[Digikam-devel] dcraw -h (was Re: extragear/graphics/digikam/utilities/imageeditor/editor)

[Gerhard Kulzer]

Am Freitag, 16. Dezember 2005 19.32 schrieb Thorsten Schnebeck:
> > I'm almost sure that the frog file is corrupted, has nothing to do with
> > dcraw. I observe this on about 5% of my images after download from
> > camera. When I download them a second time the files are OK.
>
> Yep, looks brocken. Its not good to have such an image in the raw data
> base. Do you have a better one?
>
> > Very strange, as one
> > had to rub-in the bits. Maybe it is a flash card issue since it is the
> > same problem with card reader or camera USB download.
> >
> > The quad size problem of dcraw pertains to any format needing filter as
> > Dave pointed out. There may be more formats than cr2 using filters.
>
> Should be every cam with a RGB or CYMG bayer sensor.
> I think I do understand what -h does and that this the wrong way using
> dcraw in digikam. For our example
>
> dcraw -i -v CANON-EOS350D.CR2
> Filename: CANON-EOS350D.CR2
> Timestamp: Thu Sep 29 13:34:40 2005
> Camera: Canon EOS 350D DIGITAL
> ISO speed: 400
> Shutter: 1/320.0 sec
> Aperture: f/11.0
> Focal Length: 72 mm
> Raw colors: 3
> Filter pattern: RGGBRGGBRGGBRGGB
> Daylight multipliers: 2.467797 0.917149 1.164814
> Camera multipliers: 2269.000000 1018.000000 1652.000000
> Raw size: 3516 x 2328
> Image size: 3474 x 2314
> Output size: 3474 x 2314
>
> a high quality standard should use something like:
>
> dcraw -c -w -n -m -q 3 -4 CANON-EOS350D.CR2 > eos350.pnm
> Not sure about the "-m" option cause AFAIK raw images dont use
> colorprofiles only JPEGs use CMS but as dcraw also uses lcms maybe its
> better to apply one profile to the output.
>
> But -q 3 (== ADH interpolation) was a great step in interpolation quality.
> Using -h (== -q 1) and a quite simple linear interpolation is for sure
> speedy but raw should be about quality and than about speed.
>
> BTW, this is dcraw 7.93
>
> Bye
>
>   Thorsten

I made a comparison of a) present digiKam dcraw (dcraw-c-h-4-w-a.jpg), b) 
ufraw-batch (ufraw.jpg) and c) optimum dcraw (dcraw-c-q3-4-w-n.jpg). 

Speed: a) and b) are fast, c) is slow (unfortunately)
Quality: Resolution ranking c, b,     a
Noise Ranking: c,       b,a

Ufraw blows up the -h image to adjust it to its real size. It does a good job 
in smoothing so that that the resolution is not so bad compared to -q3. But 
the noise performance is really bad. The -q3 noise is way better.

My conclusion (confirming Thorsten) : fast or good, we have the choice. It 
doesn't help much to include dcraw code into digiKam, as we (probably) can't 
do a better fast job than ufraw.

Gerhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcraw-c-h-4-w-a.jpg
Type: image/jpeg
Size: 32305 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20051217/4508edb1/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ufraw.jpg
Type: image/jpeg
Size: 18559 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20051217/4508edb1/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcraw-c-q3-4-w-n.jpg
Type: image/jpeg
Size: 20930 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20051217/4508edb1/attachment-0002.jpg>