GNOME Bugzilla – Bug 145564
RAW file format support
Last modified: 2007-02-10 15:20:12 UTC
RAW files are usually used by professional or advanced amateur photographers since they store raw, unprocessed CCD data without any loss. Normally they are converted to to other formats by the special decoding software provided by the camera manufacturers. You can not easily view RAW files on non-Windows and non-Mac systems without converting to other formats. Therefore it would be extremely useful if gthumb supported Digital Camera RAW file formats. There is free code available for decoding RAW files of different manufacturers. More information is available at http://www.cybercom.net/~dcoffin/dcraw/
if there were a "Vote" feature in gnome bugzilla I would put all my available votes on this one. There exists a great library for raw encoding - one "only" needs to plug that into gphoto ok, I admit, sounds easier than it probably is :)
With the ability to work with RAW files Gthumb will become an adult!!! Go! Go! :-)
*** Bug 302537 has been marked as a duplicate of this bug. ***
I also vote for RAW support in gthumb. At least it would be nice to be able to import them with gthumb-import. The version that I use (2.6.5) only shows jpeg files in the import window. As a first step the raw files (and other files for that matter) could just be shown with some default icon.
I don't think that GThumb can become a concurrent to UFRaw anytime soon, but why couldn't it complement UFRaw? What I'm largely misssing is equivalent to Canon ZoomBrowser, which quickly extracts JPEG preview that is stored in raw file, so that I can evaluate whether I should bother opening this particular snapshot in Raw processing software. This is really critical when you are back from a gig with over 500 snapshots in Raw in your Vosonic portable hard-drive and you have to go through all of them to trash bad ones and leave good ones :) I have gnome-raw-thumbnailer here, but the preview is 100px or so wide and doesn't make much sense. There is http://www.cybercom.net/~dcoffin/dcraw/parse.c to extract JPEG preview from Raw files. Displaying Raw preview would be a *VERY* useful feature. I hope you can find time for it. If you need financial support, I can consider paying up to $30 via Webmoney, though I understand it's not that much.
fwiw GQview have this in in their 2.1.1 release, and it works very well.
Once gThumb has support for RAW I will not need another software package for managing my photos. I too would find RAW support very, very useful.
Anyone know what the status of RAW support is?
*** Bug 323191 has been marked as a duplicate of this bug. ***
There seem to be a lot of people asking for RAW support but I haven't had any luck finding out the current development status or plans for this feature. I've emailed the author several times without any reply. Does anyone know of a source for further information on this? Is this blocked by some other bug that needs fixing? Is there a technical reason why it hasn't been implemented? Is someone needed to actually write the code (or would the feature be excluded even if code were available?). Is it a time/money issue? Like others, I'd make a donation of $$ if someone would fix this one.
*** Bug 344598 has been marked as a duplicate of this bug. ***
For the curious... At the moment, gthumb relies on gdk_pixbuf_new_from_file from the gtk+ library to load image files. The gtk+ library provides the read/write support. At the moment, there are no loaders for opening raw/hdr files in gtk+ (as far as I know). It would simplify things a lot if there were... See the io-*.c files at http://svn.gnome.org/viewcvs/gtk%2B/trunk/gdk-pixbuf/ for example. - Mike
(In reply to comment #10) > emailed the author several times without any reply. Does anyone know of a > source for further information on this? Is this blocked by some other bug that > needs fixing? Is there a technical reason why it hasn't been implemented? Is > someone needed to actually write the code (or would the feature be excluded > even if code were available?). Is it a time/money issue? Like others, I'd make > a donation of $$ if someone would fix this one. Submitting a patch to implement a RAW loader for gdk_pixbuf would probably be the most helpful thing. (Or get someone at rentacoder to write a gpl one for you, and then submit it...) For some background info, see: http://www.penguin.cz/~utx/gnome-dcraw (note the gdk-pixbuf loader "TODO" item) http://www.cybercom.net/~dcoffin/dcraw/ http://primates.ximian.com/~glesage/wiki/f-spot/interesting_links - Mike
It should be fairly simple to add RAW import support (as opposed to RAW display support) to gThumb. This is being looked at in bug 344598. - Mike
After looking at this... I think it should be "fairly easy" to add RAW viewing support. (I haven't considered editing/saving.) I'll be making a "vfs" branch in svn soon, to support my gnome-vfs work (bug 143197), so this is an ideal time to mess with image loaders. Here's what needs to be done, I think: 1) Add a "Raw" tab to the preferences gui, to configure the various dcraw options. Add matching gconf entries, update dlg-preferences.c. 2) Configure gthumb to recognize the various raw mimetypes. (I forget which files control this). 3) Add an image_is_raw function (like image_is_gif). 4) Add a function to file_utils.c that will call the external dcraw program, and return a gdk pixbuf from a gnome-vfs URI. I'm busy with bug 143197, so this is a "call for volunteers". Can anyone do part or all of the above? This is a bit different than waiting for someone to implement a gdk_pixbuf loader directly, but it has the advantage of using an existing (dcraw) external program. See also the gimp dcraw plugin, which basically just tells gimp to call dcraw. (The gimp plugin shows which config options need to be sent to dcraw). - Mike
I have a patch that add RAW thumbnailing to gthumb, using libopenraw 0.0.2
Created attachment 81277 [details] [review] patch to support raw thumbnailing I have GNOME CVS access. If you like the patch, let me know. This patch is against 2.8.1. It might need to be adapted to trunk. I'll do that. It might also need a better file type detection.
Cool, Hubert! I was unaware of libopenraw. Regarding svn: 1) New stuff goes into 2.9.x. And right now, it should go into the vfs-testing branch, because a number of changes are being introduced there (by me) to support video thumbnails/display and VFS URIs. Some of the functions in file-utils.c have been re-worked a bit and they affect your patch (for instance, file_is_image -> file_is_image_or_video), and the thumb-loader code has been re-worked to support vfs. So the patch should be re-worked against the vfs-testing branch. Regarding openraw: 2) Does/will openraw support VFS? (We can use gnome_vfs_xfer_uri to make a local copy if we have to - we do that for gif, but it would be nice if openraw supported vfs directly). 3) When can we expect openraw to be able to return a full image pixbuf for display (not just thumbnailing)? (If it will soon, that's great, otherwise we have to think about dcraw). - Mike
Created attachment 81282 [details] [review] updated patch This is patch against current SVN TRUNK. I forgot: it requires libopenraw 0.0.2 to be useful: http://libopenraw.freedesktop.org/
(In reply to comment #18) > So the patch should be re-worked against the vfs-testing branch. *sigh*. ok > Regarding openraw: > > 2) Does/will openraw support VFS? (We can use gnome_vfs_xfer_uri to make a > local copy if we have to - we do that for gif, but it would be nice if openraw > supported vfs directly). It does not use gnome-vfs at all because libopenraw per see does not depend on gnome-vfs. BUT it can have a custom IO layer, so in the future it could be implementable by the gnome support library. > 3) When can we expect openraw to be able to return a full image pixbuf for > display (not just thumbnailing)? (If it will soon, that's great, otherwise we > have to think about dcraw). I hope for next version, but I don't have any date to give. When it is ready will be more accurate.
Hubert, If you are comfortable with your code in vfs-testing, please go ahead and commit it to that branch when it is ready. (Feel free to re-work my code if you see any major issues.) I don't know how actively you commit to gnome, so I'll remind you that gnome moved to svn at the end of the year. - Mike
committed a variant of this patch in the vfs-testing branch. It does not reallu handle gnome_vfs but if the URI is a file: it will resolve the pathname and use it. So thumbnailing raw files only work on "local" files. Keep open until the viewing of RAW files is done using a more recent version of libopenraw.
I've moved some code around to add VFS support for the raw images (svn rev 1297). The main bit of raw thumbnail code is now in: libgthumb/file-utils.c: gth_pixbuf_animation_new_from_uri However, I'm having an odd problem. I have compiled libopenraw 0.0.2 (using ./configure --prefix=/usr; make; make install), and the gthumb autogen output says libopenraw is present (Have libopenraw: yes), but the #ifdefs seem to fail. The ifdef'd raw code doesn't actually run. When compiling gthumb, I get these errors: libtool: link: warning: `/usr/lib/gcc/i386-redhat-linux/4.1.1/../../..//libopenrawgnome.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i386-redhat-linux/4.1.1/../../..//libopenraw.la' seems to be moved Any ideas why? - Mike
Here's a snippet when I use libtool --debug: ++ library_names='libgthumb.so libgthumb.so libgthumb.so' ++ old_library=libgthumb.a ++ dependency_libs=' -ltiff -lz -L/lib -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnome-keyring -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 -lgnomevfs-2 -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt -lexif -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0 -lpango-1.0 -lcairo /usr/lib/gcc/i386-redhat-linux/4.1.1/../../..//libopenrawgnome.la /usr/lib/libopenraw.la -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 /usr/lib/gcc/i386-redhat-linux/4.1.1/../../..//libopenraw.la -ljpeg' libopenraw.la shows up twice... that's not normal, is it? - Mike
Oops, I forgot the config.h include. That's all. The libtool warnings are harmless. - Mike
libopenraw support is in svn trunk now. - Mike
I have added initial support for RAW and HDR images, if pfstools, pfstmo, and dcraw are installed. (These are a pain to install, though - I am hoping that we can rely on the simpler libopenraw for RAW images in the future). This is in svn rev 1336 and later. Please test. - Mike
RAW display now works if dcraw is installed. (pfstools and pfstmo are now only needed for HDR images). I'm closing this bug as fixed (as of svn rev 1345, anyway - it should appear in release 2.9.2). Hubert, let me know when libopenraw can generate pixbufs of full images, and we can insert the code into libgthumb/file-utils.c: gth_pixbuf_animation_new_from_uri. That function tries a series of loaders in sequence and uses the first that works, so libopenraw could be inserted before the dcraw loader (get_pixbuf_using_external_converter). - Mike