Project

General

Profile

Bug #9583

recommended profiled noise reduction lightness & color blend modes undo the highlight reconstruction module's good work

Added by Nicolas Dade about 6 years ago. Updated 6 months ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
-
Start date:
09/12/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Now that the highlight reconstruction module's LCh mode works properly again (thank you), I find a new problem. The values >1.0 (or whatever max L is represented as) which highlight reconstruction in LCh creates get clipped to 1.0 by the recommended blend modes in the profiled noise reduction module (non-local denoise mode + blend lightness, followed by wavelets + blend color). In fact all the blend modes I've tried except 'normal' clip the nice L values created by the highlight reconstruction. Using a parametric mask to keep the profiled noise reduction from altering bright L values or g values doesn't prevent the clipping. Meaning this clipping is happening despite the mask, which is annoying.

In other places in the stack of operations I can reduce the exposure to keep from using max L. But the profiled noise reduction module lives between the highlight reconstruction and the exposure modules, so I can't do that.

So is there a way to allow the blend modes to not clip L values, or probably easier, have the masked out areas not be clipped even though the blend mode would otherwise clip?


Steps to reproduce (in case the above is too complicated to understand):

1) open a raw photo with some need of highlight reconstruction. Something with bright clouds slightly overexposed works well.
2) in highlight exposure module enable highlight reconstruction in LCh space.
3) in exposure module, decrease exposure until nothing is overexposed. this will reveal the nice cloud contours which highlight reconstruction reconstructed.
4) in profiled noise reduction module choose, for example, the recommended non-local means, with lightness blending

and you will see that once step 4 is done (or any other NR mode variant with a blend mode != normal) the nice clouds are flat white again. Switching the blend mode in step 4 to 'normal' and the clouds
are nicely reconstructed again.

IMG_4466.CR2.xmp (7.31 KB) IMG_4466.CR2.xmp Peter Wemmert, 04/16/2019 12:37 AM
IMG_4466.CR2 (24.7 MB) IMG_4466.CR2 Peter Wemmert, 04/16/2019 12:38 AM

Associated revisions

Revision 280af926 (diff)
Added by Ulrich Pegelow about 6 years ago

blending: add blend modes "HSV lightness" and "HSV color"

these two modes are only offered for modules acting in the RGB
color space; the underlying RGB <-> HSV conversions do not need to
clamp their inputs, thus allowing unbound values to be passed through;
should help to fix issue #9583.

History

#1 Updated by Nicolas Dade about 6 years ago

and optional step

5) be clever and think "I will use a parametric mask and keep the profiled noise reduction away from the high L area", try it, and see it does not work either. The clouds remain flat white, even though the mask is supposedly omitting them from the output.

So it seems this clipping of L is happening in all areas, even those masked out.

#2 Updated by Ulrich Pegelow about 6 years ago

Well, what you describe is plausible. Both blend modes, lightness and color, clamp input data to make them fit into the range of values expected by the underlying conversion functions (RGB <-> HSL).

Maybe you are willing to invest some time and find out if in the typical use case you describe non-clamped data lead to reasonable results. In order to test you may just try to deactivate the clamping functions in blend.c:_blend_lightness() and blend.c:_blend_color(). Only the part where cst==iop_cs_rgb.

#3 Updated by Ulrich Pegelow about 6 years ago

  • % Done changed from 0 to 50
  • Status changed from New to In Progress

I added two new blend modes "HSV lightness" and "HSV color". Both do not clamp their inputs allowing unbound values to pass through.
Please give it a try and report back.

#4 Updated by Ulrich Pegelow about 6 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

No feedback. I think the issue is fixed. Please re-open if problems persist.

#5 Updated by Peter Wemmert 6 months ago

I have the issue in darktable 2.6.1. Turn off and on "denoise" and check the highlights.

Also available in: Atom PDF

Go to top