Neue Testversion 18.40b9

[photoken]

What's the third parameter then, in your opinion, besides -Q and -E? The -N option is for the denoising algorithm only.

What RawTherapee calls "False Color Suppression". If that's something unique to RT, then I stand corrected, but it seems that DCB does have an option for de-noise (or false color suppression).

So is 5 always sharper (and slower) than 2, then?

Yes, that's the way I understand it.

Would it be enough to offer "dcb fast (Q=2) and dcb sharp (Q=5)?

I think you've backed yourself into a corner, my friend. If you're willing to accept "0" (the default), and "2", and "5", why not "3" and "4", too?

Or does 5 produce more artefacts as well, and choosing 0 to 5 means trading sharpness for artefacts (and speed)?

Yep, that's the tradeoff that is mentioned. I have not seen any additional artifacts by using 5 as opposed to 2 when the image was shot using ISO=80. With higher ISOs, artifacts might become more apparent, but I haven't done any experiments to see. I think the speed concern is probably irrelevant today -- the author's Web page dates from 2010, and modern processors could very well negate any speed concerns....

[photoken]

And even though you get an idea of the parameters after a while and you "know" how to interpret a difference picture, I often prefer my NeatImage: Let the program look for a sample, maybe give a sample by your own, then some special sliders you know what they do, and you're done.

If you don't mind me picking your brain a little -- since I'm new to RAW processing, I'm wondering if you've found that you need to constantly adjust the de-mosaic parameters for images from your camera.

I've arrived at processing parameters that give extraordinarily good results on test images shot at ISO=80, and I anticipate using those parameters as a "base" that will be used on all images. Is this valid, in your opinion?

[bkh]

What RawTherapee calls "False Color Suppression". If that's something unique to RT, then I stand corrected, but it seems that DCB does have an option for de-noise (or false color suppression).

It doesn't. De-noising is the other algorithm mentioned on the page, completely unrelated to dcb, no false colour suppression.

[

Would it be enough to offer "dcb fast (Q=2) and dcb sharp (Q=5)?

I think you've backed yourself into a corner, my friend. If you're willing to accept "0" (the default), and "2", and "5", why not "3" and "4", too?

I wasn't talking about "0" (frankly, I don't know why it's the default if the author thinks that Q=2 is best), but only about something like Q=2 and Q=5. That's basically what I suggested in the first place:

Maybe one could restrict the choices to something like "dcb quick" and "dcb best" (similar to VNG linear/cubic), with suitably chosen parameters?

Cheers

Burkhard.

[photoken]

I wasn't talking about "0" (frankly, I don't know why it's the default if the author thinks that Q=2 is best), but only about something like Q=2 and Q=5. That's basically what I suggested in the first place:

Well, I'm still unconvinced that offering only 3 iteration choices is better than offering all 5 that are available....

[Hoogo]

And even though you get an idea of the parameters after a while and you "know" how to interpret a difference picture, I often prefer my NeatImage: Let the program look for a sample, maybe give a sample by your own, then some special sliders you know what they do, and you're done.

If you don't mind me picking your brain a little -- since I'm new to RAW processing, I'm wondering if you've found that you need to constantly adjust the de-mosaic parameters for images from your camera.

I've arrived at processing parameters that give extraordinarily good results on test images shot at ISO=80, and I anticipate using those parameters as a "base" that will be used on all images. Is this valid, in your opinion?

I'm not sure if I get your question at all...
I tend to say that VNG is nice for small details, it produces sharp edges, but with some more noce than AHD. AHD on the other hand tends a bit to maze artifacts. I don't regularly check the different algorithms, and I don't take that much pictures at all. But sometimes, maybe for weird experiments, I do it. I had a "real" photo years ago where it would have been a benefit to combine different algos.

And that's what I wanted to say: Sometimes I enjoy all these sliders and properties available in XiDenoiser, but it isn't handy at al for every days work. There also I prefer the comfortable solution.

EDIT:
A very old link, not the latest algorithms:
http://scien.stanford.edu/pages/labsite ... n/main.htm

[bkh]

During the last few days, I've played with dcb and its parameters a bit, mostly using test files supplied by the author of dcb (http://www.linuxphoto.org/html/test_download.html), and compared it to the other demosaicing algorithms available in dcb_dcraw, looking especially at resolution/moiré/aliasing artefacts in the test charts.

My ranking in terms of these criteria would be

dcb Q=2 and dcb Q=5
dcb Q=0
ahd
vng, ppg
linear

I can't see a difference between dcb/Q=2 and dcb/Q=5 (even if I know where the differences are). In particular, I don't see any difference in sharpness/resolution/suppression of artefacts. dcb/Q=0 is only slightly ahead (imo) of ahd.

In terms of noise, I don't think that the -E option offers any benefits – the image loses sharpness, but subsequent denoising isn't any easier.

dcb is significantly slower than any of the other methods – for a 24 MPx image, I have obtained the following timings

2.6s linear interpolation
3.0 ppg
8.2 AHD
10.3 vng
13.4 dcb Q=0
15.1 dcb Q=2
17.5 dcb Q=5

All running times seem to grow linearly with the number of pixels.

I haven't seen an example where dcb Q=5 performs worse than the dcb with Q<5. In view of the relatively small differences in running times, I'm wondering if anything but dcb/Q=5 is needed.

The noisy sample image shows that ahd has a tendency towards labyrinth artefacts in the presence of noise, while dcb/vng/ppg tend towards producing coloured blotches (which may be a bit harder to remove).

In real world images, I haven't been able to spot visible differences between AHD (my preference so far) and dcb/Q=5, so I'll probably keep the default to AHD because of its better performance. However, I'd love to have dcb/Q=5 as an alternative in case of moiré problems.

It would be interesting to test these algorithms on a very sharp raw image on a sensor without antialiasing filter, to see if dcb can extract more sharpness there than ahd.

Cheers

Burkhard.

[photoken]

Burkhard,
Interesting test data. Thanks for sharing it.

My test is using a completely different set of criteria -- a real world scenario with my own camera, the LF1, and RawTherapee. This makes sense for me because it's the camera I use, and RawTherapee will be part of my workflow because of the multitude of processing parameters (and quality) it offers.

• The image was shot at ISO = 80, with the camera mounted on a tripod.
• The focal length was 50.2mm (35mm equivalent).
• The exposure compensation was -0.66EV. (This is my normal setting for the LF1.)
• The image is shot using the "classic" 3:2 picture ratio, meaning that the megapixel size of the image is about 10.8.
• These sample images are screenshots of the image in RawTherapee. For the side-by-side comparison, the RT "default" processing profile was used and only the DCB iterations were changed.

These screenshots were taken at a magnification of 300% (3x the maximum magnification, in terms of printing, that I would ever use). This shows the area of the detail:

detail area.png

The comparison:

DCB comparison.png

The differences are exceedingly slight, indeed. I think there's an ever so slight improvement in definition with the "5" option.

In terms of processing speed, PhotoLine opens the image using AHD in about 4 seconds, and using DCB in about 6 seconds. RawTherapee opens the image in about 2-3 seconds for each, without any obvious difference between DCB's "0" and "5". The difference in times in PL is not important to me. For RT, most of the time required to open the image when I use my custom processing profile is due to applying the various enhancements (such as Chromatic Aberration Correction, De-fringing, etc.); so, again, I'm not concerned with the speed of the DCB de-mosaicking.

And here's what the image looks like when I apply my full custom RT processing profile:

RT pp3.png

So, the bottom line is that I've found a workflow that works for me -- it includes using RT as the most important part of that workflow, with 5 DCB iterations. Insofar as PL is concerned, right now its quality is a little below RT, and I'd like to see what the differences would be if the full complement of DCB options were available in PL.

[photoken]

Hoogo,
Thanks for sharing your thoughts.

That pretty much confirms what I expected to be the case. Since I've arrived at a processing profile that works great for my images shot at ISO=80, I'll use that profile as my default and see if I need to modify it for more extreme images.

[bkh]

So, the bottom line is that I've found a workflow that works for me -- it includes using RT as the most important part of that workflow, with 5 DCB iterations. Insofar as PL is concerned, right now its quality is a little below RT, and I'd like to see what the differences would be if the full complement of DCB options were available in PL.

From the test data I used, it's fairly obvious that PL currently uses DCB with 0 iterations, so changing that to Q=5 should result in the same image quality as RT. For me, the question still remains if we need anything besides Q=5 (and maybe one other value of Q) in PL, given that performance isn't much worse than even Q=0 – if I understand you correctly, then you are normally using Q=5 as well. Do you have sample images where a value of Q smaller than 5 leads to better results than Q=5?

As the author of DCB wrote, DCB has been optimised for speed in RT, so it's not a surprise that it's faster there (if DCB were available at about the speed of AHD in PL, I'd definitely use it as my default).

Cheers

Burkhard.

[photoken]

From the test data I used, it's fairly obvious that PL currently uses DCB with 0 iterations, so changing that to Q=5 should result in the same image quality as RT.

I'm not sure about that. Given that in RT I'm using its CA, de-fringing, sharpening, and micro-contrast controls quite heavily, I think PL will always be a little less "sharp" than RT. Here's where I am so far, with the best I can get out of RT and out of PL. These images are from the sample RAW file available on http://www.photographyblog.com/reviews/ ... le_images/
and are reproduced at 100%. The image is at ISO=80, and 28mm (35mmFormatEquivalent). The images are not screenshots, but are crops of the actual images from each program -- the PLD image in PL, and a 16-bit TIF output from RT. This is the area of the detail:

PL RT detail area.png

and here is the comparison:

PL & RT comparison.jpg

Even though this forum's posting limitations forced me to export the comparison image as a reduced quality JPG, the differences are still apparent. In general, I can get much better "edge management" out of RT. This is the main reason its images are sharper than PL. There is also some colour fringing apparent in the PL highlights at the right center.

For me, the question still remains if we need anything besides Q=5 (and maybe one other value of Q) in PL, given that performance isn't much worse than even Q=0 – if I understand you correctly, then you are normally using Q=5 as well. Do you have sample images where a value of Q smaller than 5 leads to better results than Q=5?

For me, I want all the available options for DCB. Otherwise, it's like telling someone that you'll let them save JPG images only at compression ratios of 0%, or 50%, or 100%....

You're right that I've standardized on Q=5. I have not run into any images where I need to reduce the number of iterations, and that's with images ranging from ISO=80 to ISO=1600. At the higher ISO values, I need to apply significantly more noise reduction (of course) in RT, and that is much more important than any DCB iterations.

As the author of DCB wrote, DCB has been optimised for speed in RT, so it's not a surprise that it's faster there (if DCB were available at about the speed of AHD in PL, I'd definitely use it as my default).

The speeds I noticed are very much in line with what you found, taking into consideration the much smaller MPx images I have. So, for me, the speed difference (in PL) of 2-3 seconds is irrelevant; but with your images, the 10 second difference is certainly something to take into account.

[bkh]

From the test data I used, it's fairly obvious that PL currently uses DCB with 0 iterations, so changing that to Q=5 should result in the same image quality as RT.

I'm not sure about that. Given that in RT I'm using its CA, de-fringing, sharpening, and micro-contrast controls quite heavily, I think PL will always be a little less "sharp" than RT. Here's where I am so far, with the best I can get out of RT and out of PL.

Oh, I was just talking about the results of the demosaicing step. I don't know enough about RawTherapee to compare its possibilites to those of PL.

For me, the question still remains if we need anything besides Q=5 (and maybe one other value of Q) in PL, given that performance isn't much worse than even Q=0 – if I understand you correctly, then you are normally using Q=5 as well. Do you have sample images where a value of Q smaller than 5 leads to better results than Q=5?

For me, I want all the available options for DCB. Otherwise, it's like telling someone that you'll let them save JPG images only at compression ratios of 0%, or 50%, or 100%....

Well, to keep this in proportion, I'd rather say it's like: is it enough to have JPEG qualities of 90 and 95, or do we need 91, 92, 93, 94 as well – on the assumption that quality 95 files are only 20 percent larger than quality 90 files (which they aren't, generally). If there were a lot of difference betweeen the quality steps in DCB, I'd be the first to vote to have them. (And, yes, I think that there are far too many JPEG compression options – but that's a different story altogehter.)

Btw., I've just had a quick look at Raw Therapee: the "False Colour Suppression Steps" you mentioned earlier are applicable to every demosaicing algorithm – probably they correspond to dcraw's "-m" option (not currently available in PL, afaik). Doesn't seem to be very sophisticated (and probably more or less redundant when using DCB's optimisation steps).

Cheers

Burkhard.

[photoken]

Btw., I've just had a quick look at Raw Therapee: the "False Colour Suppression Steps" you mentioned earlier are applicable to every demosaicing algorithm – probably they correspond to dcraw's "-m" option (not currently available in PL, afaik). Doesn't seem to be very sophisticated (and probably more or less redundant when using DCB's optimisation steps).

Yes, that could very well be. Still, if it's there and can possibly help, I'll throw it at my images. Doesn't hurt, as far as I can tell....

[photoken]

Oh, I was just talking about the results of the demosaicing step. I don't know enough about RawTherapee to compare its possibilites to those of PL.

Understood. As far as I know, one important difference between RT and PL is that RT performs its CA correction before the demosaicing. From what I've read, DCB is thrown off by chromatic aberrations and colour fringing. This alone could account for the differences in sharpness between the two programs.

[bkh]

[As far as I know, one important difference between RT and PL is that RT performs its CA correction before the demosaicing. From what I've read, DCB is thrown off by chromatic aberrations and colour fringing. This alone could account for the differences in sharpness between the two programs.

I also read the remark about problems with dcb and CAs, and I've looked for an example where they are visible – so far I haven't seen any. Unfortunately, one cannot correct colour fringing (longitudinal CAs) before demosaicing, so at least that part of the problem remains.

CA correction before demosaicing means that one has to do an interpolation step in the R and B channels before the actual demosaicing, which means loss of information (especially in those areas where the shifted Bayer pixels are 1 pixel away from the original matrix), and I'm slightly in doubt if dcb works so much better then to compensate for that.

In any case, CA correction doesn't affect the image centre, so differences in sharpness there must come from elsewhere.

If RT has a lens database for CAs and can do more than just linear stretching, then it's quite possible that image sharpness is better than in PL outside the image centre due to better CA correction, but I'm unsure if this is because of CA correction before demosaicing.

Cheers

Burkhard.

[photoken]

If RT has a lens database for CAs and can do more than just linear stretching, then it's quite possible that image sharpness is better than in PL outside the image centre due to better CA correction, but I'm unsure if this is because of CA correction before demosaicing.

I know from experience that it wasn't a lens database in my case -- their CA adjustment worked wonders for my LF1 long before RT got any "support" for the camera. You're absolutely right about the off-axis sharpness -- the detail areas I showed as examples were both at least two-thirds of the way out toward the edge.

If I have time, I'll do a test of DCB with and without RT's CA correction.

Edit:
Aha, I found the RT reference I was thinking about:
http://50.87.144.65/~rt/w/index.php?tit ... Aberration
This implies that PL's CA corrections, being after the fact, will always not be contributing to the sharpness of the demosaic algorithm,