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 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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
> 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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Le Vendredi 16 Décembre 2005 19:32, Thorsten Schnebeck a écrit :
> > 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? Gerhard, about the broken GREEN FROG pictures, can you take a new one with this subject, because it's very cool (:=))). I love this photo, and i want a new one like this in RAW database ! A nice WE -- Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Am Freitag, 16. Dezember 2005 20.55 schrieb Gilles Caulier:
> Le Vendredi 16 Décembre 2005 19:32, Thorsten Schnebeck a écrit : > > > 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? > > Gerhard, about the broken GREEN FROG pictures, can you take a new one with > this subject, because it's very cool (:=))). I love this photo, and i want > a new one like this in RAW database ! > > A nice WE I don't believe man :-))) hi, hi, it's sitting outside on my balcony covered with snow. I'll see what I can do for you. A+ Gerhard _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Am Freitag, 16. Dezember 2005 21.44 schrieb Gerhard Kulzer:
> Am Freitag, 16. Dezember 2005 20.55 schrieb Gilles Caulier: > > Le Vendredi 16 Décembre 2005 19:32, Thorsten Schnebeck a écrit : > > > > 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? > > > > Gerhard, about the broken GREEN FROG pictures, can you take a new one > > with this subject, because it's very cool (:=))). I love this photo, and > > i want a new one like this in RAW database ! > > > > A nice WE > > I don't believe man :-))) hi, hi, > it's sitting outside on my balcony covered with snow. I'll see what I can > do for you. > > A+ > Gerhard Made a new photo -> ftp://[hidden email]/Images_2_Test_DImg/RAW/frogs.CR2 Gerhard _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from thorsten.schnebeck@gmx.net
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 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 |
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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from thorsten.schnebeck@gmx.net
---- Gerhard Kulzer <[hidden email]> 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. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Le Samedi 17 Décembre 2005 14:35, [hidden email] a écrit :
> ---- Gerhard Kulzer <[hidden email]> 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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by F.J.Cruz
Am Samstag 17 Dezember 2005 14:35 schrieb [hidden email]:
> 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. Hmm, I dont think so. Ok, by now there is nothing better than ufraw in the free software world and of course I'm also using ufraw and not the dcraw kipi converter. But if we compare ufraw and an enhanced digiKam/dimg than this is like comparing Raw Shooter and the PhotoShop RAW plugin. A integrated digiKam module do not need to look like ufraw cause digiKam has powerful plugins that can handle further processing like CMS, white balance, sharpen, gradation etc. Some of this stuff is handled by dcraw command line app and some aspects have still to be ported like a camera white balance which is not part of digiKams current implementation. I believe in Cilles art of programming and it is a good KDE tradition to create the things you need if there is no other "good enough solution" leading to the fame of khtml or KOffice. OTOH if there is something better, drop your code and use an established solution, like the current ksync opensync swap. So its all a question of maintaining. What parts of dcraw need digiKam: - file identification - file loading and decoding - demosaicing and basic postprocessing If Cilles put this all into dimg the whole lib could attract other projects and this could help integrating dcraw updates back into dimg. But this is the critical point. If such a dcraw lib/class fork is not maintainable, better use the original. Everthing above is IMHO ;-) Bye Thorsten _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Gilles Caulier
On Saturday 17 December 2005 11:48, Gilles Caulier wrote:
> 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). FWIW, AFAIU the command line tools are used for speed comparison. So no loops involved this 'benchmark'. So c) stays slow and digikam is even slower. When you optimize 1-3 away, then digikam will be like a) or c) depending on the used options). Achim > > Gilles > > > > > Gerhard > > -- > Gilles Caulier > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [hidden email] _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Gerhard Kulzer
Le Samedi 17 Décembre 2005 10:13, Gerhard Kulzer a écrit :
> Am Freitag, 16. Dezember 2005 21.44 schrieb Gerhard Kulzer: > > Am Freitag, 16. Dezember 2005 20.55 schrieb Gilles Caulier: > > > Le Vendredi 16 Décembre 2005 19:32, Thorsten Schnebeck a écrit : > > > > > 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? > > > > > > Gerhard, about the broken GREEN FROG pictures, can you take a new one > > > with this subject, because it's very cool (:=))). I love this photo, > > > and i want a new one like this in RAW database ! > > > > > > A nice WE > > > > I don't believe man :-))) hi, hi, > > it's sitting outside on my balcony covered with snow. I'll see what I can > > do for you. > > > > A+ > > Gerhard > > Made a new photo -> > ftp://[hidden email]/Images_2_Test_DImg/RAW/frogs.CR2 > > Gerhard OK, thanks. I love it ! -- Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Gilles Caulier
Le Mercredi 14 Décembre 2005 13:35, Gilles Caulier a écrit :
> Le Mercredi 14 Décembre 2005 13:30, vous avez écrit : > > Am Mittwoch, 14. Dezember 2005 09.33 schrieb Gilles Caulier: > > > Le Mercredi 14 Décembre 2005 09:27, Thorsten Schnebeck a écrit : > > > > > > Another problem I have with the RAW cr2 files, when I open > > > > > > them with IE the size is only 1/4, i.e. width and height are > > > > > > half the real size only. > > > > > > > > > > Hum, i suspect a problem with dcraw program and CR2 file. Can > > > > > you trying with dcraw by command line to convert CR2 file to > > > > > PNG for example ? > > > > > > > > > > Another test can be done using biblelabs (www.bibblelabs.com) > > > > > program, witch using dcraw implementation inside to decode RAW > > > > > files. > > > > > > > > > > Nota : i remember a decoding problem with a CR2 file coming > > > > > from you. Do you remember the green _FROGS_ (:=))) : > > > > > > > > > > http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS > > > > >350D.CR2 > > > > > > > > > > Gilles > > > > > > > > Aloha, > > > > > > > > seems to be the "-h" option of the two dcraw commands in > > > > libs/dimg/loaders/rawloader.cpp. Drop the option and you have ful > > > > sized images in IE. > > > > > > 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... > > > The downside is that it is very slow, for my cr2 of 3474x2312 pixels it > > takes 50sec to convert on a 3GHz i386 machine. > > This is a major problem ! We cannot frozen IE during 50 s to display one > image (:=)))... I Finding the solution : dcraw -q (Use simple bilinear interpolation for quick results) give speed results with the right size. I will provide a new IE setup options area for RAW file formats decoding. -- Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Hi Gilles!
> > This is a major problem ! We cannot frozen IE during 50 s to > > display one image (:=)))... > > I Finding the solution : dcraw -q (Use simple bilinear > interpolation for quick results) give speed results with the > right size. I will provide a new IE setup options area for RAW > file formats decoding. Hmm, why speed and not quality? Nobody uses RAW in terms of speed?! "-q" needs a parameter in latest dcraw: "-q [0-3] Set the interpolation quality" So, maybe this could be a loading option like in ufraw? Biliar interpolation is nomally uses in photos with dark areas, where AHD can produce a noise pattern. What about the "-m" flag? IIRC raw files dont support a color mode. Bye Thorsten P.S. Untested, but some compiler options for optimization of dcraw can be found on http://home.earthlink.net/~paul.j.lee/ _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
> "-q [0-3] Set the interpolation quality" So, maybe this could > be a loading option like in ufraw? Biliar interpolation is > nomally uses in photos with dark areas, where AHD can produce a > noise pattern. ...otherwise if you use a simple "-q" this leads to -q 3 in latest dcraw which means highest quality :o) Bye Thorsten _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |