Hey
@usm and
@vjbelle,
I don't think the two problems you've highlighted are the same. I suspect quite the opposite.
On one hand, the problem highlighted by Victor (
@vjbelle), for which the solution is work-in-progress, has to do with clipped highlights.
Clipped highlights completely or partially lose their color information. What I mean is that in the RAW data some or all of the R, G and B adjacent pixels of an RGGB bayer block may have reached the upper bound of the available dynamic (65535 on 16 bit data). When this happens, the original and correct proportion between those color channels is lost, and the original color, when demosaiced, is lost forever. That's not a problem if those areas are kept near the highest stop of the dynamic range, they will be treated as full white by the RAW developers.
Now, if the reference point (actually 4 points, one per color channel) of the applied LCC is too low due to the average mode and ref-point area selected by the user, the resulting processed image may have a lower average brightness than the original one. The clipped values will be lowered down and turn into pink color because, due to the clipping, R and B values are close or even equal to the green ones (usually, R and B are lower than G). There is an excess of R and B and the original proportion cannot be reconstructed because it has never been captured due to the clipping. The more the clipped values are far from the upper bound, the less they are treated as full white by the demosaicing algorithm.
I suspect RAW developers may do some sort of pink-cast compensation on the demosaiced image. I'm only working with RAW data, so I cannot even know which the correct white balance point is to eventually try to reconstruct the different shades of gray in place of the pink areas.
Therefore, the only reliable solution I've found to this issue is to increase the LCC ref point value till the highlights of the processed image are placed at the same level as they were in the original image. The "Ref. Point. Gain (%)" is what needs to be increased. It can be done manually, and now I'm adding an "auto-gain" function to perform this compensation automatically (do not try to increase the Ref. Point. Gain with the current version of HBComposer, there is a bug that may lead to color casts which I've fixed on the upcoming version). A temporary solution you can adopt on the current version is to try different Ref. Point positions and radiuses so that you get a processed image having the clipped highlights where they should be, at the upper bound.
On the other end, I strongly suspect that the problem Mario (
@usm) is highlighting, which I see here for the first time, could be quite the opposite, almost. It seems to me an under-clipping of the G channels of the LCC image (below the black level), which may cause the abundance of the green color in the processed image. Mario, your use case is really difficult to manage, your LCC is really too much compromised. I'm not sure I can do something for this. But, as usual, feel free to send me the images so that I can test and try to understand whether this can be fixed.
Honestly, I am afraid that I have ventured on something bigger than my abilities can handle.
-m
