[KimDaBa] Debian 2.1 when ?

[Steffen Hansen]

On Wednesday 11 May 2005 13:52, Robert L Krawitz wrote:

> 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.

Exactly, RAW data might require Bayer demosaicing, dark current 
compensation, white/black/curve adjustments, sharpening, color 
correction and so on -- not to mention the basic decoding of the data 
that is stored in proprietary formats.

> 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).

I don't believe in automagic conversion from RAW to image. It will never 
be acceptable compared to a good RAW converter application with user 
adjustable parameters.

So, all you get from invoking dcraw automatically is a preview image 
that is probably of worse quality than the embedded JPG preview, and 
converting with dcraw is going to be a lot slower than pulling out an 
embedded JPG.

So, the conclusion so far is to make kimdaba show the embedded JPG for 
thumbnail and preview images and nothing more. "Real" conversion sould 
be handled by an application suitable for the task -- such as bibble. 
It would still be nice to somehow "group" a collection of a RAW file 
and the (multiple) images that have been created with it -- but that is 
being discussed in the "new features" thread.

I've talked to Jesper about it and we have agreed on a design that 
allows kimdaba to be enhanced with support for multiple RAW formats 
just like it supports Canon's .CRW right now (but without further 
uglyfing the code and without "polluting" KDE with image loaders that 
don't really decode the image). Now I just need to find time to 
implement the basics, then we can start adding support 
for .CR2, .NEF, ...

> 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.

regards
-- 
Steffen Hansen          |       Klarälvdalens Datakonsult AB
Senior Software Engineer|       http://www.klaralvdalens-datakonsult.se
                        |
                        |       Platform-independent
                        |       software solutions