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

[Gilles Caulier]

Le Samedi 17 Décembre 2005 10:27, Gerhard Kulzer a écrit :
> 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.
>

ok. thanks for these informations.

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

perhaps we can't do a better fast job than ufraw but we can improve digiKam 
speed RAW decoding using dcraw implementation in digiKam core, because :

1 - we using an external dcraw instance. Ther is aloop to decode RAw data in
2 - we using a pipe to get decoding data (in PNM form)
3 - we using an internal loop to convert PNM data to DImg data form.

Conclusion : we are 2 loops. Including dcraw loop under digiKam core will 
reduce time RAW file loading in IE (20-30% i think).

Gilles

>
> Gerhard

-- 
Gilles Caulier