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

Gerhard Kulzer gerhard at kulzer.net
Fri Dec 16 17:02:47 GMT 2005


Am Freitag, 16. Dezember 2005 17.47 schrieb Gilles Caulier:
> Le Vendredi 16 Décembre 2005 05:46, Gerhard Kulzer a écrit :
> > Am Mittwoch, 14. Dezember 2005 16.02 schrieb Thorsten Schnebeck:
> > > > > > What the problem with -h option ? The Raw decoding speed is
> > > > > > decreased without this option ? Please give me a feedback
> > > > > > before to change...
> > > > > >
> > > > > > Gilles
> > > > >
> > > > > Gilles, without the -h option it works as it should, I get
> > > > > the correct picture size. Reading the dcraw help it is clear
> > > > > that -h divides the image by 4. So there is no problem with
> > > > > dcraw, we have to leave out -h.
> > > >
> > > > I'm not agree with you. Why -h option working fine with other
> > > > file formats, and with any CR2 file that you have provide ? I
> > > > suspect a problem in dcraw with CR2 and -h option...
> > > >
> > > > Gilles
> > >
> > > "-h" comandline option of dcraw correspondends to "half_size=1".
> > > In dcraw there is this code:
> > >
> > >     shrink = half_size && filters;
> > >     iheight = (height + shrink) >> shrink;
> > >     iwidth  = (width  + shrink) >> shrink;
> > >     image = calloc (iheight*iwidth*sizeof *image + meta_length,
> > > 1);
> > >     merror (image, "main()");
> > >     meta_data = (char *) (image + iheight*iwidth);
> > >
> > > So, based on "filters" it seems to be possible, that one format
> > > shrinks and another does not shrink. I tested cr2 and x3f (BTW
> > > the latter is not part of digiKams default supported raw format
> > > extentions nor is any raw format part of the "Image Import..."
> > > filter dialog):
> > >
> > > x3f results to a full-sized image, cr2 to a half- (better
> > > quad-)sized image when using "dcraw -h"
> > >
> > > "filters" set or unset seems to be a result of
> > > int CLASS identify (int will_decode)
> > >
> > > I will forward this mail to the CRW-Decode ML and maybe
> > > someone can help and explain, when -h shrinks, when it does not
> > > shrink and what is this option all about. Can "-h" be used to
> > > load and decode a RAW format in best quality?
> > >
> > > Bye
> > >
> > >   Thorsten
> > >
> > > P.S.
> > > cr2: Canon RAW
> > > x3f: Foveon RAW
> >
> > ufraw decodes cr2 to the correct size. Looking into its dcraw_api.c if
> > found this:
> >
> >      * If scale is odd we need to "unshrink" it using the info in
> >      * hh->fourColorFilters before scaling it. */
> >     if (hh->filters!=0 && scale%2==1) {
> >         /* I'm skiping the last row/column if it is not a full row/column
> > */ f->height = h = hh->height / scale;
> >     f->width = w = hh->width / scale;
> >     fujiWidth = hh->fuji_width / scale;
> >     f->image = g_new0(dcraw_image_type, h * w);
> >     f4 = hh->fourColorFilters;
> >     for(r=0; r<h; r++) {
> >         for(c=0; c<w; c++) {
> >         for (cl=0; cl<hh->raw.colors; cl++) sum[cl] = count[cl] = 0;
> >         for (ri=0; ri<scale; ri++)
> >             for (ci=0; ci<scale; ci++) {
> >             sum[FC(f4, r*scale+ri, c*scale+ci)] +=
> >                 hh->raw.image
> >                 [(r*scale+ri)/2*hh->raw.width+(c*scale+ci)/2]
> >                 [FC(f4, r*scale+ri, c*scale+ci)];
> >             count[FC(f4, r*scale+ri, c*scale+ci)]++;
> >             }
> >         for (cl=0; cl<hh->raw.colors; cl++)
> >             f->image[r*w+c][cl] =
> >                 MAX(sum[cl]/count[cl] - hh->black,0);
> >         if (recombine) f->image[r*w+c][1] =
> >             (f->image[r*w+c][1] + f->image[r*w+c][3])>>1;
> >         }
> >     }
> >     } else {
> >     if (hh->filters!=0) scale /= 2;
> >         /* I'm skiping the last row/column if it is not a full row/column
> > */ f->height = h = hh->raw.height / scale;
> >     f->width = w = hh->raw.width / scale;
> >     fujiWidth = ( (hh->fuji_width+hh->shrink) >> hh->shrink ) / scale;
> >     f->image = g_new0(dcraw_image_type, h * w);
> >     norm = scale * scale;
> >     for(r=0; r<h; r++) {
> >         for(c=0; c<w; c++) {
> >         for (cl=0; cl<hh->raw.colors; cl++) {
> >             for (ri=0, s=0; ri<scale; ri++)
> >             for (ci=0; ci<scale; ci++)
> >                 s += hh->raw.image
> >                 [(r*scale+ri)*hh->raw.width+c*scale+ci][cl];
> >                     f->image[r*w+c][cl] = MAX(s/norm - hh->black,0);
> >         }
> >         if (recombine) f->image[r*w+c][1] =
> >             (f->image[r*w+c][1] + f->image[r*w+c][3])>>1;
> >         }
> >     }
> >     }
> >
> > Looks like that what is needed after dcraw call.
>
> Hum, this is want mean that ufraw lib has included dcraw source code and do
> not use an external dcraw instance to decode RAW files. This is not the
> case in digiKam whitch use actually a dcraw program.
>
> This is want mean too, like i have already said before than there is a
> decoding problem with any CR2 file, like your GREN FROGS pictures (:=)))
>
> Nota : i have tried to display GREEN FROGS pictures using bibblepro program
> : the result are the same than digiKam. This is want mean than
>
> 1 / bibblepro use dcraw source code in and CR2 decoding is wrong.
> 2 / or GREEN FROG file is corrupted.
>
> ... but this is strange to find the same result with digiKam and bibblepro,
> especially if bibblepro use an dedicaced implementation non-depending of
> dcraw. Like it's descripbe in this article :
>
> http://users.tkk.fi/~stanhua/rawcomp/
>
> ... bibblepro is dcraw decoding implementation seem to be different.
>
> Gilles
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. 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.

Gerhard



More information about the Digikam-devel mailing list