Hard-deprecate haze removal?

[kofa73]

Is your feature request related to a problem? Please describe.

This module has been the source of constant issues, surprises when exporting.

Describe the solution you'd like

Not have it available any more for new edits. We have diffuse or sharpen, and one can use other modules to add contrast.

Alternatives

Keep it; maybe add another section to the bug report form to check if haze removal is causing problems; add a huge warning to the manual, saying if haze removal is active, the only way to ensure export matches the darkroom is to have HQ processing enabled both in the darkroom and in the export module. there is no way to guarantee consistency between darkroom preview and export.

[KarlMagnusLarsson]

I am neutral when it comes to alternatives proposed. I do not use the dehaze module.

This module has been the source of constant issues, surprises when exporting.

If we go the other way and file issues and correct them, then I can list recent issue examples:

• "High Quality Resampling" blowing highlights #18378
• https://discuss.pixls.us/t/color-management-issue-for-specific-image/46940
• Crop makes image areas burned-white (haze removal) #17358 (comment) EDIT: Example from @kofa73

[kofa73]

Fixes are unlikely, based on #17358 (comment)

[kofa73]

Changed the description: even HQ does not help.

[jenshannoschwalm]

I am not absolutely sure about the quality of the algorithm, if it is principally/mathematically better than what other modules offer we should keep it and modify the algorithm.

Iirc we currently calculate some "correction data" from preview pipe processed output which is not available while direct export. We could possibly always use those "correction data" from a downscaled image simulating the preview.

[kofa73]

Could the input to calculate params not be taken from the output of the previous module? Then, at least when HQ is enabled both in the darkroom and in the export module, the results would match. Without the HQ setting, only the ROI is available, of course - fall back to the preview, in that case?

[jenshannoschwalm]

The output of previous module is always the input for current :-)

This is absolutely not sufficient as the distance is calculated from full image data (leaving cropping aside). If you look at the code you will recognize there will be subtle differences for full-preview vs full-fullpipe, the area is identical but for the preview we did downsampling before (that's what we use in darkroom) but for exports the data are calculated from not-downscaled. You can also observe those differences for HQ vs non-HQ export, the downscaling happens either in the demosaicer or finalscale for raws, for non-raws we downscale either at pixelpipe input or finalscale.

So in short - for me the downscaling leads to subtly different results. You can also observe that this depends on the interpolator (bilinear less difference than lanczos3 for example).

What we could do for export pipes when having full data- we could downscale exactly as we do for the preview pipes and calculate the distance based on that - to get rid of the differences.

The differences also depend on the colorspace being in, with 5.0 there are improvements but not fully solved.

[kofa73]

Yes, of course the input always comes from the previous module :)

What I meant was the 'auxiliary input', or 'intermediate data', which comes from the preview pipe:

It calculates some intermediate data from all available areas and does some maths using this intermediate stuff. [...]
the mentioned intermediate step happens in the preview pipe iirc

Could that not be taken from the current (darkroom, export) pipe instead? In that case, if I understand correctly, at least with HQ darkroom + export processing, the full image area is available at full resolution, so export would match the darkroom view.