GNOME Bugzilla – Bug 625356
Displays CR2 images but ignores them on "next"
Last modified: 2010-07-31 11:37:34 UTC
This was reported in the ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/608540 "Eye of GNOME 2.30.0 can display CR2 (raw cannon images) images when you double click on them, but when you press the next button on it, instead of showing you the next image it jumps to the next non-CR2 image." The same holds for current git HEAD.
Eye of GNOME does not support RAW images out of the box. They are only supported when libopenraw's pixbuf loader is installed. Only then eog will pick CR2 files up into the collection when loading a folder. From what I remember Ubuntu does not ship this loader (although it ships libopenraw). The reason why you still see an image is that the CR2 file format is largely following the format of TIFF images. So, what you are likely seeing is the included JPEG preview image which the present TIFF loader was able to extract. This relationship between TIFFs and CR2s might also be the reason why you can double click them, as normally eog shouldn't be registered with CR2 images (I checked it's not in the list eog registers itself with). Closing as this is neither really a bug nor is it eog's fault.
Thanks for the explanation, CR2 is indeed registered as sub-class-of image/tiff. While I see the technical reason for this now, I do still think it's a bug from the user's point of view: "Why is it possible to "click and close" through all raw files in a directory files but not to use the prev/next arrows?" eog behaves inconsistent because all gio functions take the subclass-relationship into account. That's why eog is counted as registered for raw-files (g_app_info_get_all_for_type will return eog for "image/x-canon-cr2") and therefore offered by nautilus and also why eog's file chooser will list raw files under "all images" (GtkFileFilter: "Filtering by mime types handles aliasing and subclassing of mime types"). If you agree it could indeed be a bug, I see two possible fixes (and could submit patches for both): 1) change eog_image_get_supported_mime_types to return a list of all mime_types supported by pixbuf *and all sub-classes of these mime-types* 2) change eog_image_is_supported_mime_type to return true also if the image is a sub-class of a supported mime_type. For reference: On my system this would add image/x-sony-sr2, image/x-kodak-kdc, image/x-canon-cr2, image/x-adobe-dng, image/x-pentax-pef, image/x-nikon-nef, image/x-kodak-k25, image/x-kodak-dcr, image/x-sony-arw, image/vnd.microsoft.icon, image/x-sony-srf to the supported mime_type list.
Thanks, for debugging what happens on the MIME layer. Good to know. Although I agree it does look strange to the user, it's still not really a bug in eog (or evince which is affected as well) IMHO. It's more a false assumption of the MIME layer (and also your patches) that every TIFF capable application also supports CR2s. This appears to especially false when libtiff4 (beta6) is used, which fails to load even the preview image from my CR2s due to stricter error handling. So, the only real fixing eog could do would be to support RAW files directly (bug 344601) or Ubuntu could just package libopenraw's gdk-pixbuf-loader and put it in eog's recommends as it did for librsvg's loader for SVG files.