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

[fj.cruz at supercable.es]

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

Paco.