Support for artistic tone curves in DCPs

[Beep6581]

Originally reported on Google Code with ID 1527

DCPs may contain tone curves. These are purely artistic and not part of the color calibration,
so disabled for RTs own profiles (most of them don’t contain one anyway, but for backward
compatibility with a few of them).
This patch adds support for those tone curves. Obvious use cases are DCP profiles that
try to mimic camera makers rendering.

Here is a sample of a Nikon D700 with normal, color correct rendering (right) vs. Adobe
profile that tries to mimic the "Nikon Portrait" camera setting rendering (left). Both
are full neutral in RT:

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

Note how the Nikon Portrait profile adds more contrast, brightness and colors by default.
The advantage over e.g. the hacked Nikon ICC profiles is that you got full precision
and full highlight recovery. Plus there is a very wide range of mostly Nikon and Canon
camera mimic profiles available for free from Adobe.

The downside is that Adobes tone curve method does not contain all the fancy tricks
like "avoid color shifts" that RTs tone curves can do. So it’s NOT recommended to move
the curves to the profiles but use RTs ones, except you want to use those existing
profiles.

Reported by oduis@hotmail.com on 2012-08-17 13:05:58

[Beep6581]

Thanks for this ultra quickly developed feature, but i still don't see the difference
between strongly modified DCP tone curve (exported from DNG Profile Editor) and the
embedded profile. Do we have to enable something in the GUI?

Also, does the DNG raw file embeds TagProfileToneCurve? If so, will it be used too?
(i guess no by looking at the code)

Reported by natureh.510 on 2012-08-17 21:48:42

[Beep6581]

Correction: it seems to be applied to profiles that integrate a color table (i.e. the
one based on the Color Checker 24). This kind of DCP profile has a size of ~24kb, while
those that doesn't work has a size of ~1-2kb even if they (should) include a tone curve.

Maybe I only need to read DNG Profile Editor's documentation...

By looking at the code, i guess we'll be able to make that optional if we want it?

Reported by natureh.510 on 2012-08-18 02:45:17

[Beep6581]

Olli, thanks, this is a great feature, I will experiment tomorrow.
Interesting tricky logic in ApplyToneCurve and RGBTone, I wonder, what is behind it?
In current RT's RGB tonecurve skintones become "dirty" when curve darkens colors. Are
these tricks possibly correcting for such effects?

Reported by michaelezra000 on 2012-08-18 03:20:37

[Beep6581]

Good morning Hombre,

Yes, it's currently applied at the end of the LUT processing. Do you have a sample
profile without LUT? Then I'll change it so it's always applied.

Do You think an additional checkbox "Enable DCP tone curve" is really needed? It's
already auto-disable for RTs own color correct profiles, and the DNG editor is where
you should define the look (or disable the tone curve).

@Michael: That's Adobes reference implementation we may not change that, because the
rendering would change, hence the effect of the profile.

Reported by oduis@hotmail.com on 2012-08-18 06:05:11

[Beep6581]

Hombre, I don't know how you generated such a DCP, but here is a patch that for sure
also takes the tone curve if you just have a matrix + tone curve, and no LUT.

> Also, does the DNG raw file embeds TagProfileToneCurve? If so, will it be used too?
While it technically can be embedded, I never saw one. Usually you want to keep the
calibration in a seperate DCP.
Neither LUT nor Tone Curve are read from a DNG currently, only the simple matrix (which
does not go through RTs DCP engine anyway, read from DCRAW).

However a DNG should be read like a DCP, so you should be able to select a DNG as profile
file. Should I enable that in the GUI? (currently only accepts .DCP)

Reported by oduis@hotmail.com on 2012-08-18 09:46:16

---

• Attachment: DCPToneCurve03.patch

[Beep6581]

Patch works great!
Since DCP can be embedded into DNG and RT can read DCP from DNG - sure, why not allow
it!
About Adobe reference implementation - I did not mean to change it, just curious what
does this logic really do.

Reported by michaelezra000 on 2012-08-18 12:21:08

[Beep6581]

BTW, I just noticed that we have some inconsistencies in packaged DCP profiles.
Xrite tool does not seem to allow to choose the tone curve, so I build profiles with
Adobe's DNG profile editor. 
All my custom DCP profiles are about 54KB - with linear or other tone curve.
Majority of RT's are only 1.5KB.
Pentax K10D, Sony SLT-A55V and the recent D800 profiles are 54KB but they have a non
linear tone curve.

Although it is a pretty quick shortcut to use a nice tonecurve within DCP, I suppose
it is better if we stick to a linear curve by default. So, if we provide DCPs with
a base tone curve, it would be helpful to have a checkbox "Linear tonecurve" in UI
(checked by default), so the same profile file could be used for two purposes - with
linear curve and with the base curve.

Reported by michaelezra000 on 2012-08-18 12:40:15

[Beep6581]

There is also a small Pandora's box - new DCP profile by Adobe are v4 that RT cannot
handle yet, so now with a fuller support of camera-like DCPs users will be more likely
to use this feature and will hit v4 limitation on new camera models - may be a tooltip
message with explanation of this issue would prevent user complaints if they see weird
colors in v4 DCP?

Reported by michaelezra000 on 2012-08-18 12:50:21

[Beep6581]

This image is the reason why i've contacted you, Oduis:
http://natureh.free.fr/RawTherapee/Comparison2.jpg

On the left, image loaded in RT with Neutral profile
On the right, image loaded in DPE with "neutral" profile too (just started DPE then
loaded the DNG image, all parameters untouched, embedded base curve used)

There's a clear difference (even with DPE "Base Tone Curve = Linear"), and i don't
know why. But here are some hints:

--- IMGP3633.xml :

Genarated by dcptools from the original Pentax K20D file (see link below)

--- PENTAX K20D Standard.xml :

Genarated by dcptools from the DCP profile generated by DNG Profile Editor, with no
adjustment at all. As you can see, the matrices are the same, but DPE adds a tone curve,
maybe related to the Base Profile as you can see in BaseProfile.png below (the curve
contains at least 2 control points by looking at the start if the curve). Where does
it come from, it would be interesting to know. I see 2 possibilities:
1. it's in the original DNG file but dcptool don't know how to extract it, but RT should
be able to read and use it. In this case, a "Use original file's embedded tone curve"
should be a must have :), even with proprietary file format if possible (well, at least
for DNG files). If the user specify a DCP profile, the raw file's embedded profile
will then be overrided by the one of the DCP profile *IF IT CONTAINS ONE*, otherwise
the original one is kept. I think that a supplementary "Use DCP's embedded tone curve"
would be useful as well, as some may want to tune their image starting from a completly
neutral image (ok, not speaking about the matrices here :) )
2. the tone curve is generated by DPE only, on a per camera basis or depending on metadata
(would be interesting to know too). Then the "Use DCP's embedded tone curve" option
would still be welcomed.

I also didn't understood what you meant by:

"[...] so disabled for RTs own profiles (most of them don’t contain one anyway, but
for backward compatibility with a few of them"

and

"So it’s NOT recommended to move the curves to the profiles but use RTs ones, except
you want to use those existing profiles"

Anyway, viel danke for this great new feature!

--- Original raw file: http://natureh.free.fr/RawTherapee/IMGP3633.DNG
Legal notice: IMGP3633.DNG is copyrighted (c)Jean-Christophe FRISCH, do not use without
my agreement

Reported by natureh.510 on 2012-08-18 15:35:09

---

• Attachment: BaseProfile.png
  
• Attachment: IMGP3633.xml
• Attachment: [PENTAX K20D Standard.xml](https://storage.googleapis.com/google-code-attachments/rawtherapee/issue-1527/comment-9/PENTAX K20D Standard.xml)

[Beep6581]

Ok, trying to clarify:

The DCP version of the tone curve is generally a bad thing. It’s technically way less
powerful than RTs curves, e.g. no fancy color shift correction. And it has nothing
to do with camera calibration, it’s not derived from the calibration, therefore X-Rites
profiles don’t contain it (which is a good thing). I think DPE mixes that curve in
from Adobes base profiles. It’s subjective and purely artistic. You should make a PP3
curve preset if you want to have the effect as default, rendering better quality.

So the only raison d’être of this feature is for DCP profiles that try to give a certain
look (mostly cam maker like “portrait”, “landscape” etc). The best way would be to
create a PP3 profile to simulate that. However if you have a given profile already
(like the many many Adobes) and you don’t care too much about ultra-quality, you can
use this patch.

Also because of this, the tone curve parsing is disabled for RTs own profiles in the
dcpprofiles directory. For one because they are a bad thing, for two because 3 profiles
had to be done with DPE unfortunately and contain that curve, and it would yield error
reports why most of RTs profiles render neutrally while 3 boost contrast etc.

But I’ll add a checkbox for disable the tone curve in non-RT profiles if you like.
A tooltip for the v4 problem will probably not be helpful: judging from the forums/issues,
no one seems to read the lengthy explaining tooltips I once added to the color panel
anyway ;-)

Reported by oduis@hotmail.com on 2012-08-18 19:23:01

[Beep6581]

PS: The DNG does usually not contain a tone curve (just check with exiftool to be sure),
for very much the same reason: it has nothing to do with calibration and is a subjective
preset. So DNG usually just contain the simple color matrix and white level (which
is essential and measured).
But since it does no bloat to the UI I'll add compatibility to select a DNG as profile.

Reported by oduis@hotmail.com on 2012-08-18 19:25:46

[Beep6581]

Here is the extended version

Reported by oduis@hotmail.com on 2012-08-18 21:34:29

---

• Attachment: DCPToneCurve04.patch

[Beep6581]

Well it's totally clear now, thanks, and thank you for the checkbox too. I don't have
the time to test right now, but will do tomorrow.

Maybe the most annoying thing in this affair is that RT doesn't have any tool to correct
tones thanks to a curve without huge colorshift. The Exposure tone curve is not really
usable. So maybe i'll have to open a new issue on "how to reproduce Adobe's tone curve
without color shift"

Gute nacht.

Reported by natureh.510 on 2012-08-19 00:44:18

[Beep6581]

Bonjour,
So you want to have the Adobe tone curve algorithm in RT, you like it? Personally I
found both RT tone curves to complement nicely. The exposure curve seem to make colors
a bit warmer when lightening up, which is nice for the base brightness lifting of e.g.
shadows in the image (which have a colder white balance, so the red boost comes in
handy). Then afterwards the color shift reduced Lab curve is good for the contrast
etc. corrections.

Reported by oduis@hotmail.com on 2012-08-19 06:07:57

[Beep6581]

I can confirm on Ubuntu 12.04 64-bit, RT 4.0.9.114 (changeset 82aa7b34d179) debug that
Adobe DCP profile curves are applied. Interesting feature, thanks for implementing
it!

Sadly enough I still can't reproduce the Nikon D200 portrait color balance, not even
with Nikon D200 Camera Portrait.dcp from Adobe Camera Raw. It definitely has an effect,
but the color balance is still way off.
I selected the DCP as custom camera profile. Is it the correct way to use them?

Reported by gyurko.david@e-arc.hu on 2012-08-19 09:06:42

[Beep6581]

David, the 82aa7b34d179 does not apply the tone curve yet, since the patch was not committed.
Yes, selecting the DCP as custom profile is the right way to go. White balance is not
really the same across converters, so that will not match 100% (and is not set by the
DCP), so you probably have to set the kelvin value manually.

Reported by oduis@hotmail.com on 2012-08-19 09:32:15

[Beep6581]

Sorry, I forgot to apply the patch.

Indeed there is a checkbox, after selecting a custom DCP and clicking the checkbox
the image becomes overexposed. See examples below, it is good to check the raw histogram
of the nef.

Right click, Save As is suggested, I think my host will serve the files as plain text.
Images are copyrighted by me (just in case...).
NEF:
http://e-arc.hu/share/rawtherapee/rt4_d200_color_balance/D200_skin_tones--red_blue--_DSC9424.NEF

Original JPEG from camera:
http://e-arc.hu/share/rawtherapee/rt4_d200_color_balance/D200_skin_tones--red_blue--_DSC9424.JPG

DCP profile from Adobe Camera Raw:
http://e-arc.hu/share/rawtherapee/rt4_d200_color_balance/Nikon%20D200%20Camera%20Portrait.dcp

The purpose of this patch is to improve interoperation with Adobe products, to make
available the vast custom camera profiles by Adobe to RawTherapee, and to match the
camera makers' color rendition in RT, right?
These are all important aspects, I definitely find the direction great.

However, as it can be seen from the linked example, the red-blue balance is still not
fine.
Am I missing something? Patch is applied this time. :)

Reported by gyurko.david@e-arc.hu on 2012-08-19 11:08:50

[Beep6581]

Think that's the wrong test. The comparison is if ACR totally neutral but with that
DCP renders roughly the same as RT. Otherwise you're testing the profile against incam,
but not this patch.

Reported by oduis@hotmail.com on 2012-08-19 11:23:56

[Beep6581]

OK, thanks.

Have you seen the overexposure?

Reported by gyurko.david@e-arc.hu on 2012-08-19 11:28:31

[Beep6581]

I'm sitting on a bench in a park with wife and kid sleeping. Writing from Smartphone,
cannot test.
But the curve evaluation look good on the D700 profile, see sample above. SO I assume
it's that D200 profile.

Reported by oduis@hotmail.com on 2012-08-19 11:46:31

[Beep6581]

:) Have a great time!

Reported by gyurko.david@e-arc.hu on 2012-08-19 11:52:03

[Beep6581]

Olli thanks for adding that checkbox. 

About the tonecurve, Emil and I had private correspondence on the subject. The issue
with RT tonal curves is that they alter saturation and/or hue and or chromaticity.
As a result a complex combination of curves is necessary to get clean colors, and that
may not be always possible at the desired tonal adjustments. I think this is a fundamental
feature that needs a better solution. The answer might be here: https://sites.google.com/site/clifframes/ciecam02plugin
A clear explanation is given in the paragraph "Saturation vs Chroma":  

"When Chroma is held constant, changes in Lightness will also cause a change in chromaticity.

When Saturation is held constant and Lightness is changed, chromaticity will tend to
be preserved.

To demonstrate the difference, change the Perceptual Correlates to one of the Chroma
modes ( JCh or JaCbC) and vary the Lightness scale control to make the image lighter
and darker. When Lightness is changed in Chroma mode, even though Chroma is kept constant,
the purity of the colors in the image appears to change. As the Lightness is increased,
the image becomes less colorful, conversely reducing Lightness results in overly-saturated
dark colors. It is well-known that the same effect occurs when editing Lightness in
CIELAB, and the reason is that the CIELAB a* and b* coordinates are based on Chroma.

Now change the Perceptual Correlates mode to one of the saturation modes (Jsh or Jasbs).
In saturation mode, saturation will not change when Lightness varies. When saturation
is held constant, chroma will change in proportion to Lightness so that the effect
is similar to varying the photographic exposure (chromaticity is preserved)."

So the new tonecurve that RT needs is L in the LSH space. That plugin allows to visualize
how such curve works.

Olli, sorry for hijacking your issue, this is a separate one:)

Reported by michaelezra000 on 2012-08-19 14:08:29

[Beep6581]

Thanks, back again. It looks like the brightness is already correct without much tone
curve on that image. But again, that test is comparing apples and oranges.

Reported by oduis@hotmail.com on 2012-08-19 14:18:35

[Beep6581]

Michael, that is for sure another subject than Adobes DCP tone curve.

Also from my understanding, Jacques and Hombre lately fixed it, with the Lab curve
that's munsell corrected to prevent color shifts. I seemed to work fine, judging from
some test images that fail on normal Lab changes but work with RT now.

Reported by oduis@hotmail.com on 2012-08-19 14:22:37

[Beep6581]

Munsell corrections to L curve don't address the issue I mentioned: "As the Lightness
is increased, the image becomes less colorful, conversely reducing Lightness results
in overly-saturated dark colors."

Reported by michaelezra000 on 2012-08-19 14:35:48

[Beep6581]

Should maybe be discussed with Jacques, but on a different issue from my point of view.

Reported by oduis@hotmail.com on 2012-08-19 15:11:51

[Beep6581]

About comment #15: sure i like it, but just for my personal information, what makes
you say that Adobe's embedded curve are of poor quality?

Anyway, offering the possibility to use them goes in the right direction i think. I
still have to test your latest patch (right now).

About the color shift of the Tone curve, the dechnical details are too high level for
me, but we (Michael? ;) ) should open an issue for that, and ask Jacques to join.

Reported by natureh.510 on 2012-08-19 17:27:12

[Beep6581]

I’m not a specialist on tone curves, but once read an article about the different tone
curves in the Adobe products (LR, ACR, PS, they seem to be a bit different). Some seem
to be pretty advanced, like RTs. However the reference code seems to be simple it seems,
and if I were Adobe I would not give away the full source code for a cool curve technique.

So I assume it’s just a basic version. But if you say the results are great and one
of our tone cuve math specialists (Emil? Jacques?) says the DCP curve algorithm is
better than e.g. RTs current exposure curve, we could add it (optionally of course)
to RTs arsenal.

Reported by oduis@hotmail.com on 2012-08-19 19:55:39

[Beep6581]

Committed to DEFAULT.

Reported by oduis@hotmail.com on 2012-08-20 05:43:57

• Status changed: Fixed