Re: Canon Raw format support for gdk-pixbuf
- From: "Daniel M. German" <dmgerman uvic ca>
- To: gtk-devel-list gnome org
- Subject: Re: Canon Raw format support for gdk-pixbuf
- Date: Wed, 24 Mar 2004 16:19:02 -0800
Tor Lillqvist twisted the bytes to say:
Tor> Jens Ansorg writes:
> do you know about dcraw?
> it does encoding for a lot of digital camera formats, i.e Minolta and
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
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.
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.
Daniel M. German "Science clears the fields on which
W. Heisenberg -> technology can build. "
dmgerman uvic ca
] [Thread Prev