GainMap and highlight reconstruction problem

[paolodepetrillo]

When a GainMap (#10289) is applied in the rawprepare module, pixels which are bright but not clipped may have their values increased so that they are greater than the raw white point. Even though these pixels are valid and not really clipped, the highlight reconstruction module then clips them causing the color to be incorrect. The problem occurs in this smartphone dng image with DT 4.0: example.zip The clouds are not clipped at all according to the raw overexposed indicator, but with flat field correction enabled in rawprepare and highlight reconstruction enabled, an artifact appears.

[jenshannoschwalm]

I had a short look into the gainmap handling code in rawprepare, i guess this is wrong

  for(int k = 0; k < 4; k++) piece->pipe->dsc.processed_maximum[k] = 1.0f;

It was right with scaling for white & black points but not any more.

[parafin]

I don't think this can be handled any other way, because white point is global value for the picture, not per-pixel value. If you raise it, then highlights will be left uncorrected for the central area with gain close to 1. The only solution I see is to split FFC correction from rawprepare and place it after highlight reconstruction module.

[kmilos]

Or you re-normalize the gain so it is not >1.0 (equivalent to pulling in the exposure for the max gain)...

[parafin]

No, it won't solve anything.

[jenshannoschwalm]

Parafin, yes you are absolutely right.

[jenshannoschwalm]

Another way would be to make use of the gain data map to correct in&output in highlights. But not nice code...

[parafin]

I would close this with "won't fix" - this issue is the compromise you get into with shitty lens.

[PeterWem]

Increasing the clipping threshold seems to be the work around.

[jenshannoschwalm]

Increasing the clipping threshold seems to be the work around.

No. Just imagine the gainmap to correct for a vignetting, then you might have values of 1.0 in the centre as clipped and in the corners a clip would be a value of much more.

[jenshannoschwalm]

@paolodepetrillo it would be possible to defer gainmap calculation as a preprocessing step in demosaic though. There are other pre-demosaic modules that might be affceted, i think hotpixels would be one too.

[paolodepetrillo]

I guess it could be moved out of rawprepare into demosaic if necessary, although I really wish I had caught this before the 4.0 release. Now that it's released it has to remain implemented permanently in rawprepare for backwards compatibility?

It looks like the hotpixels module is using the ratio of the pixel to its neighbors rather than the absolute value of the pixel, so it should be ok with GainMap at its current location in the pipeline.

There is another possible fix although it's an ugly hack.. in rawprepare when GainMap is enabled, before applying the GainMap first find all of the clipped pixels based on the white point set in the dng, and set those pixels to a much larger value. After applying the GainMap, rescale so that the max gain applied by the GainMap to a pixel that was not clipped results in a value close to 1.0, and any pixels that had been clipped are > 1.0.

[parafin]

There is another possible fix although it's an ugly hack.. in rawprepare when GainMap is enabled, before applying the GainMap first find all of the clipped pixels based on the white point set in the dng, and set those pixels to a much larger value. After applying the GainMap, rescale so that the max gain applied by the GainMap to a pixel that was not clipped results in a value close to 1.0, and any pixels that had been clipped are > 1.0.

That will result in big jump in brightness at the border between clipped area and neighbour pixels in the center of the image (where no FFC correction is needed). This would be especially bad if any other highlight recovery algorithm is used, because it will skew colors too. To summarize: let's not invent hacks.

[jenshannoschwalm]

Now that it's released it has to remain implemented permanently in rawprepare for backwards compatibility?

I think you have two options:

1. keep the UI setting in rawprepare but defer the processing to demosaic that would be just right. But as some demosaicers need an input range of 0->1 they need proper settings for "processed maximum"
2. no-fix

[parafin]

It's true that you can't just move processing to another module - if there are other modules in-between, then it's impossible to have the same result, so old history stacks will break (produce different result). So code will have to remain in rawprepare. What can be done is to obsolete that option and use it only for legacy edits and introduce the same correction in some other place in the pipe for new edits. Maybe it would have made sense to make it a separate iop, then it's just about moving it. But I'll repeat my opinion - just close this as won't fix.

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions[bot]]

This issue was closed because it has been inactive for 300 days since being marked as stale. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed.