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

[Caulier Gilles]

Le Samedi 17 Décembre 2005 14:35, fj.cruz at supercable.es a écrit :
> ---- Gerhard Kulzer <gerhard at kulzer.net> escribió:
> > 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
>
> As I said in a recent conversation with Gilles, in my opinnion, ufraw is
> the better app for raw decode, its features are similar to other propietary
> applications like Capture One or Camera Raw and its results are the same o
> better than theses apps too.
>
> On the other hand, it's usually we must to choose between quality or speed,
> so if we want to have a great raw decoder in Digikam, we must to provide to
> the user a modules like ufraw, where they can do the best adjusts for their
> preferences.
>

I study hard the current dcraw implementation to create a core lib in digiKam. 
I want create a C++ class including all dcraw methods with the minimum 
changes to backport easily all future dcraw releases.

Gilles