Re: Canon Raw format support for gdk-pixbuf

["Daniel M. German" <dmgerman uvic ca>]

 Tor Lillqvist twisted the bytes to say:

 Tor> Jens Ansorg writes:
 > do you know about dcraw?
 > 
 > http://www.cybercom.net/~dcoffin/dcraw/
 > 
 > it does encoding for a lot of digital camera formats, i.e Minolta and
 > Nikon

 Tor> However, before somebody suggests using that to write code to load the
 Tor> actual image from a RAW file in gdk-pixbuf, please consider that the
 Tor> main reason why one uses RAW format in the first place is its support
 Tor> for more than 8 bits per channel, and the gdk-pixbuf (AFAICS) only
 Tor> supports 8 bits per channel.

Let me first explain the format and my goals.

Canon RAW photos are difficult to browse with Nautilus or photo
oriented tools (like gqview) because they don't understand them. I
have been using dcraw (David Coffin's) to convert them into JPGs. 

My goal is not to convert the photos, but to be able to quickly browse
them. The canon format contains a embedded JPEG that is 8bit and large
(60% of the raw photo, 2000 pixels wide in the d60 for example). What
I want is gdk-pixbuf to load this jpeg to "browse" the photo.

I have completed the support for this in gdk-pixbuf but I am having a
hell of time trying to get the code called with dynamic linking. 
I can run the pixbuf-demo (changing the files that it uses to RAW
ones) and it works great.

But when I try to use another tool to load them, the code never gets
called. Can somebody tell me where do I look, what steps are needed to
add a new type of image format?  The dyn library file is created and
placed in the proper location along with the other libraries.


 Tor> What would be really useful, IMHO, would be to convince Dave Coffin to
 Tor> convert his really useful code from a freestanding single-file program
 Tor> into a library with a clean API, and no static data. (Then the dcraw
 Tor> command would be a very small program that calls that library to do
 Tor> the job.) I suggested something like that once to him, but he didn't
 Tor> like the idea.

He has put his code in the public domain. I have looked at it and
reemplemented the parsing part of the internal data structures in a
way that is re-entrant (his code is really bad in this repect, as Tor
points out). I am willing to continue this work with that goal in mind.

 Tor> (This probably should be done by creating automatic Perl or whatever
 Tor> scripts that converts his dcraw.c into the source file(s) for the
 Tor> library, so that you can reapply it whenever he updates the
 Tor> functionality of dcraw...)

Good idea. But I honestly think that there are 2 different problems
here:

1. Browsing. For this we don't need a high quality image. We can use
   the embedded jpeg. It will way faster than decoding.

2. Conversion. For this we can keep using the command line tool. The
   gimp-plug in is using it to load RAW files. 

I think this approch is a good one.

 Tor> I don't like to use dcraw only through separate invokations, because
 Tor> for applications like what I have in mind (an Open Source alternative
 Tor> to interactive RAW manipulation tools like Phase One's Capture One),
 Tor> that just isn't good enough. It would be too slow to have to convert
 Tor> all of the RAW file for each tweak you do interactively, just to check
 Tor> the result in a part of the image, for instance.

Xactlyl

 Tor> In fact, there already has been such work (look for "libraw"). But at
 Tor> least when I looked at it, even if it did have a clean API, it
 Tor> suffered from being forked early from Dave Coffin's work, and then
 Tor> dramatically restructured, and thus diverging without hope of backport
 Tor> of the actual RAW decoding enhancements that Dave does all the
 Tor> time. Thus the idea to use an automatic script.

Point taken.


--
Daniel M. German                  "Science clears the fields on which
    W. Heisenberg ->               technology can build. "
http://turingmachine.org/
dmgerman uvic ca