Munsell correction - Lab adjustements

[Beep6581]

Originally reported on Google Code with ID 1359

This patch adds the correction Munsell, to "Lab Adjustements"

Its action depends on the cursor "saturation", "brightness", "contrast" and the "curves"
luminance.
I changed "avoid color clipping" becomes "avoid color shift". This button enables the
correction Munsell

The software part of "vibrancy" is amended accordingly :)

Reported by jdesmis on 2012-05-09 06:48:04

---

• Attachment: munsell01.patch

[Beep6581]

Welcome back Jacques!
Just tried it, however the "avoid color shift" seems to have no effect at all (tried
it with some bigger edits in the Lab curve section). Are You sure it works?
Olli

Reported by oduis@hotmail.com on 2012-05-09 19:43:13

[Beep6581]

Reported by oduis@hotmail.com on 2012-05-09 19:52:02

• Status changed: PatchSubmitted
• Labels added: 4.0, Component-Quality

[Beep6581]

Jacques, thank you very much for working on this. I think this is one of the most important
adjustments that RT can benefit from!

Some feedback: http://minus.com/mw7jExYsu/

Reported by michaelezra000 on 2012-05-10 02:56:59

---

• Attachment: munsell01.patch.jpg

[Beep6581]

Olli and Michael, thank you for your evaluation.

Yes it works, you can see information about the maximum corrections in DEBUG mode (verbose
= true)
On my test image (468 color test chart), the corrections are identical to those obtained
with "vibrance" (with same saturation)

By cons, the correction applied to Munsell "Lab adjustements" only corrects variations
in hue. If saturation is beyond the gamut, she puts the color gamut boundary, which
in some cases will lead to posterization. This is not the case of "vibrance" of which
the algorithm ensures that there is no posterization for saturation.

Reported by jdesmis on 2012-05-10 05:00:59

[Beep6581]

Let's assume the posterization issue gets fixed, do you have a real world image where
the improvements are clearly visible? The special sample images that I hoped for a
better Lab curve rendering because they look unnatural seem to be the unchanged.

I mean, the patch probably increases complexity and probably makes it slower, so for
"raison d'etre" it should have some advantage that is clearly visible on normal images
from my point of view.

Reported by oduis@hotmail.com on 2012-05-10 05:49:05

[Beep6581]

Olli

From my perspective, the first problem to be addressed, which does not relate directly
to 'Munsell Correction "is the control of saturation (the latter being due to the saturation
slider, or contraste, or" curve ", etc.).. I did it for "vibrance", but it is absent
in "Lab adjustements" ... There is work, but it is independent of "Munsell".

I put a real image on my site (a tropical flower).
http://jacques.desmis.perso.neuf.fr/RT/     _ASC5464.NEF

Choose "Profile = neutral"; Choose "Prophoto" as "Working profile" and "Output Profile"
to avoid posterization.
Set as setting "Lab adjustements": Saturation = 49, Contrast = 28 ... and observe the
image when active "avoid color shift"
In this case, it's "Red Yellow correction is operational" (one of the two major corrections)-
and also "green-yellow" but it's less visible.
I have attached a graph of Lab values​​. The pixel "992 - 2322" shows: a) the original
color is on gamut boundary, b) the correction changes the hue
Lab before L=20 a=60 b=35
Lab after  L=20 a=45 b=34

Reported by jdesmis on 2012-05-10 07:13:43

---

• Attachment: flower.jpg

[Beep6581]

Jacques,
I downloaded your test image, made some changes to Lab and compared the images with
and without "avoid color shifts". The colors don’t improve at all it seems, they look
the same to me.

However I spotted a bug: if you look at the highlights in your test image (the light
spots in the upper part) they are clipped and totally white if I enable "avoid color
shifts", while they are green without.

Reported by oduis@hotmail.com on 2012-05-10 08:35:08

[Beep6581]

And yet, there are visible differences:
I saved two TIF, with two versions of RT, one without the patch "Munsell", the second
with the other'4.0.8.31'
Same settings (Neutral, Prophoto, Sat = 49 contrast = 33).
Looking at the two TIF in Photoshop, one beside the other ... we see the differences.
See also histogrammesqui are significantly different.

I do not know if we can talk about bug for "the light spots in the upper part" - it
is the same problem with the current version of RT (without the patch "Munsell"). This
color is out of gamut Prophoto (L = 98 a =-22 b =66), and thus clearing the gamut is
effective. But I expected this case, if you check the "Highlight Enabled reconstruction",
values​​> 65535 will not be reduced

Reported by jdesmis on 2012-05-10 09:40:27

[Beep6581]

Comment on my bad english :
Not "See also histogrammesqui are significantly different."
But "See also the histograms that are distinctly different."

Reported by jdesmis on 2012-05-10 09:44:46

[Beep6581]

I know this is not a real image, however it is used to make profiles and objective is
...
Try my test chart "468 colors" (there are one more chart "C.Metairie" 285 colors)

Use profile "neutral", and all in Prophoto
http://jacques.desmis.perso.neuf.fr/RT/   4029-li.nef

Look the blue, the red-yellow, the blue-purple...

Reported by jdesmis on 2012-05-10 10:55:20

[Beep6581]

I set the settings as you said. With the current build I also checked “avoid color clipping”,
which makes them look very similar since “avoid color clips” also generates blown highlights,
plus some general brightness changes.
But even with these extreme saturation and contrast settings, I see no significant
improvement in color:

http://www.visualbakery.com/RawTherapee/Download/LabMunsell.jpg

Left Munsell. However I can clearly see the severe posterization issues Michael has
reported with the patch (which might explain the small histogram differences ;-).

Maybe I’m doing something wrong here, but to me visually on real world images it looks
like it just make things worse, not better.

Reported by oduis@hotmail.com on 2012-05-10 11:41:02

[Beep6581]

I have been slow to respond, because I was at the beach

I put on my site another photo of flowers.
Try "Profile = neutral", all Prophoto
Lab adjustement = saturation=100

Compare : 
RT without patch and "avoid color clipping"
RT with patch and "avoid color shift"

The difference I think is important, especially in blue-purple and red
http://jacques.desmis.perso.neuf.fr/RT/   colorspace_flowers.pef

Reported by jdesmis on 2012-05-10 15:32:13

[Beep6581]

I'd love to get back into south France weather for beach, it's raining here in Hamburg
;-)

Tried it the other sample, but apart from Saturation=100% being unrealistic in real
world, it just causes shadow clipping. So while it seems that the purple flower is
a tiny bit different, it is just clipped out, and you see different clipping effects,
not color corrections.

As soon as I set the saturation back to e.g. 30 (where it doesn't cause clips), the
images are indistiguisable (except from the open posterization problems of the Munsell
patch maybe).

Come on Jacques, if we are already discussion about finding any very special image
with unrealistic extreme settings to see any difference at all, there is probably something
wrong.
Maybe just search for the posterization bug. If you find it, maybe it's the same bug
that causes the colors not to be corrected, who knows...

Reported by oduis@hotmail.com on 2012-05-10 16:02:09

[Beep6581]

I do not think there is a bug "posterization" in the patch ...

By cons, "Lab adjustements" fails to address the extreme values​​.
The algorithm "Munsell" is exactly the same as "vibrancy" (for color correction), that
you are getting very good!

In "vibrance" there are four things that differ from "Lab adjustement" (without patch)
* Saturation according to the hue and luminance
* Control the gamut that preserves hue
* Control of saturation according to its RGB value to never exceed the gamut (posterization)
* Correction Munsell for chroma

I introduced an amendment to control the gamut in order to preserve the hue (the same
that "vibrance", you can change it in "option": gamutLch = false, but from my point
of view, results are less good.

Reported by jdesmis on 2012-05-10 16:18:49

[Beep6581]

Let's just stay with the LAB (which is obviously the big new addition), before we move
over to vibrance.

I do not have a problem that the clipping is handeled differently (I would not say
"better", since without "avoid color clipping" the normal RT handles highlights obviously
better judging from your first test image), but it doesn't do what it says it does,
avoid color shifts. It has no effect on real world image at all it seems.

Plus the posterization problem cannot stay that way, regardless if it is a bug or a
general limitation. We're proud to be floating point with seamless and smooth colors,
and that posterization bug/limitation would set us back to integer times. And these
negative effects ARE easily visible.

Reported by oduis@hotmail.com on 2012-05-10 16:31:16

[Beep6581]

Tomorrow I will be absent, I will spend the day in Nice and eating out "Place du Gesu"
:)

Reported by jdesmis on 2012-05-10 17:26:24

[Beep6581]

Oh, have fun! Nice place when I visited there, the church de gesu is pretty tight up
within the streets, good demonstration of RTs shadow/highlight qualities  :-)

Reported by oduis@hotmail.com on 2012-05-10 17:35:34

[Beep6581]

Is the 'blue turns purple' problem get addressed when saturation is increased?

Reported by ejm.60657 on 2012-05-10 20:06:30

[Beep6581]

There is visible posterization, visibility depends on the working profile:
sRGB: http://i.imgur.com/NHl03.jpg
AdobeRGB: http://i.imgur.com/EM9sg.jpg
Prophoto: http://i.imgur.com/juVVi.jpg

On the positive side, it improves the red flower's petals and the shaded parts of the
purple flower:
http://i.imgur.com/FRicy.jpg

Same comparison with an unpatched RT:
http://i.imgur.com/DZjAl.jpg

There is a small hue change in the green leaf. In the patched RT, the green leaf is
a bit warmer; in the unpatched RT its a bit greener ("after" view of course).

Differences in the petal with purple spots on a white background:
Patched: http://i.imgur.com/LrwjU.jpg
Unpatched: http://i.imgur.com/QyXLv.jpg
Highlight reconstruction "Blend", amount "30" in both.

Reported by entertheyoni on 2012-05-10 21:21:51

[Beep6581]

Notice the significant difference in the white lobe top-left in the last two screenshots
above. In the patched version the lobe is white with a tinge of purple, as it should
be. In the unpatched version, it is an ugly greenish shade of white.

Though I know nothing about color compared to you, I do prefer the patched version
if the posterization issue can be fixed.

Reported by entertheyoni on 2012-05-10 21:30:06

[Beep6581]

DrSlony, you have also change the Lab curve in the shades, which leads to shadow clippings,
see comment 13.
Enable the clipping indicators (esp. shadows here) and make sure it's all clean, otherwise
you just see clipping problems, not color shifts.

But agree that posterization is a severe issue.

Reported by oduis@hotmail.com on 2012-05-11 05:19:17

[Beep6581]

Dr Slony

Thank you for your tests.
Before I left all day in Nice:
1) can you post the file "raw" where you find the posterization
2) did you test with the version of RT without patch ?

Emil
In the raw "colorspace_flowers.pef", the 'blue turns purple' problème is adressed when
saturation is increased.If I proposed to put saturation=100, is to highlight this problem

Reported by jdesmis on 2012-05-11 05:47:42

[Beep6581]

Jacques, does this patch implement color shift corrections in out of gamut areas only?

My observations:
1. when using L channel adjustments only (no saturation) the avoid color shift seems
to have impact on clipped range only

2. when boosting Lab saturation (no L changes) the avoid color shit seems to have some
impact in non clipped areas as well

When editing skin tones with L curve there is a problem of skin getting a  color shift
to purple & red in darkened areas. 'Avoid color shift' has no effect there, but that
would be very desirable.

Reported by michaelezra000 on 2012-05-12 16:14:17

[Beep6581]

Michael

We must understand the principle of “Munsell Correction”
First, there are three (four with green) areas where the correction is clearly visible,
which depends on the luminance, and obviously chrominance :
* Blue-purple (between 5PB and 10PB) 
* Red-yellow (between 10YR and 5R)
* red purple ( 10RP)

Of course there are other sensitive areas, but with differences less visible (blue
sky, green,…).
I set up Lutf (195), for about 70% of all Munsell colors. For the remaining 30%, the
corrections are small and not visible, and I don’t make correction.

There are two ways - which can be combined - to bring a change of color (hue):
1) a change in the saturation (chromaticity in Lab mode), more or less. In the "BP
zone", this can lead to a correction of 0.45 radians, which is very important and very
visible. This is "possible" when the chromaticity varies from +-100, which is very
rare but can occur and bring the colors out of gamut, which depends of course of the
« working profile ». Corrections are commonly observed from 0.05 to 0.2 radians  (0.1
radians =>DeltaE94=3.5; 0.2 radians => DeltaE94=8; 0.05 radians=> DeltaE94=2  which
is the usual limit visible, although some may see differences if deltae94=1)

2) a significant change in luminance, which will also bring a maximum correction of
about 0.40 radians (slider or curve). For example "tonemapping" can lead to very strong
variations of luminance (in this patch “tonemapping” is not corrected). Corrections
are commonly observed from 0.1 to 0.3 radians.

All colors (in the 70%) are concerned, in or out or close the gamut, or neutral. Obviously
the maximum corrections are for data near gamut or near neutral tones.

You can get an idea of this correction by consulting the file on my site on "Vibrance".
Of course "vibrance" has other characterstics not included in  "Lab adjustements" 
(skintones,  saturation for every color, etc.) http://jacques.desmis.perso.neuf.fr/RT/vibrance2.html

Of course it is possible to modify "Lab adjustements", to incorporate something else
(skin tones, etc..), But it will slow down the code, the more complex ... and this
is to put the code of vibrance in "Lab adjustements" !!

I will briefly describe the process (which is somewhat different from that of "vibrance"):

1) First (and this was also necessary with UPLab!), I convert the data Lab to the "working
profile". This conversion is done to "hue" constant. 
2)Then I make a correction Munsell data, due to the change in chromaticity conversion.
3) I save the data L and C (luminance and chromaticity) before any action  (saturation,
brightness, curves, ...)

4) Then performs the saturation, brigthness, curves,...

5) I converted the data Lab, to "working profile" still mode Lch to preserves the hue.
If you check "highlight reconstruction", the control of the gamut is only on negatives
RGB values . Optionally, you can choose the conversion "gamutbdy". (in “option” : gamutLch=false)
This is good, but does not guarantee the preservation of hue.

6) Then applying the correction Munsell (chrominance and luminance). by comparing the
new data to those saved

You can see the maximum values of these corrections (BG, RY, GY, RP) in "DEBUG" (verbose=
true), and the number of iterations needed to convert data in the gamut.

There is a bug in the original (unpatched) of "Lab adjustements". “Satcurve” and “Satfactor”
give wrong data - which normally should be between 0 and 1 - are truly negative or
greater than 1. This leads to strong artifacts - that may give the posterization. I
made a fix, by deleting "satcurve" and replacing by a linear function. I do not know
how to change "satcurve" - if anyone can do it would be nice, but is it necessary?.
I mentioned this bug in the code patch (Munsell01.patch)

I have attached the new patch, which has the difference with the previous one, only
on the initial code of "Lab adjustement" (satfactor ==> factor). But I don’t say there
is no bug in the patch !

Reported by jdesmis on 2012-05-13 09:44:33

---

• Attachment: munsell02a.patch

[Beep6581]

Jacques, thank you for detailed explanations.
Here is another set of observations for munsell02a.patch which illustrates areas where
I see success of the correction and also still present posterisation problem with rough
tonal transitions after correction.

In test below working and output profiles are ProPhoto.
My monitor profile is 93% Adobe RGB, jpg screenshots below are in Adobe RGB.

http://www.michaelezra.com/Projects/RT/images_shared/munsell02_01_aRGB.jpg
http://www.michaelezra.com/Projects/RT/images_shared/munsell02_02_aRGB.jpg

Reported by michaelezra000 on 2012-05-13 14:26:59

[Beep6581]

Aside from the posterization problem, are these areas where with the difference shadow
clipped when output is noICM/sRGB (the problem we chatted about yesterday)?

Reported by oduis@hotmail.com on 2012-05-13 15:08:38

[Beep6581]

Here is illustration:
http://www.michaelezra.com/Projects/RT/images_shared/munsell02_03_sRGB.jpg

Reported by michaelezra000 on 2012-05-13 15:24:43

[Beep6581]

Thanks Michael, so if I understand you screens correctly it is probably still just a
different reaction to clipping but not a color shift correction.

Reported by oduis@hotmail.com on 2012-05-13 15:30:40

[Beep6581]

Thank you for your evaluation ...
I made ​​a small modification, which may limit perhaps the "rough", but I can not recreate
the facts!
If you still have the problem, can you send me the original file (RAW, ...)

For cons, I quickly made ​​a simple modification for "protect skin tones"  :)

Reported by jdesmis on 2012-05-13 15:35:57

---

• Attachment: munsellskin01.patch

[Beep6581]

Hi Jacques,
you can repro it with your own test image, see comment 11.

Reported by oduis@hotmail.com on 2012-05-13 15:38:05

[Beep6581]

Olli, yes, it appears that color changes are mostly (not sure if entirely) in the clipped
areas.

Jacques, thanks, I will try munsellskin01.patch 

Reported by michaelezra000 on 2012-05-13 15:42:20

[Beep6581]

Can you try, this patch (slight modification)

Reported by jdesmis on 2012-05-13 16:27:55

---

• Attachment: munsellskin02.patch

[Beep6581]

in munsellskin01.patch I still saw the posterization.
Protect skin tones removes saturation from skin tones, but transition between colors
which are considered skintones and not is rough.

I will test munsellskin02.patch 

Reported by michaelezra000 on 2012-05-13 16:53:58

[Beep6581]

munsellskin02.patch :
posterization seem to be gone in skintones, but I see them in Olli's example in comment
11 still.

The rough transitions for the areas affected by protect skin tones is still here -
you can actually see it in the red areas of the raw files in comment 11 (using preview
modes for individual channels)

Reported by michaelezra000 on 2012-05-13 17:58:09

[Beep6581]

Here a new patch :
* no changes for Munsell
* best transition for "skin"

At tomorrow :)

Reported by jdesmis on 2012-05-13 18:06:03

---

• Attachment: munsellskin03.patch

[Beep6581]

I had a limited time to test, but the rough transitions are still there... 
Is there any way to change LUTs into a fitted smooth curve to solve this?

Reported by michaelezra000 on 2012-05-14 02:43:16

[Beep6581]

Jacques,
It seems that there are many patches, but they just seem to be fine tuning, but no
solutions yet.
Could you come back with a patch when the two main problems are really solved:
- No effect in normal, non-clipped sRGB color range
- posterization/rough transitions

Testing also takes a lot of work time, and it's kind of ineffective to test a flurry
of patches that offer no real solution to the two main problems anyway.

Reported by oduis@hotmail.com on 2012-05-14 04:58:15

[Beep6581]

This new patch :
   1. take care of the knowledges acquired from the preceding patch (comments, bugs,
disfunctions)
   2. brings new functionnalities
   3. brings a complement to Vibrance

In detail :

1) Acquired knowledges :
   A priori (to be verified) :
      * the "Munsell" correction doesn't create artefact anymore;
      * the reds and skins correction doesn't create solid colors or artefact in the
transitions anymore;

2) new functionnalities (from the current "lab adjustements" tool):
   a) the "saturation" algotithm has been completly reworked, and use a new vocabulary :
      « chromaticity »  (specific of the Lab mode). 
      For the record, the saturation is an RGB concept, and for a given saturation
value (e.g. 0,6), the rendering will be different in the sRGB and ProPhoto color space.

      Saturation values always goes from 0 up to 1 and traduce the proximity off the
gamut.
      The chromaticity is specific to the Lab mode (and its derivative Luv, Lch, …).
      A given chromaticity will render the same rendering (provided that the output
device is capable of rendering the color correctly whichever colorspace has been selected).

   b) the saturation limiter has been replaced by a reds and skins tones control

   c) I've replaced "avoid color clipping" by "avoid color shift":
      * beyond the vocabulary, the gamut control algorithm is different, not that the
algorithm is wrong, but:
      * i'm not sure that it corrects the gamut with a guaranteed constant hue (necessary
for the Munsell correction)
      * it doesn't allow to dissociate the out of gamut negative values from the one
above 65535. The later one must be controlable when "higlight reconstruction" is activated
      * in some cases, some of the negative out of gamut values (RGB) aren't brought
back in the gamut
      * optionnaly (in the « options » file), it's possible to choose the gamut control
algorithm: GamutLch=true ==> new algorithm; =false==> actual algorithm)

      * activating "avoid color shift" enables a gamut control then the Munsell correction
which correct hues for chromaticities and luminance variations
      * the 2 most concerned colors (most visible change) are « blue-purple » and « red-yellow »

   d) 2 curves (the labels has been adapted by Hombre… as well as GUI functionnalities
and optimisations – thanks for his work !) has been added, they allow chromaticity
control:
      * the first one modify chromaticity depending on chromaticity (« Cc »); they
allow, somewhat likely to the « Vibrance » tool but less finely, to modulate the saturated
and pastels tones
      * the « parametric » type curve has 4 sub-ranges to modulate the neutral, dull,
pastels and saturated tone – it seems like to the « tone curve », but it works on chromaticity
      * the second one modify the chromaticity depending on the hue (« Ch »); it will
allow to e.g. accentuate the blue of the sky or reduce the green of the leaves – of
course preserving the hue

3) Moreover i've took the occasion of this patch to provide additional functionnality
to « Vibrance ».
   It concern the marginal modification of the skin tones (the actual version allow
saturation modification only)
   I've chosed a Diagonal curve, as it looks to be the most appropriated. This H=f(H)
curve only concern skin tones with hue values between -0,1 radians and +1,6 radians
only
   Four zones (parametric) let you modify skin tones: Red-Purple (rare); Red (rather
frequent); Red-Yellow (the most frequent); Yellow (rare) 
   The corrections are necessarilly slight, and i've voluntarily reduced the curve's
sensibility.

Reported by jdesmis on 2012-07-09 06:16:16

---

• Attachment: munsell07-09a.patch

[Beep6581]

additional information:
This patch is not completely finished. Tracking in color curves "hue" is temporarily
disabled. The correction will be made within days by Hombre.
This patch is primarily used to test the algorithms and features. :)

Reported by jdesmis on 2012-07-09 09:00:43

[Beep6581]

compiling:)!!!

Reported by michaelezra000 on 2012-07-09 10:39:01

[Beep6581]

Jacques, thanks for coming back with such substantial toolset!
Question:
- Would it be possible to extend the red and skin control to the CC curves as well?

Suggestion:
- When BW toning is enabled, Avoid Color shift should be grayed out and not effective.

Reported by michaelezra000 on 2012-07-09 11:09:13

[Beep6581]

Another question - (may be a separate issue/patch?)
Would it be possible to add a checkbox or a slider (similar to red & skin control)
 that would prevent change of the perceived *saturation* when L is adjusted. Currently
when tones are darkened they appear more saturated and when brightened - less saturated
(not due to this patch of course). 

Reported by michaelezra000 on 2012-07-09 11:16:15

[Beep6581]

Hello Jacques,
Thanks for the efforts, also to Hombre.
On the positive side the new patch seems to cure the banding issues, at least haven’t
notice any on quick tests.

However the other problems seem to remain:
In non-clipped sRGB colors (the 95% case) I cannot see any difference when “avoid color
shift” is activated. It does not seem to be effective at all.
Here is a test image for the classical “blue turns purple” Lab color shift that needs
to be remedied:
http://www.visualbakery.com/RawTherapee/Download/LabBlueTurnsPurple.png
Just open It neutrally and reduce Lab saturation by e.g. 50% and you can repro the
Photoshop values on the original patch (I just converted it from http://www.colormancer.com/whitepapers/lab-color-space/is-LAB-useful.htm).

In clipped regions the issues like washed out whites in highlights remain it seems,
but that’s not the key at first. The core problem is that it still does not avoid color
shifts at all it seems.

Reported by oduis@hotmail.com on 2012-07-09 12:12:41

[Beep6581]

@ Olli

In improcfunc.cc, replace the commented out text by "|| saturation!=0". This will apply
Munsell when the Saturation slider is different from 0. I don't know why it has been
commented out thoug.

For me, and with this little correction, this patch works great! What's the problem
with washed out whites in highlights? Could you provide a test case?

Reported by natureh.510 on 2012-07-09 14:35:45

[Beep6581]

Sorry, forgot to mention: modify line 772 in improcfunc.cc.

Reported by natureh.510 on 2012-07-09 14:36:44

[Beep6581]

Thanks Hombre, that fixed it (why was it commented out?).

Looks GREAT now, merci!  :-))

As for the highlights problem: if you take the image from #6, and pull up the saturation,
the clipped areas become white if you check "avoid colorshifts"

Reported by oduis@hotmail.com on 2012-07-09 15:52:06

[Beep6581]

Excuse me, but I've been away this afternoon :)

The problem of highlights which turn white, which is a typical problem of controlling
the gamut: any value greater than 65535 are reduced to 65535 (with relative colorimetry...)

If you see the current version of "lab adjustements" you will see that there is no
means for leaving these values​​ > 65535.

I changed the control algorithm of the gamut so that it always acts for negative values​​,
and for values​​ > 65,535, if the box "highligth reconstruction" is not checked, the
values ​​are reduced to 65535, if the box is checked the value > 65535 are preserved.

Reported by jdesmis on 2012-07-09 16:10:31

[Beep6581]

Thanks, enabling highlight reconstruction really fixes that one.

Looking at the code, are you sure that the default(shared) definitions in ipvibrance.cc
L1907 are correct? I would have expected vars like LL, CC etc. be declared inside the
loop or private.

Reported by oduis@hotmail.com on 2012-07-09 16:46:36

[Beep6581]

Oh, that white higlights :)!

I'd like to keep this feature, because it's the best way to have images looking like
what my Pentax K-5 produce. Use the "CIELab" mode with HL Reconstruction enabled to
get back colors in these areas.

Reported by natureh.510 on 2012-07-09 17:12:36

[Beep6581]

depass is stated in "reduction" for Debug mode, but should be stated ni "firstprivate"
for release, you're right. I'll make that change and check other OMP pragmas too.

Reported by natureh.510 on 2012-07-09 17:16:30