In the release-notes for ristretto 0.3.5 last weekend, I mentioned the following:
Most problems with ristretto are actually caused by incorrect mime-type recognition
of the operating-system, identifying raw files (like canon’s CR2 format) as TIFF files.
This will result in an error from the tiff loader, these errors are now displayed in the UI,
making it possible to identify the source of the problem.
Since I could not understand why this happened, I started investigating the problem a bit further.
So, I executed the following commands on my system:
$ mimtype IMG_6635.CR2
$ file IMG_6635.CR2
IMG_6635.CR2: Canon CR2 raw image data, version 2.0
In my defense, I have seen it return image/tiff in the past, but clearly that was not the case right now. Both commands returned image/x-canon-cr2 just fine.
But opening the raw-files with ristretto (with the libopenraw-gnome backend installed), still gave me TIFF image-loading errors.
So something else must be causing the problems. Apparently, the OS determines the mimetype just fine, but something inside ristretto does not. Checking the source I discovered I was using gdk_pixbuf_loader_new(), which creates a pixbufloader that automagically determines the mimetype based on the stream of data you feed it.
So, I replaced that with a call to gdk_pixbuf_loader_new_with_mime_type (mime_type, NULL) and retrieved the mimetype using GFileInfo.
The commit that fixes this problem is 8dd741057f7b935d8e7c327017d850388ba77767, you can cherry-pick it and install libopenraw-gnome to support the rendering of raw files inside ristretto.
Libopenraw-gnome is still under active development and rendering-bugs can occur. – When the image looks bad, this is not a bug in ristretto, it is probably some terrible photography ;-), or maybe something is not yet fully implemented in libopenraw-gnome.
Using git-master this weekend did not result in any usable whitebalance or exposure compensation for me.