Seeking DNG SDK Assistance, ...for a new image processing project Options

[Jonathan Wienke]

Accepting for the moment what you are saying, all it demonstrates is the particular set of choices Adobe has made. If you think that the programming of ACR is optimal for image quality, I've got news for you. Many choices for the programming of ACR seem to be made to fit an overarching philosophy of speed of processing and convenience, rather than IQ.

Your examples to demonstrate this assertion haven't exactly been overwhelmingly persuasive. As a counterexample to the church tower, I give the baby's hair in my RAW; there's no color artifacting in it anywhere.

BTW, there appears to be a gaping hole in your mathematical argument:

If the data is not white balanced, then AHD is interpolating RAW data with chromaticity G-B/c. If c is large and G~B ie approximately gray, AHD is trying to interpolate data that looks to it as though the chromaticity is very large and rapidly varying across edges.

IOW, if B/c is much smaller than G, then color artifacting is inevitable, and this must be avoided by applying WB to the RAW data prior to demosaic to keep B/c as close to G as possible. You're ignoring the possibility that there can be a large variation between the scaling of color channels even when the desired WB is selected. if your assertion is correct, if you do not choose a perfectly neutral white balance (perhaps to enhance the character of the light in a sunset image or retain the colors of the stage lighting at a concert), then high-contrast-edge color artifacts will become a problem in direct proportion to the non-neutrality of the selected WB setting. Setting a deliberately "wrong" WB is no different than deferring the selection of the "right" WB until after demosaic. And shooting subjects with highly saturated colors (such as a blue flower or red laser beam on a neutral black background) can result in edges and fine details where adjacent Bayer pixel values diverge widely in the manner you described in your example, even if the RAW data has a perfectly neutral WB applied.

(G-B/c) is going to fluctuate just as much when B is small and c~1 as when G~B and c is "large". If your demosaic algorithm requires WB to be done first to avoid situations where B/c diverges greatly from G, it's going to have major problems handling situations where B/c is small and G is large even after WB. Any strategy you employ to avoid color artifacting in this instance can also be used to make pre-demosaic WB unnecessary.

[deja]

ACR does a lot of smearing of chroma data to cover it up; that smearing starts to fail in the presence of noise, which one can see in any high ISO conversion of ACR 5.x and before.

do you see that corrected in LR3B (and ACR v6.x when released) ? there will be new DNG converter by then too, may be w/ changes.

[ejmartin]

do you see that corrected in LR3B (and ACR v6.x when released) ? there will be new DNG converter by then too, may be w/ changes.

I've only played with LR3ß a little; what I've seen so far looks to be a substantial improvement over previous versions of Adobe's conversion engine. High ISO in particular looks a lot better, especially the chroma blotching is gone.

[joofa]

I must stress that adhering to strict theory is not always the goal in industry. The more important issue is that the image looks pleasing to eye even if violates some linearity considerations, etc. Color correction via CCMs is done frequently on non-linear (gamma-corrected) data with coefficients that are derived from linear theory as it offers some advantages in color fidelity near saturated colors. IIRC even some SMPTE specs have "incorrect" coefficients and perhaps primary placements for such reasons and historic considerations.

[GLuijk]

Open Bridge.

Select a RAW.

Open RAW in ACR.

Click the Save button.

Select DNG as the output format.

Check the linear option.

Jesus, I had no idea my Bridge could do DNG conversions, either with and without demosaic. Good to learn new things. I am quite surprised ACR didn't generate colour artifacts when doing a non white balanced demosaicing since I always thought it was based in the AHD algorithm. However it seems to produce less sharp results:




Anyway Jon I think there is no need to be so agressive in some of your comments to Emil's points. We are all enjoying and sharing information.

Regards.

[ejmartin]

I suspect the DNG conversion in Bridge is the same as in DNG Converter stand-alone, in which case Eric gave the answer above:

Hi Sandy, yes, you are right: the DNG SDK only has a simple bilinear interpolation demosaic routine implemented. (We have been meaning to update it with something more serviceable, but have not worked that into the already rather-packed dev schedule ...)

That would explain why it's softer. Now, bilinear interpolation isn't exactly a linear operation, but to the extent that it is WB before or after wouldn't matter since linear operations commute with rescaling operations. Also, one would have to know the internal workings of a converter to know whether WB is being done before demosaic -- who's to say that the WB multiplier isn't applied and then undone after demosaic, so that you are free to WB afterward in ACR/LR? Well I suppose Eric could say...

I was incorrect before in suggesting that doing WB before demosaic would require redoing demosaic every time the WB is changed. There is presumably an optimal value, that one can apply and then un-apply afterward, then the WB slider can act on un-WB data that has had the optimal demosaic, that need not be redone.

Jonathan, there is a difference between the WB multiplier, which is a constant, and the RGB mosaic data, which is varying across the image.

[sandymc]

I suspect the DNG conversion in Bridge is the same as in DNG Converter stand-alone, in which case Eric gave the answer above:




That would explain why it's softer. Now, bilinear interpolation isn't exactly a linear operation, but to the extent that it is WB before or after wouldn't matter since linear operations commute with rescaling operations. Also, one would have to know the internal workings of a converter to know whether WB is being done before demosaic -- who's to say that the WB multiplier isn't applied and then undone after demosaic, so that you are free to WB afterward in ACR/LR? Well I suppose Eric could say...

I was incorrect before in suggesting that doing WB before demosaic would require redoing demosaic every time the WB is changed. There is presumably an optimal value, that one can apply and then un-apply afterward, then the WB slider can act on un-WB data that has had the optimal demosaic, that need not be redone.

Jonathan, there is a difference between the WB multiplier, which is a constant, and the RGB mosaic data, which is varying across the image.

I think that what Eric was saying is just that demosaicing in the DNG converter is not the same as ACR or bridge.

Re the white balance question, it depends on how you're doing white balance. AHD type algorithms are dependent on being able to measure "distance" in color space. If your change to white balance changes distance, then yes, you have to do the demosaic again, at least in theory. Eric has stated in the past that ACR/LR does NOT run a a AHD algorithm. Although what that means isn't too clear - there is a school of thought that ACR/LR runs a AHD derivative, but in a non-RGB space. I don't think there's much evidence one way or the other, but that would explain why ACR/LR is subject to maze type artifacts. However, we do know that in an Adobe workflow, white balance is before demosaicing - that's why a DNG has two color matrixes.

Sandy

[Jonathan Wienke]

Jesus, I had no idea my Bridge could do DNG conversions, either with and without demosaic. Good to learn new things. I am quite surprised ACR didn't generate colour artifacts when doing a non white balanced demosaicing since I always thought it was based in the AHD algorithm. However it seems to produce less sharp results:

I'm not excessively concerned about getting perfect sharpness directly after demosaic as long as there aren't any color artifacts and suchlike; the goal of the deconvolution I'm doing is to correct the sum of all blurring from the lens, AA filter, and RAW converter combined.