The gphoto project has been running without manufacturer support for at least 6 years now. No manufacturer did help us to write drivers to communicate with their camer, and only a very few have provided documentation in the past. So far, good citizens have been Kodak, who did publish the protocols for almost all their consumer camera, until they switched to PTP and reorganized themself, and Digita, that provided some sort of documentation, even if largely incomplete that was a good basis to write the driver. Other than that, it has only been either total ignorance or even some sort of hostility. One good example is Canon of such hostility, that still so far has to understand that we do their job, supporting camera they no longer provide support.

The dialog with Canon representatives, when we had one, as been useless and a waste of time. It did looked like:

- Hello I'm part of the gphoto project, we write free drivers for digital camera for Linux and other UNIX systems . We would like to support Canon cameras, so we would like to have the proper documentation for that.

- Use the Canon SDK. It is available for Windows and allow you to communicate with Canon cameras

- Mmm. As I said we run on UNIX, not Windows, so it is likely your SDK for Windows is useless to us.

- Mmm. There is a software called gphoto that works on UNIX. It might work for your. Be aware that Canon does not endorse this product at al.

grin

- Can I have access to that SDK ?

- Which company is it for ?

- Sorry I'm an individual.

- Then I'm sorry, the SDK is not available to individuals.

sigh

Yes, they told gphoto developers that just wanted documentation to look at gphoto, and then refused us access to the SDK. But thanks to the obstination of a few smart hackers (that I was NOT part of), reverse engineering has been successfully performed to implement the Canon drivers for almost every cameras.

A couple of years after, Stephen H Westin, on behalf of Cornell university, got access to that SDK, that helped him a bit to complete the reverse engineering process towards provide software support for capturing images with a Canon camera. He admits that the documentation in the SDK, even if just documenting APIs, helped him. The documentation is still under NDA.

Nikon camera support has been somewhat easier. They started with Sierra Imaging firmware, and used this protocol, already reverse engineered by the photopc developers, then they switched to USB Mass Storage, with the advent of USB, that was already in most USB stacks, because it was part of the USB protocol suite. They never provided any assistance.

Now, with the recent Nikon story, I started collecting a bit of information. I went to Adobe user forums and found this:

From Adobe forums:

Thomas Knoll - 11:30am Mar 1, 05 PST (#3 of 18)

Adobe: Can you please document NEF format?

Nikon: No, but you can use our SDK.

Adobe: But the Nikon SDK does not provide what Camera Raw needs to operate, and using it would limit Camera Raw's speed, UI features, and quality of results (e.g. Camera > Raw's special highlight recovery algorithms).

Nikon: Then redesign Camera Raw to work within the limits of our SDK.

Adobe: No, we don't want to cripple Camera Raw. Please document NEF format.

Nikon: No, redesign Camera Raw to work within the limits of our SDK.

etc.

And I thought that with gphoto and other Free Software project, we were the only one to have problem with camera vendors to obtain the documentation and specifications for communication protocols with cameras. But Thomas Knoll, who is one of the original authors of Adobe Photoshop, seems, on behalf of Adobe, to have trouble to obtain some sort of support from Nikon to decode RAW files. Basically Nikon tell Adobe to abandon the flagship features that make Adobe software better than Nikon's (that you also have to pay extra for, shall I remind you), making it useless. Note that Free Software with dcraw did that long before Adobe release their camera RAW plugin, and of course without manufacturer support.

Can someone explain the logic behind these people to hide communication protocol, which is not the major reason to choose a product, and to not disclose file format ? I don't see any. Fortunately, in that market, there is device interroperability, like camera to printers, camera to portable drives, etc. That led to the use of the standard PTP protocol, and before that, the use of USB Mass Storage, thanks Microsoft for making it difficult to write a USB driver, and support it: manufacturers mostly switched for that reason, at least this is what I do believe, because otherwise they had no other interest given theur current attitude.

Even better. Some camera have no support for recent versions of the only OS the manufacturer support, so we end up with some request from users to port gphoto to Windows. We don't have interest in doing it ourself. One more advantage: you are not fooled by the vendor who drops support to sell upgrades.