mxpxpod: if your Nikon camera makes f-spot crash when you download the pictures, you might have better to switch the camera back to USB Mass Storage. f-spot will bypass libgphoto2 and directly import by copying.

Well, I was going to have to do it sometime. I got out the USB cable and plugged the camera into the Ubuntu box, not expecting much.

What a pleasant surprise; some little program popped up, told me I’d plugged in a Canon S70 and wondered where I’d like to download the pictures to. Had a nice little slide-show thingie too for quick review.

Thanks Tim for the feedback, the gphoto team is happy to have provided you a good surprise. (and also kudos to the applications writers and system packagers for providing the user experience).

Yes, as I noted a few weeks ago, I bought the Canon PowerShot SD450. When I plugged the camera into my shiny new install, Ubuntu immediately recognized it and offered to import the photos, which I did, and it worked. I believe this is the work of libgphoto2, which is one of those amazing little libraries that does one incredibly useful thing incredibly well and just keeps getting better for free. Someone out there *really* cares about interfacing with digital cameras, in much the same way that I *really* care about parsing RSS and Atom feeds.

Thanks Mark, you made my day with this user testimonial. I know switching is not easy, and I'm really happy that the libgphoto developers made your life easy for that part.

Yesterday you announced Picasa for Linux. But I'm a bit confused. I don't find it. All I see is a Windows binary installation and a Wine installation. Is that what you call a Linux version? I call that a Wine version. But I'm sure you have you reasons after all, and it is good enough for some people to congratulate you.

I also see that you benefited from Marcus' wonder hack about libgphoto2 support in Wine 0.9.13. Marcus is one of our[1] most dedicated hackers, and I wish myself to publicly thank him for the tremendous work he put in gphoto. He saved you a few bucks in contracting with a pure random coincidence, so maybe you could share the reward, no? Putting is in the FAQ will juste get us more support work, support we manage to provide ourself without any help but the user and some external companies that end up going the Open Source way by contribution back patches and fixes. Even some lobbying to get us support from manufacturers would be something we would appreciate, even if I'm sure you just don't care.

So what can you do to make this better? I see three things:

caring more about Linux by stopping this Wine hack and releasing a real Linux port. Even something using winelib at first would be nicer. Or modify an existing GPL program, in collaboration with their maintainer, to provide a Picasa experience.

caring more about Open Source by release Picasa as Open Source. I know the last part is more difficult because you probably did by choices by tying yourself to some obscure bad software vendor or just because you still don't believe in Open Source unless they helps you provide nice tax breaks or publicity.

at least not insult Linux user by providing them bad quality "ports" like that. You might find that last request a bit rude, but I believe that these bad quality Linux versions harm Linux more than they do good. Listen to this: "Linux sucks because Picasa on Linux is largely inferior to the Windows version." Hell yeah. I have heard that a while back about a different software on a different platform. You are just repeating history.

Notes

I spend my week-end reading online and on dead-tree, as well as tranlating my slides from GUADEC 2005 to French so that I can talk about digital photography at the meeting of Club Linux Outaouais in Gatineau, QC, Tuesday. Talk will be in French, that goes without saying. I'm not just simply translating, I'm updating a few items and add some new stuff about KDE programs.

I must note that OpenOffice 2.0 did crash at least 5 times during the process. The good news is that their recovery mechanism seems to work pretty well.

If you want to access your digital camera, you use a program that use libgphoto2. Now, with version 2.1.99 (upcoming 2.2) we even handle the camera that are mounted as a disk. It took us time to implement that because we didn't see the interest until we realized that people wanted to use their camera with a digital photo application, be it f-spot, gtkam, digikam, gthumb, and that the developer of said application shouldn't have to figure out the details. So now, we provide a single API for all the cameras that we know how to communicate with.

But what if you want to access your digital audio player (iPod, iRiver, Nomad Jukebox, etc)?

Some devices work as USB Mass Storage, like the small flash based players, hence do not require anything special driver.

For the iPods, there is libgpod that developers use to access the iPod private and proprietary database, there is ipod-sharp and its companion libipoddevice for those who write in C#, ipodslave of KDE developers (it is a kio-slave module) and gnupod, the Perl version.

For the Nomad Jukebox, there is libnjb, that implements the DPE protocol.

For the new iRiver and other MTP devices, there is experimental support in.... libgphoto2. Yes, you read correctly, a digital camera driver can be used. The MTP protocol is a variation of PTP (Picture Transfer Protocol, used for still image cameras), mostly pushed by Microsoft who provide a standard driver in the latest Windows XP updates. It is some sort of corruption of PTP and I think that the idea behind is to be able to control what files can put on the device, like implementing DRM. A bit like Apple does with iPod preventing iTunes users to download from the iPod the music, requiring that the music be on both the iPod and the computer, and having implemented a hackish crippling of iTunes to prevent loading some third-party plugins that allowed users to download the music off the iPod.

And I probably miss a lot.

How confusing is that ? Confusing for the developer that has to write at least four different version of code to access most of the device, and to the user that may not be able to use the application XyZ with the ACME player.

The solution it to create a library for digital audio player access the same way we have libgphoto2. One API for all the devices. That would involve a few changes in libgphoto2 to extract the PTP protocol, and give libgphoto2_port is own life, because the PTP implementation uses it. That would give the following architecture (admire the ASCII art):

I just released gphoto2 2.1.99. This release is required to build with libgphoto2 2.1.99 that has been released previously. One of the reason is that gphoto2 relied on some libgphoto2_port API that has changed.

We have had users complain that they couldn't use their "USB Mass Storage" camera using a libgphoto2 client, and we finally implemented support of these using the disk: driver. Philip Langdale have been having the opposite use case: using a non Mass Storage camera using a file manager.

This is how gphotofs is born. gphotofs is a FUSE file system, ie a user space filesystem using libgphoto2. The code has reached gphoto CVS.

libgphoto2 2.1.99 has been release today on Boxing Day. It is the first pre-release of the upcoming 2.2.

This release is for testing purpose.

Beside the numerous bug fixes and new camera support, the major feature is the support of cameras mounted as filesystems (works better if you have
libhal) that I have already described, as well as better handling of the in memory caching (by Marcus).