LabVIEW
Controlling FUJI GFX100S camera - shooting and setting
This is an interesting but also very complicated topic.
When DSLR cameras got mainstream, there emerged a standard called PTP (Picture Transfer Protocol) that was attempting to standardize the communication of picture transfer as well as remote control of cameras. It looked promising and most camera manufacturers added it at least as an option to their products, besides usually supporting a different communication standard, quite often called native (a nicer word for proprietary). PTP was in theory transport independent but in reality only really ever implemented over USB. It tried on one hand to be flexible, so to not limit camera manufacturers in any way and at the same time still promote a common interface. The reality was that aside from picture transfer itself, most other things were highly manufacturer specific and often changed with new models even from the same manufacturer.
The most common open source implementation was libptp and then libptp2, but its development stopped around 2016 as most manufacturers had abandoned PTP as a standard. Windows supports PTP too as part of the WIA driver framework, but aside from the picture transfer itself everything else has to be implemented by an application through passthrough messages by implementing the camera specific commands itself. By now WIA itself is an abandoned technology that Microsoft would rather forget than spend one single additional hour on.
The only framework that I'm aware of that is multivendor capable would be the libgphoto2 project. But that is only available on Linux/Unix. It has not been ported to Windows until now and likely never will be. libgphoto2 is however a library that needs to be called from an application. It is not a plug and play interface for any programming environment including LabVIEW. There are of course bindings available for the more popular programming environment like Python or .Net, but only on Linux/Unix since the entire libgphoto2 framework is Linux/Unix only.
So what does that mean for you? Unless you want to work on Linux, the camera vendor specific SDKs are your best bet to try to get this working. And yes these SDKs are generally in the form of shared libraries (DLLs) and sometimes .Net Framework libraries, usually as Interop interface to the lower level shared library implementations. On Linux you could consider looking into libgphoto2 instead, but this still means that you have to create a LabVIEW binding to the actual libgphoto2 shared libraries. Basically the same effort as when trying to interface to the manufacturer specific SDK libraries.
Basically you have several options.
1) Using the Call Library Node you can directly call into shared libraries/DLLs. This works very well if you know what you are doing and that means actually a bit more than just being able to call the library functions in C for instance (which in itself is already quite a feat for any non-trivial library). The Call Library Node allows you to call each shared library function and configure the parameter interface for that function and here is part of the difficulty. Without having a very good understanding on how C compilers tend to pass parameters to functions you can really misconfigure those parameters and create a wild crash generator instead of anything else. If the parameters are complex (structures containing pointers of any sort, large clusters with many elements even if no pointers are used, or any form of callback pointers) it gets very tedious (and in the case of callback pointers completely unpractical to directly try to interface to the functions through the Call Library Node. In that case my go to path is generally to create an intermediate shared library in C with a more LabVIEW friendly interface that then translates to the lower level shared library.
2) .Net Nodes can access .Net shared libraries on Windows. (.Net Core support is preliminary and still quite limited in the latest LabVIEW version). This does have the advantage that the configuration of the interface is part of the .Net library specification, so LabVIEW can usually generate the entire binding glue behind the scenes itself. It has a few limitations though, for instance if the type library says it is a scalar passed as pointer, while it should be really used as an array, you can't convince LabVIEW to overwrite the type library definition. Also functions that use generics as type for any parameters are not supported without going through very involved reflection call interfaces to circumvent the LabVIEW binding logic.
3) If you have a separate application that interfaces to your hardware, that provides a standard interface such as TCP/IP, you can communicate from LabVIEW through that. It is not very fast because of the intermediate proxy but often simpler to do than interfacing to a new custom library.
I can assist you with this if you want but there are quite a few difficulties. Distance, Communication options, availability of hardware and necessary SDKs and such are all possible obstacles. Also the financial aspect is usually a major issue. 😁
People tend to expect that these things should be simply available, yet it is a lot of work with an extremely small interested audience, so that dispersing costs is usually not an option.
