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:

Quote

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.

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.

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.

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.

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

Quote from: madmanchan

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.

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.

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.

"...FYI, the DNG processing model performs a linearization of the original raw image values followed by demosaicing, then white balance. All of the other image stages follow. So to answer your question, all of the image ops except for linearization (which isn't under user control anyways) happens after demosaicing..."

"...FYI, the DNG processing model performs a linearization of the original raw image values followed by demosaicing, then white balance. All of the other image stages follow. So to answer your question, all of the image ops except for linearization (which isn't under user control anyways) happens after demosaicing..."

Yes, I wasn't precise. As I understand it, "white balance" data has two roles in the Adobe image pipeline. The first role is the usual one, which is to set the white balance of the image, and happens after demosaic, the same as for a "normal" image pipeline. So yes, the white balance operation occurs after demosaic.

However, white balance data may be used before demosaic as well: The second role that white balance has is in an Adobe pipeline is to avoid metamerism, etc, where Adobe use two color matrixes and interpolate them based on the color temperature. That part may/probably(?) occurs before/during demosaic in order to get an accurate measure of distance in color space for use in the demosaic process itself. Assuming they're using a demosaicing technique that needs that. (Big assumption - at the time I wrote the response above, in 2009, I was fairly sure they did. Circa 2012, I'm not nearly as sure.)

Yes, I wasn't precise. As I understand it, "white balance" data has two roles in the Adobe image pipeline. The first role is the usual one, which is to set the white balance of the image, and happens after demosaic, the same as for a "normal" image pipeline. So yes, the white balance operation occurs after demosaic.

However, white balance data may be used before demosaic as well: The second role that white balance has is in an Adobe pipeline is to avoid metamerism, etc, where Adobe use two color matrixes and interpolate them based on the color temperature. That part may/probably(?) occurs before/during demosaic in order to get an accurate measure of distance in color space for use in the demosaic process itself. Assuming they're using a demosaicing technique that needs that. (Big assumption - at the time I wrote the response above, in 2009, I was fairly sure they did. Circa 2012, I'm not nearly as sure.)

Sandy

interpolation between 2 color matrices shall depend on the particular WB that we select in UI, right ?

change in WB by you in UI shall lead to reinterpolation between 2 color matrices in ACR/LR, it can't be a fixed interpolation - can it ?

and demosaick as said by Eric happens before WB, "the usual one, which is to set the white balance of the image", then technically, you need to do the whole stuff again and again when WB sliders are changed in UI...

you need to do matrix multiplication for the whole raw data using a reinterpolated matrix, demosaick and regular WB operation after that for each slider move...

at the same time we have linear DNG (demosaick happened and for example done by genuine ACR algorithm, not by crippled /as Eric said/ DNG converter code) produced by ACR and WB in ACR on that file (linear DNG) gives exactly the same image as WB in ACR on the source raw file... so either there are no reinterpolation or everything is done on demosaicked data.

interpolation between 2 color matrices shall depend on the particular WB that we select in UI, right ?

change in WB by you in UI shall lead to reinterpolation between 2 color matrices in ACR/LR, it can't be a fixed interpolation - can it ?

and demosaick as said by Eric happens before WB, "the usual one, which is to set the white balance of the image", then technically, you need to do the whole stuff again and again when WB sliders are changed in UI...

you need to do matrix multiplication for the whole raw data using a reinterpolated matrix, demosaick and regular WB operation after that for each slider move...

at the same time we have linear DNG (demosaick happened and for example done by genuine ACR algorithm, not by crippled /as Eric said/ DNG converter code) produced by ACR and WB in ACR on that file (linear DNG) gives exactly the same image as WB in ACR on the source raw file... so either there are no reinterpolation or everything is done on demosaicked data.

please tell me where I am wrong, because I probably am.

My understanding circa 2009 from Eric was that yes, if you changed white balance, LR went all the way back to demosaic to rerender the image. Seemed entirely over the top to me at the time, and still does, but I've never seen a concrete example of dual illuminant making any significant different to anything(!). Maybe I misunderstood what Eric was saying.

As regards linear DNG vs raw - the changes would be very, very subtle, only a pixel or two slightly different. The matrixes (should) have no impact on white balance in the sense of warmer or cooler, the changes would just be e.g., in a possibly different choice of vertical or horizontal in the demosaic step.

My understanding circa 2009 from Eric was that yes, if you changed white balance, LR went all the way back to demosaic to rerender the image. Seemed entirely over the top to me at the time, and still does, but I've never seen a concrete example of dual illuminant making any significant different to anything(!). Maybe I misunderstood what Eric was saying.

you mean output from using dual illuminants vs single illumant profiles ? like you have a dual illuminant profile, you manually remove one matrix and voila - not impact ?

As regards linear DNG vs raw - the changes would be very, very subtle, only a pixel or two slightly different.

first of all - how come that very significant changes in WB in UI in ACR/LR will lead to only a pixel or two different and then - I do not see even a single pixel changed... granted I did not run that on thousands of files, but do you have a guess wha are the conditions, target or camera model where that can be seen to have a direct test to see a pixel at least ?

, the changes would just be e.g., in a possibly different choice of vertical or horizontal in the demosaic step.

that sounds a little bit an overkill to use matrices to just make such a binary decision and then - how in the world ACR knows when producing a linear DNG file (means making such a decision before human being) knows which WB we shall end up in UI afterwards (if that selection of WB actually affects the step in demosaicking).

you mean output from using dual illuminants vs single illumant profiles ? like you have a dual illuminant profile, you manually remove one matrix and voila - not impact ?

first of all - how come that very significant changes in WB in UI in ACR/LR will lead to only a pixel or two different and then - I do not see even a single pixel changed... granted I did not run that on thousands of files, but do you have a guess wha are the conditions, target or camera model where that can be seen to have a direct test to see a pixel at least ?

that sounds a little bit an overkill to use matrices to just make such a binary decision and then - how in the world ACR knows when producing a linear DNG file (means making such a decision before human being) knows which WB we shall end up in UI afterwards (if that selection of WB actually affects the step in demosaicking).

I haven't seen a difference between dual and single illuminants in regards of demosaicing, no.

The current ACR/LR demosaic does not depend on the choice of color profile or white balance. (You can check this for yourself; if you change color profiles or white balance, the fundamental demosaic results do not change.)

The purpose of the dual-illuminant profile, like Sandy said, is to deal with different color response of sensors under different illumination. Even such profiles can fail if shooting under a light that is spectrally rather different than the calibration lights (e.g., compact fluorescent vs tungsten). Another approach is to build dedicated separate (single-illuminant) profiles for the illumination conditions you care about, though in your workflow that would mean you would have to select the profile manually. This may not be a practical issue since one can use presets, sync settings, etc. to speed things up.

The current ACR/LR demosaic does not depend on the choice of color profile or white balance. (You can check this for yourself; if you change color profiles or white balance, the fundamental demosaic results do not change.)

that is exactly what you (Eric) said before in quoted post - demosaick happens before any white balance, hence white balance can't affect demosaick by definition... and in such design you do not need to redo demosaicking when you change the WB in user interface... that is much faster and allows things like linear DNG... for example if you produce a linear DNG in ACR from some raw file (does not matter whether it is native in camera DNG or proprietary) then the output using the same version of ACR and any identical WB (and other parameters in UI are identical too) will be same for both conversion from that linear DNG and its original raw file, right ?