[KimDaBa] Debian 2.1 when ?

[Robert L Krawitz]

   From: Steffen Hansen <steffen at klaralvdalens-datakonsult.se>
   Date: Wed, 11 May 2005 12:54:11 +0200

   On Wednesday 11 May 2005 12:44, Jesper K. Pedersen wrote:

   > Isn't this what [QK]ImageDecoder is all about?
   > Maybe these extra format's should be created as image decoders, that
   > kimdaba would instantiate at an appropriate location.

   Right, but kimdaba has some spiffy code for loading reduced size
   JPG images that bypasses the KImageDecoder stuff, and all the JPG
   functionality was readily available in that code.

   I'm a bit afraid to create "real" imagedecoders for RAW formats
   that only pull out the embedded JPG and don't really decode the RAW
   data.  Any idea if the KImageDecoder classes support the notion of
   an implementation that only shows a preview (which the embedded JPG
   really is) without being able to decode the real thing?

The problem with raw files is that they aren't really images; they're
dumps of the camera sensor with some extra metadata.  They can be
processed into an image, but if you tried to use them as an image
they'd have all manner of problems, such as the fact that most cameras
only record one channel at each point.

The only completely free tool to convert a wide range of raw files is
dcraw; many proprietary tools are built off it, since most of it is
licensed for any purpose (BSD-style).  Recently Dave's added some GPL
components to it.  I have a version of my own which I'm eventually
going to release entirely under the GPL.

The right thing (IMHO) here would be a kimgio handler for raw files.
This particular handle would invoke dcraw to do the work.  It would
need to be able to handle a variety of options somehow.  Also, it
would be quite slow; depending upon the output resolution and
interpolation method selected I find it takes anywhere between 2.5 and
20 seconds on a PIII-1GHz (20 seconds for a full-size output using
high quality interpolation; 2.5 seconds for a thumbnail where it's
limited by how fast it can read the file in).

At this point, I'm inclined to not want to use the raw handling in
kimdaba for any kind of production work at all, and use only
conversions for that purpose.  The reason is that I embed small/coarse
JPEG's in my raw files to save space in my compact flash.  However,
when working on dcraw it is certainly handy to compare what the camera
generates with what my code generates.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton