Rawtherapee: Softproofing branch

[Beep6581]

This is a general issue for things related to the softproofing branch.

[Beep6581]

When I run a1981dbd4d1ed5c5c50a8a11053fea6ab1c0f7fa it nukes my options file. The result is almost identical to deleting the options file, with these differences (the - is when you delete the options file and run RT master, while the + is when you run RT softproofing):

@@ -12,7 +12,7 @@
 Theme=25-Gray-Gray
 SlimUI=false
 UseSystemTheme=false
-Version=4.2.1015
+Version=4.2.1016
 DarkFramesPath=
 FlatFieldsPath=
 Verbose=false
@@ -44,8 +44,8 @@
 SameThumbSize=1
 MaxPreviewHeight=250
 MaxCacheEntries=20000
-ParseExtensions=3fr;arw;cr2;crf;crw;dcr;dng;fff;iiq;jpg;jpeg;kdc;mef;mos;mrw;nef;nrw;orf;pef;png;raf;raw;rw2;rwl;rwz;sr2;srf;srw;tif;tiff;x3f;
-ParseExtensionsEnabled=1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;0;1;1;1;1;1;1;1;1;1;1;1;
+ParseExtensions=
+ParseExtensionsEnabled=
 ThumbnailArrangement=2
 ThumbnailInterpolation=1
 LiveThumbnails=true
@@ -187,6 +187,7 @@
 Autocielab=true
 RGBcurvesLumamode_Gamut=true
 Intent=1
+MonitorBPC=true
 view=0
 grey=3
 greySc=1
@@ -247,6 +248,7 @@
 fastexport_icm_working=ProPhoto
 fastexport_icm_output=RT_sRGB
 fastexport_icm_output_intent=1
+fastexport_icm_output_bpc=1
 fastexport_icm_gamma=default
 fastexport_resize_enabled=true
 fastexport_resize_scale=1

[Beep6581]

I think the rendering intents for the monitor profile are incorrectly switched under the hood. Now Relative Colorimetric is actually Perceptual, while Absolute Colorimetric and Perceptual look identical when they should not.

https://github.com/Beep6581/RawTherapee/blob/softproofing/rtgui/editorpanel.cc#L71
https://github.com/Beep6581/RawTherapee/compare/softproofing#diff-3d82a2796017d51b96c612376d2300fcR71

[Beep6581]

In Settings I have a default monitor profile set (called "latest"). When I open a photo, the preview has not been passed through that monitor profile, even though the monitor profile combobox shows "latest". If I change from "latest" to "None" there is no difference. If I change back to "latest", it gets loaded correctly.

[Beep6581]

I may have stumbled on the cause of the wrong rendering intent problem:
https://github.com/Beep6581/RawTherapee/blob/softproofing/rtgui/editorpanel.cc#L176

case 0 should be switched with case 1

P.S. "same order as the enum"

[Beep6581]

One thing I wanted to point out in the old code.

rtgui/preferences.cc old code:

    monIntent->append_text (M("PREFERENCES_INTENT_RELATIVE"));
    monIntent->append_text (M("PREFERENCES_INTENT_PERCEPTUAL"));
    monIntent->append_text (M("PREFERENCES_INTENT_ABSOLUTE"));
    monIntent->set_active (1);

rtgui/preferences.cc new code:

    monIntent->append_text (M("PREFERENCES_INTENT_PERCEPTUAL"));
    monIntent->append_text (M("PREFERENCES_INTENT_RELATIVE"));
    monIntent->append_text (M("PREFERENCES_INTENT_ABSOLUTE"));
    monIntent->set_active (1);

Assuming index starts at 0, monIntent->set_active (1); used to point to Perceptual, but now it points to Relative. But when I checkout and compile master, delete the options file and run it, the default monitor profile is set to Relative Colorimetric! Of course RC is the best default option, but according to the code it should be Perceptual, so... there must have been a quirk in the original code, if I'm reading this correctly. Just a heads up.

[Beep6581]

From RawPedia:

The image you see in the preview is taken from the working profile's color space and converted into the monitor profile's color space, if a monitor profile is loaded, or into sRGB if one is not. It does not take into account the "Output Profile" section of the "Color Management" tool.

For the docs, and for me, could you please describe the new preview pipeline with and without softproofing enabled?

So is this correct?

raw
 |
input
 |
working --- if soft-proofing off: monitor profile [chosen intent] --- preview
 |
output [chosen intent] --- if soft-proofing on: monitor profile [chosen intent] --- preview
 |
saved image

[Beep6581]

I'm not sure soft-proofing is working correctly yet. Please try this ICC:
https://filebin.net/br6el0xq9pg0x8fc/SwappedRedAndGreen.icc
Set it as your monitor profile and as the output profile. I think what should happen is that the red and green channels are swapped once in the output profile, and then swapped again in the monitor profile, leading to a correct image, but when I do this in RT, nothing happens. I still see the swapped colors, as if the soft-proofing profile wasn't applied.

[Hombre57]

For the options file bug (your second comment), I experienced it myself but can't reproduce now. Anyway, I saw a problem and fixed it few minutes ago in master : the options object were reset at each call Options::readFromFile, which is not what we want if we want to cumulate the changes at each call of this method. That bug was problematic if your personal options file couldn't be read (damaged or doesn't exist) or if it's incomplete. I also noticed a little problem in options.cc but that should not lead to a failure of the readFromFile function (set_integer instead of set_boolean). I'll correct that in an upcoming patch though.

[Hombre57]

Perceptual, Relative, (Saturation,) Absolute is the enum's order. Look for the case rtengine::RI_PERCEPTUAL: code, you'll see that it respect this new order (in editorpanel.cc as well as preferences.cc), or tell me what's wrong in the code. [EDIT: just saw one of your later comment. Yes, you've found the bug).

You're right that in preferences, I didn't updated the default choice. However there is default choice mismatch in the original code between [Options::setDefaults (rtSettings.monitorIntent = rtengine::RI_RELATIVE;) + ex-MonitorProfileSelector] and the Preferences. Now everything is set to Relative by default.

[Beep6581]

or if it's incomplete

That makes sense. Since your branch adds new keys fastexport_icm_output_bpc and MonitorBPC, every pre-existing options file would be considered incomplete, and be reset.

Have you tried that SwappedRedAndGreen.icc thing?

[Hombre57]

In Settings I have a default monitor profile set (called "latest"). When I open a photo, the preview has not been passed through that monitor profile, even though the monitor profile combobox shows "latest". If I change from "latest" to "None" there is no difference. If I change back to "latest", it gets loaded correctly.

Should be solved in the upcoming patch.

[Hombre57]

I finally solved the initial use of the monitor profile bug.

Have you tried that SwappedRedAndGreen.icc thing?

Yes, but I don't even knew we could swap channels with an ICC profile. However, I don't understand why using that profile as output profile, and soft-proofing activated, does not lead to inverted channels like it does when set as monitor profile. I suspect some internal behavior in lcms. In non-soft-proofing mode, RT converts from Lab to monitor profile directly (i.e. RGB). In soft-proofing mode, it converts from Lab to Output (unknown channels) to monitor (RGB). See line 118 of rtegine/improcfun.cc for the creation of the soft-proofing profile using lcms.

For the docs, and for me, could you please describe the new preview pipeline with and without softproofing enabled?

So is this correct?

From what I've understood from the code (even from master), no. See the updated tools/color_management.svg file (from the last commit).

[Hombre57]

I hope that with the actual bugfix, we'll not see that deleted options file bug again, otherwise we may have some complain ^^ (and it doesn't look professional)

[Beep6581]

I'll test soon, hopefully tonight.
Thanks for the work on this, it's a very useful feature!

[Floessie]

Thanks from me, too, Jean-Christophe!

I've pulled master an hour ago and built a release build. After starting it, all my options where defaulted. Is that still expected?

Best,
Flössie

[Hombre57]

No, but I still can't find a scenario to reproduce it.

[Hombre57]

@Floessie The soft-proofing branch is not yet merged to master, so if it happened to master, then the problem lies in master not in this branch, doesn't it ? Or does it reset the options file when switching back to master ?

[Floessie]

@Hombre57 No, you must be right. I was on master and did a fast forward git pull, ran make install in the build dir and started it in build/release. It came up with my system's locale instead of en_US and with _no_ file associations. Until then, I had not even pulled the soft-proofing branch. Maybe I should delete RT's config directory and start all over. Perhaps something is wrong with my setup.

[Beep6581]

SwappedRedAndGreen.icc - https://github.com/mm2/Little-CMS/issues/96

[Beep6581]

1. RawTherapee users, myself included, don't know the RawTherapee pipeline, so the SVG is not very helpful.
   The light green arrow which goes to the preview image, that should come from the working profile when soft-proofing is disabled, or from the output profile when soft-proofing is enabled. Instead, the only working profile box in the diagram is hanging unused on the left. This doesn't make sense to me.
2. There is a bug:
   
   
   
   • Preferences > Color Management, default monitor profile set to "latest"
   
   
   • I open any photo, my monitor profile is used.
   
   
   • Change the monitor profile combo to "None".
   
   
   • Open some photo, or reload the same photo. The combo still shows "None", but my monitor profile is being used.
   
   
   • If I change the combo to "latest", nothing changes in the preview, because it was already being used. If I change it back to "None", it updates.
   
   
3. I'm having doubts about whether the flow of data is happening in the right order...
   
   
   
   • Using dobbiaco_bar.pef. RT is set to use my monitor profile, "latest". https://i.imgur.com/O9SIV0s.jpg
   
   
   • I set the output profile to "latest" and the output rendering intent to "perceptual". I expect the gamut from the working profile to be squashed into my monitor ICC's gamut without clipping, and then I expect this to be fed through the monitor profile (also "latest"). But there is clipping in the red light. https://i.imgur.com/e2YvV4O.jpg Maybe this indicates that the data is not flowing through the correct order of things? Or it indicates that I'm wrong.
   
   
   • Now if I change my monitor profile to nothing, clipping goes away https://i.imgur.com/aYl1Ts0.jpg
   
   
4. RT doesn't show CMYK profiles. https://filebin.net/pv6aovpqotx6a6rh/rgb_cmyk_icc.zip

[Hombre57]

1. I'll drop a word on where to start reading the diagram in the SVG file. It reflects the way that the data are converted and the generated internal image. The Working image was not generated in all case even before my patch ! The Working color space is however used here and there in the pipeline to fit the image into its gamut, and as output profile if you select this option in the ICM panel. I'm not the architect is this behavior, so I can't comment more on this. You can debate and tell me what to do though.

[Hombre57]

3.

Now if I change my monitor profile to nothing

In this case there's no soft-proofing at all possible and the image is converted to sRGB IIRC. I'll make a patch to make those icons insensitive in this case. Still investigating for the rest of this point.

[Beep6581]

When jumping from a non-softproofing build to a softproofing one, when I open a photo which uses film simulation the preview looks good at first, but when I touch any slider, the film simulation is disabled from the preview and from the tools, and the combobox shows that I must set the film simulation folder in preferences. Reproduced in yesterday's build and reproduced in a just-now build (commit bdf4665).

[Beep6581]

Reproduced #3411 in commit bdf4665.

[Hombre57]

Point #2: solved (already committed)

[Hombre57]

3.

I expect the gamut from the working profile to be squashed into my monitor ICC's gamut without clipping, and then I expect this to be fed through the monitor profile (also "latest").

I'm sorry but I don't really understand what you mean here. I see clipping in the reds for both images, so I don't understand your point. Could post some screenshots again but with a detail window (or zoomed in) of the red area, + a snapshot or the preview without soft-proofing ?

[Hombre57]

Let me show you what I've ended up so far with my test that compares the result between RT and LR4.4, involving my monitor profile used as monitor profile (perceptual intent, like the system option and hence LR's monitor intent) and your monitor profile used as output profile (see below for the intent). No Plack Point Compensation involved.

http://imgur.com/a/yc98B

I tried to get an image in both software with saturated reds in non soft-proofing mode. I'll let you compare the general brightness & the clipping. I find this quite similar (and I said _quite_, so is there something wrong ?).

I also tried the SwappedRedAndGreen profile (last image of imgur). It doesn't swap when used as output profile in both software. However the RT's version is brighter, while they are similar in Relative intent (same rendering as the LR's Perceptual version).

[Beep6581]

For the SwappedRedAndGreen-not-swapping phenomenon see https://github.com/mm2/Little-CMS/issues/96
It seems that that is the way it should be.

It is maybe not a good idea to explain with screenshots, because when I view the screenshots I sent you in a color-managed viewer then they are both clipped, while only one is clipped when I turn color management off in the viewer.

I will do more testing tomorrow.

By the way, when I use a Gtk3 build and then switch to today's softproofing branch (commit a69c631), the ClutsDirectory= key in the options file still gets wiped, which is a problem when I open a photo which uses Film Simulation as then the used CLUT gets wiped from the PP3.

[Hombre57]

By the way, when I use a Gtk3 build and then switch to today's softproofing branch (commit a69c631), the ClutsDirectory= key in the options file still gets wiped, which is a problem when I open a photo which uses Film Simulation as then the used CLUT gets wiped from the PP3.

Still investigating on this...

[Hombre57]

Btw, would it be possible to ask something to Marty regarding the role of the output intent ? How is it used and why is there a difference when I see the preview image in soft-proofing mode in e.g. Relative output intent, vs the real output image seen through a color managed software (IrfanView) which seem to don't care about this parameter, I always see the same thing !

My theory is : when opening the output image in PhotoMe, it tells me that the embedded profile is set to "perceptual". Should we and how can we change that ?

Another thing : Windows is set to "perceptual" for photo rendering, I guess that IrfanView is looking at this and will only show the image with the intent set in Windows preferences ?

I hope that someone will be able to answer this.

[Hombre57]

By the way, when I use a Gtk3 build and then switch to today's softproofing branch (commit a69c631), the ClutsDirectory= key in the options file still gets wiped, which is a problem when I open a photo which uses Film Simulation as then the used CLUT gets wiped from the PP3.

Solved in a9fc506, as well as the nuked options file bug ! We could have solved this earlier if the error message wasn't displayed in verbose mode only. This is solved too.

[Beep6581]

@Hombre57 yes, you can ask him directly, it's still GitHub, you don't need a new account. You can also ask Florian Hoch, author of DisplayCal, and Graeme Gill, author of ArgyllCMS, about how things should work and how the data should flow. They are both very knowledgeable and helpful.

[NextTherapist]

Please explain to me: what do you mean by Softproofing branch? Is there a version of RT where I can simulate photo paper output or offset output for a defined paper or machine?
And if yes, is there already an installable Windows version?

[Hombre57]

@NextTherapist A _xxx_ branch mean that there is a patch in Work In Progress state. This _softproofing_ branch adds soft-proofing to RT, as you have guessed.

Branches are for developer or tester who can build RT themselves, before merging them to _master_, the generally available RT version. If you have some knowledge in ICC Profile and color management, I wouldn't mind any help from you and would build RT for you, but it's still not officially ready for production (though I think it is).

[Hombre57]

Just gave another try to the current state of the patch. I don't see any problem so far, except that the output rendering intent doesn't seem to have any effect on the output image. I would be very thankful if a CMS expert (@mm2 ?) could provide some explanation on this, or point me to a webpage on this. I didn't found documentations on the output intent and its role.

Perhaps, another problem that we could find a workaround by using 2 lcms transform, is that the bit depth is not previewed by lcms with soft-proof transform. So the output image can be very posterized while the preview, even in soft-proofing mode, are clean. You can test by selecting a custom gamma profile (gamma 1.0) - see here :

http://natureh.free.fr/RawTherapee/BlackCat2-6-RT.jpg
http://natureh.free.fr/RawTherapee/BlackCat2-6.jpg
http://natureh.free.fr/RawTherapee/BlackCat2-6.jpg.out.pp3

@mm2, if you're around and okay to answer, is there a way to specify the proofing bit depth, the cmsCreateProofingTransform function does only ask for the source data format and output data format. So since the output file will be 8 bits, we would prefer float > char > char over float > float > char (the second one being the theoretical output bit depth) for the soft-proofing transform. @Beep6581 @Floessie @heckflosse : but do we really want to preview the output file bit depth ? That mean that the Editor should react to the Queue tab's output file format !

In RT, soft-proofing intent and monitor intent are set to Perceptual, as is Irfanview output profile. Btw, I see that the embedded profile from the output file has a preferred intent set to Perceptual. Are we allowed to set another value when processing and saving the image in RT ?

[mm2]

Hello,

I think to properly answer your questions I should first clarify some concepts.

In color management, “proofing” relates closely to printers. A very frequent issue, when somebody prints a color managed job, is to get colors that she don’t like at all. In industry, this becomes a big issue because the obvious marketing implications. So, RIP manufacturers often offer a way to “preview” the output without really printing it. This is very convenient when the final media is expensive or unavailable at design time.

There are two ways to do this “proofing”. The good one is called “hard proofing”. This is done by specialized printers often called ”proofers”. It emulates everything. Halftone screens, screens angle, dot gain, some even including emulation of mechanical limitations. Proofers use same media and same inks that the printer being emulated. Proofers are expensive and one of its functions is to do the “contract proof”, which is a emulation of the final plot such good and fair that the customer can sign a contract with the emulation as a demonstration of quality. Example, a company wants 300.000 flyers and signs a contract with the print service provider based on a contract proof that shows the exact colors and appearance of final flyers. Many times emulating cheap media is more complex than emulating expensive ones.

On the other hand, there is something way more simple. This is not such detailed as hard proofing, but if done properly is very effective, and the cost is unbeatable: almost zero. The idea is to use a monitor to emulate the colors (and only the colors!) of the printout. Why a monitor? Because in general, monitors do have wider gamut than printers. All this soft proofing thing is about gamuts. Each printer, each print mode and EACH PAPER have an associated gamut. So, if you are going to print your photo using a Series-Z HP, for example, switching from plain paper to semigloss photo makes a huge difference in gamut. So, if you have an adequate profile for the paper, printer and print mode, you can do the softproofing. Let’s use coated paper for example. If you take a look on the gamut of this media, the reads and greens cannot be very saturated, yellows are very good (more than some monitors, indeed!) and the blacks are not very dark. So, the profile, especially in perceptual intent, have to do a lot of gamut mapping to accommodate colors from your image to the coated paper gamut. Now if your monitor gamut is big enough, you could preview the colors moved by this gamut mapping. And this is the case of almost all colors, but not all. Still the printer is better on printing yellows than your monitor.

So, to view all colors in the monitor, including this yellow, you need additional gamut mapping to accommodate to your monitor. And this is the role of the output intent. Normally, absolute or relative colorimetric should be used, and it affects very few colors, because only colors that can be printed but not displayed will be moved.

To implement proofing, lcms as most CMM does this chain:

Input image -> Input profile -> CIELab -> Proofed profile -> CMYK -> Proofed profile -> CIELab -> Monitor profile -> RGB

That is, a roundtrip on the proofed profile is performed, the proofed intent is applied only in Lab->Proofed profile step. The measurement to CIELab part is performed in relative colorimetric. Output intent is applied to Lab ->Monitor profile.

Ok, sorry for getting too long. Now I feel I can answer better your questions.

that the output rendering intent doesn't seem to have any effect on the output image

It does. It happens that only will affect colors that are out of monitor gamut but in printer gamut. And those are few. Try cyan, magenta or yellow for example. Another reason would be you are using a simple monitor profile that does not implement intents. All matrix-shaper profiles (adobeRGB, sRGB, etc.) does not implement intents. Use a real profile generated by a profile software and you will see the difference.

is that the bit depth is not previewed by lcms

It is not, because that would be only a very small fraction hard proofing. Dot gain is, for example, far more important that bit depth. Lcms implements soft-proofing. For hard-proofing you need specialized hardware, and doing only a part of the feature is out of current lcms scope.

BTW, using softproof to preview the effect of working spaces or gamma curves is pointless. The use for soft proofing is to emulate printers. To some extent it may work for other usages, but this is not the goal of this tool.

I see that the embedded profile from the output file has a preferred intent

You can read this setting by using lcms routines. But then is up to you to use this value when creating your transforms.

Hope this would help.

Best regards

Marti Maria

The LittleCMS project
http://www.littlecms.com

[Hombre57]

@mm2
Hello Marty,

Thanks for this detailed introduction, that was very clear and instructive, and given my understanding of color management (!NULL, but far from complete ;) ), it'll never be too long !

What I understand from your answer is this (and correct me if I'm wrong) :

1. the soft-proofing term should only be used in a printing simulation scenario only. Actually, I'm also using it to simulate the rendering of the output file, even if it's targeted at monitor display and/or for further editing in the user's workflow.
2. it is pointless to save an image with a printer profile, it is just not meant for that. In fact, RT should filter out the output profile list and only keep profiles with standard color-space, e.g. sRGB, ProPhoto, AdobeRGB, etc... Do you recommend to filter them out based on the cmsProfileClassSignature enum ?
3. we should add a button to simulate (or should I say _preview_) the rendering of the output file, taking into account the bit depth and gamma value. I don't really know the use case of selecting a particular gamma value, I didn't made this function, but it's there.
4. it means that we have to create a separate combobox to select a printer profile with the soft-proofing button to enable the simulation, with or without output file simulation (to let the user preview more scenarios).

Just for the record, my monitor profile was created by ArgyllCMS with a SpyderPro2 colorimeter, so you may know better than me if it includes several intents or not (and I'm interested to know).

One thing that I find curious is that all the color profiles (of any class) seem to enable the 4 intent type. I guess there's a bug in my code and will check again.

[Beep6581]

my monitor profile was created by ArgyllCMS with a SpyderPro2 colorimeter, so you may know better than me if it includes several intents or not

You must select Profiling > Profile Type > XYZ LUT + Matrix (I don't know about Lab* LUT), and you can add further rendering intents by clicking the gear icon next to that combo and selecting the desired intent in "Gamut mapping for * intent".

[Beep6581]

@Hombre57 I would like to add the soft-proofing patch to RT5 roadblockers, because it adds great value and because it cannot break anything PP3-wise. Is that OK with you?

[Hombre57]

@Beep6581 Ok, that's fine.

And do you have any comment on my last 4 questions or should I proceed like I think _should be better_ ?

[Beep6581]

Apologies for the late response.

1. I don't feel qualified enough to comment whether it is correct to call the output profile simulation when not used for printing "softproofing". It bugs me when people say "HDR" when they mean "(unnaturally) tone-mapped". As far as I'm concerned, calling it "softproofing" is fine.
2. I'm not sure what you mean by "_with_ a printer profile" or why that would be pointless. If users have a need for that, then why prevent them?
3. I would like that functionality. I wanted to abuse use that in a certain way, but I'm having doubts about whether what I wanted to do makes sense, so I won't describe it yet until I'm sure ;)
4. The user needs to be able to select the output profile, the monitor profile with monitor intent, and the soft-proofing profile. The rendering intent used when converting the saved image into the proofing (printer) profile must be selectable - it seems logical to put this into the softproofing part of the UI wherever that is. Here I have an doubt - @mm2 wrote of the "output intent" and the "proofed intent"; are they not the same thing?

@mm2 wrote:

using softproof to preview the effect of working spaces or gamma curves is pointless.

Why pointless, if the user has such a desire? Or is it that it will not work as intended?

Here is my latest XYZ LUT + matrix monitor profile, it has an 84.2% sRGB gamut coverage, uses the relative colorimetric intent by default and also includes a perceptual intent gamut mapping - you can use it for testing:
https://filebin.net/cqq4z7bs2mazutdi/B133HAN02.1__1_2016-09-19_13-50_250cdm__0.295x_0.3451y_0.24cdm__1.86_F-S_XYZLUT_MTX.icc

[mm2]

On Sep 19, 2016 6:44 PM, Beep6581 [email protected] wrote:

image into the proofing (printer) profile must be selectable - it seems logical to put this into the softproofing part of the UI wherever that is. Here I have an doubt - @mm2 wrote of the "output intent" and the "proofed intent"; are they not the same thing?

It happens sometimes the printer can print colors that the proofing monitor cannot, so you need a gamut mapping to accommodate things. Example, you print your photo using perceptual, and want to see accurately how perceptual moves colors. So, the proofed intent is perceptual and the output intent is relative or absolute colorimetric.

using softproof to preview the effect of working spaces or gamma curves is pointless.

Why pointless, if the user has such a desire?

I mean is pointless to do ONLY gamma emulation. If you want to do hard proofing, that would be great, but then you need to do much more than just emulating  posterization. And to emulate gamma posterization you need to convert the whole image pixel by pixel. Gamut soft proofing is speed up by 3d tetrahedral interpolation, which works for predicting gamuts but not for predicting artifacts.

Regards
Marti

[ellelstone]

FWIW, here is a comparison of soft proofing output from several different image editors that use LCMS, including RT: http://ninedegreesbelow.com//files/soft-proof/soft-proofing.html

The various softwares were mostly compiled from git on September 3. There are 3 downloadable test images.

PhotoFlow linear gamma branch (https://github.com/aferrero2707/PhotoFlow/tree/linear_gamma) has some nice code that allows to work around some of the current limitations of just using LCMS for soft proofing, including code that accurately calculates gamut checks when soft proofing to an output RGB working space, plus code for emulating paper white and ink black.

In a time when many people do edit images for display on the web or electronic display devices, soft proofing to RGB matrix profiles is an important thing to be able to do. And for raw processors where the user's chosen RGB working space might not be the same as the chosen RGB output space, again, soft proofing to the output space at least to the extent of seeing accurate out of gamut checks seems pretty important.

This page has some examples of issues trying to soft proof using current LCMS and GIMP from git, but the same issues apply to any software using LCMS: if the source color space has a linear gamma TRC soft proofing gives wrong results, and if the destination color space supports unbounded profile conversions, again there are issues: http://ninedegreesbelow.com/bug-reports/soft-proofing-problems.html

[Hombre57]

Hi @ellelstone , I'm taking time now to finish this patch and explore all your useful material about soft-proofing, but to make my own test, could you share the pp3 files of your different test case from here http://ninedegreesbelow.com//files/soft-proof/soft-proofing.html I've already downloaded your profiles.

Could you also check your _Preferences_ and disable the _Black Point Compensation_ from the _Color Management_ panel. If this button is checked, BPC will be active when soft-proofing despite the one in the _ICM_ panel.

For the unbounded mode, I guess that it would be a great improvement if RT could handle it, but it would require quite some work, because RT control out of gamut color at different step of the pipeline without using LCMS. @Desmis could better answer and help here.

So I'd say that we won't support it for now and we should open a new issue for that.

[ellelstone]

Hi @Hombre57 , and my apologies, I already deleted the pp3 files.

I just opened RT and it looks like Black Point Compensation from the Color Management panel was already disabled. I normally disable bpc for image editing (instead I just make sure that none of my image colors fall below my monitor's black point).

How does/where in the code does RT control out of gamut colors? For the three test images, RT was generating better gamut checks than LCMS.

[Hombre57]

How does/where in the code does RT control out of gamut colors? For the three test images, RT was generating better gamut checks than LCMS.

I'm using lcms' gamut soft-proofing feature, enabling the gamut check when asked for. See here https://github.com/Beep6581/RawTherapee/blob/softproofing/rtengine/improcfun.cc#L118

Since the last image buffer from the pipeline is a Lab image, the Input profile is a Lab colorspace from lcms (see https://github.com/Beep6581/RawTherapee/blob/softproofing/rtengine/improcfun.cc#L88)

If you want some example of gamut control during the pipeline, see here :

• https://github.com/Beep6581/RawTherapee/blob/softproofing/rtengine/color.cc#L2290
  This one is used in Vibrance, Retinex, Wavelet, RGB curves (Luma mode)
• https://github.com/Beep6581/RawTherapee/blob/softproofing/rtengine/ciecam02.cc#L347

As @mm2 said, soft-proofing should be used for rendering Printing only. However if we select a small gamut output profile like sRGB displayed on a wide gamut monitor, we should let the user see the gamut handling. So I think we should handle 4 paths :

1. Input (Lab) -> Monitor profile : That's the path RT uses when soft-proofing if disabled. Do we have to put the Working profile in-between ? Please notice that you could select an output profile corresponding to the Working profile (RT provide one for each Working space, but you can override the choice of the corresponding ICC profile), if you want to save the image in the working profile space, and then render it with path 2.
2. Input (Lab) -> Output (e.g. sRGB) -> Monitor profile :
3. Input (Lab) -> Output (printer) -> Monitor profile : you could do soft-proofing with this path. More like a workaround than something cleanly done, but isn't there an interest in saving an image in a Printer color space ? (just asking)
4. Input (Lab) -> Output (e.g. sRGB) -> Output (printer) -> Monitor profile : should we really handle this path ? The idea is to _simulate_ (kinda) the generation of a file in a small color-space and simulate the rendering of that file to a printer. I probably go too far here and we should not have to worry about this path (which will take some time to code, since we have to create one more ICC profile selector).

[ellelstone]

As @mm2 said, soft-proofing should be used for rendering Printing only.

Many photographers choose to edit in large RGB working spaces such as Rec.2020, ACEScg, or ProPhotoRGB. For radiometrically correct RGB color mixing, the user might be editing in a linear gamma version of their chosen RGB working space.

At some point the user will want to output the finished image to another color space, either to a device color space for final display or to another RGB working space for further editing. So the destination color space might be:

1. A CMYK profile such as US Web Coated SWOP V2.
2. A printer-paper profile such as a profile for a specific Epson printer using a specific paper such as Museo Silver Rag.
3. sRGB for display on the web.
4. A profile made for a digital picture frame. I'm assuming some of these can be profiled, which surely will be the case "some day" if not already the case; otherwise the display color space is probably sRGB, which reduces to case 3.
5. A profile for an LCD/LED/etc monitor or television or handheld device - many if not all of these devices already can be profiled and their color gamuts do vary considerably.
6. A different RGB working space for further editing.
7. Or instead of being a finished image, the image might be a scene-referred interpolated raw file, still in the RGB color space defined by the camera input profile. In this case the destination color space will be a user-chosen RGB working space such as Rec.2020/ACEScg/ProPhotoRGB ("working space": well-behaved RGB matrix ICC profile with a neutral white point and gray ramp).

Apparently the only cases in the above list that officially count as "soft proofing", at least for people using LCMS soft proofing, are cases 1a and 1b.

However, in all of the above-listed cases the photographer will want to know the answer to two questions:

1. Which colors in the image are out of gamut with respect to the destination color space? Users typically answer this question by activating a gamut check.
2. What will the image look like after it is converted to the destination color space using one of the available destination color space conversion intents? This is answered by using the monitor to emulate the chosen output device as described by its ICC profile.

As the same two questions need answering regardless of the destination color space, I'm not sure what the point is of limiting the term "soft proofing" to cases where the image is about to be printed on a piece of paper.

As currently programmed, and as far as I can tell from testing, as of LCMS V2.8 the only time LCMS "soft proofing" gives accurate gamut checks and also accurate visual feedback is when the following two conditions are both met:

(1) The source color space has a more or less perceptually uniform TRC.
(2) The destination color space doesn't support unbounded ICC profile conversions, which is to say either V2 RGB matrix profiles with a point TRC, or else a LUT profile (assuming the LUT profile doesn't support unbounded ICC profile conversions).

[Hombre57]

In the end, maybe we could merge this branch to master as is, and look for a more qualitative featre set later on ?

@ellelstone Is there something broken for you in the actual implementation ? I understand that it is suboptimal right now, but is it broken ?

@mm2 If I've understood you documentation correctly, unbounded mode only works if input and output data are floats, + other conditions related to the profiles themselves. But in the cmsCreateProofingTransform function, you can't set the proofed profile's data type. Which one do you use ? I know that all the computation can be float internally, with optimized code for different cases. But we don't know how to ensure that the conditions are met to work in unbounded mode, and if LCMS can do gamut check in unbounded mode (bounds still exists and we could check out of bounds values, even though out of gamut data are kept as is and are considered valid).

[mm2]

On 09/10/2016 17:30, Jean-Christophe wrote:

@mm2 https://github.com/mm2 If I've understood you documentation
correctly, unbounded mode only works if input and output data are
floats, + other conditions related to the profiles themselves. But in
the |cmsCreateProofingTransform| function, you can't set the proofed
profile's data type. Which one do you use ? I know that all the
computation can be float internally, with optimized code for different
cases. But we don't know how to ensure that the conditions are met to
work in unbounded mode, and if LCMS can do gamut check in unbounded
mode (bounds still exists and we could check out of bounds values,
even though out of gamut data are kept as is and are considered valid).

I have filed a change request for lcms 2.9 to always force bounded in
softproof profiles.
But as said, lcms will NOT show you the artifacts due to low gamma and
so, this is hard proofing and is above the intent of a color management
engine.

Regards
Marti

[ellelstone]

(1) The source color space has a more or less perceptually uniform TRC.
(2) The destination color space doesn't support unbounded ICC profile conversions, which is to say either V2 RGB matrix profiles with a point TRC, or else a LUT profile (assuming the LUT profile doesn't support unbounded ICC profile conversions).

I forgot to add the third condition for accurate LCMS 2.8 soft proofing: The image needs to be in a perceptually uniform color space that has a color gamut that completely encompasses the image colors. I'm not sure how much this affects RT as RT doesn't yet support opening a floating point image.

It looks like RawTherapee always does a floating point conversion from the source color space to LAB before creating the soft proofing transform, yes? So RT shouldn't be affected by the problems of trying to soft proof from linear gamma RGB working spaces.

@ellelstone Is there something broken for you in the actual implementation ? I understand that it is suboptimal right now, but is it broken ?

@Hombre57 I'm not sure what you mean by suboptimal vs broken.

Given that RT converts to LAB before soft proofing, some issues with how LCMS soft proofing currently works are eliminated.

Given that RT doesn't support opening floating point images (at least not tiffs, I haven't tried OpenEXR), some other issues with current LCMS soft proofing won't come up.

But yes, some combinations of input and soft proofing profiles do lead to inaccurate gamut checks, as can be demonstrated by using the test images and procedures here: http://ninedegreesbelow.com//files/soft-proof/soft-proofing.html

For example, open the jet trails image and assign the ACES-elle-V4-labl.icc profile (for some reason RT doesn't seem to detect ICC profiles embedded in pngs). Then select ProPhoto as the Working Profile and RT_sRGB as the Output Profile. The gamut checks look correct.

If you select Adobe as the Working Profile, the gamut checks shift very slightly and are not quite as correct as when ProPhoto is selected.

Now select sRGB as the Working Profile, with RT_sRGB still as the Output Profile. Now the gamut checks are wrong for both the original color space and also for the sRGB color space (the entire sky is actually out of gamut wrt sRGB).

In both cases above, if you disable the gamut checks, the image colors are properly shown with a shift towards purple. I'm guessing the RT built-in profiles have point curves and are already saved to disk, so there aren't any issues with soft proofing to profiles that support unbounded ICC profile conversions.

For images with colors outside the ProPhoto color space (as is easily possible with interpolated camera raw files with linear gamma matrix input profiles, even for "scene-referred" interpolated files with no post-processing), even ProPhoto won't show accurate gamut checks.

[Beep6581]

@Hombre57 Elle found a segfault if soft proofing is activated and the user chooses as the output profile "No ICM: sRGB output". Here's the GDB log:
https://dpaste.de/YLf9/raw
I did not manage to reproduce it in Gtk2 commit 23011fbd63acb06fca6b225b5205d290feb7f557.

[ellelstone]

Given that the following passages talk about posterization, low gamma artifacts, and such, I think there might be some miscommunication going on:

But as said, lcms will NOT show you the artifacts due to low gamma and so, this is hard proofing and is above the intent of a color management engine.

using softproof to preview the effect of working spaces or gamma curves is pointless.

Why pointless, if the user has such a desire?
I mean is pointless to do ONLY gamma emulation. If you want to do hard proofing, that would be great, but then you need to do much more than just emulating posterization. And to emulate gamma posterization you need to convert the whole image pixel by pixel. Gamut soft proofing is speed up by 3d tetrahedral interpolation, which works for predicting gamuts but not for predicting artifacts.

is that the bit depth is not previewed by lcms
It is not, because that would be only a very small fraction hard proofing. Dot gain is, for example, far more important that bit depth. Lcms implements soft-proofing. For hard-proofing you need specialized hardware, and doing only a part of the feature is out of current lcms scope.

BTW, using softproof to preview the effect of working spaces or gamma curves is pointless. The use for soft proofing is to emulate printers. To some extent it may work for other usages, but this is not the goal of this tool.

I have no interest in using LCMS soft proofing to show the user a preview of the posterization ("gamma artifacts") that would be produced if the user chose to output an 8-bit image in a linear gamma color space. Imho the user shouldn't be doing such a silly thing unless the user's goal is to demonstrate that it's a silly thing to do.

Here's the actual soft proofing scenario I'm interested in:

• The source image is in a linear gamma RGB working space and is at high bit depth precision (at least 16-bit, possibly 32-bit, and either integer or floating point).
• The destination profile might be a printer-paper profile, or another RGB working space, or sRGB for display on the web, or perhaps an RGB display device. Any actual ICC profile conversion will be done using high bit depth precision.

For example, the user is editing a 32-bit floating point image in a linear gamma version of the Rec.2020 color space, and wants to soft proof to two different output profiles: (1)sRGB for display on the web and (2)a printer-paper profile. The workflow is as follows:

1. Edit in the linear gamma RGB working space while still at 32-bit floating point.
2. Still in the linear gamma RGB working space, and still at 32-bit floating point, make a copy of the layer stack and soft proof to sRGB or to the printer-paper profile, making any appropriate changes to bring the colors within the destination color gamut, or at least make them look acceptably nice.
3. While still at 32-bit floating point: For display on the web, convert the image to sRGB and export as a jpeg. The resulting 8-bit image that was saved to disk should look like what was shown by soft proofing in step 2. For printing, the next step will vary depending on what the source image requirements are for sending the image to the printer.

Nowhere in the above workflow is there an 8-bit image produced that's still in the original linear gamma RGB working space.

Unfortunately current LCMS soft proofing code doesn't produce accurate gamut checks if the source image is in a linear gamma RGB working space. This is true regardless of whether the soft proofing color space is another RGB working space (including sRGB) or is a LUT printer-paper profile.

RT seems to convert the image to LAB before soft proofing begins, and I'm pretty sure RT built-in working spaces use more or less perceptually uniform TRCS, so RT probably doesn't need to worry about people trying to soft proof from a linear gamma RGB working space. I'm only making this post to clarify that the problem isn't trying to use LCMS to show posterization from 8-bit images that might be converted to a linear gamma color space.

If I've completely misunderstood the passages that I quoted at the top of this post, please clarify!

[Hombre57]

@ellelstone @mm2 The posterization simulation was my request, while trying the different scenario offered by RT, like defining a custom output gamma of 1.0. Apparently, it's a non issue because not something a user would want, so just forget about that. We're not in hard-proofing either :wink:

@ellelstone RT can load 32 bits Tiff files. Have you ever tried ? I did and it worked fine. OpenEXR is not supported however, but that's only a matter of incorporating the OpenEXR library, see issue #1895. We're not supporting any Alpha channel though, it would be dropped completely if OpenEXR were add to RT tomorrow.

IIRC (speaking under the control of the other devs @Desmis @heckflosse @iliasg), RT handles the image in a linear gamma color space all the way up, from the image loading (where the values are converted to float before applying the input profile -> https://github.com/Beep6581/RawTherapee/blob/softproofing/rtengine/rawimagesource.cc#L890) to the end of the pipeline, which is a Lab image. At different point in the pipeline, the data are converted to the RGB, XYZ and Lab color space back and forth. But to be honest, I feel a bit uncomfortable about that gamma thing, so will let the other devs comment.

If you want to convert the image to an sRGB output file, you have to use "No ICM" for the output profile. In this case, the image is converted to sRGB and no profile is embedded.

@Beep6581

Elle found a segfault if soft proofing is activated and the user chooses as the output profile "No ICM: sRGB output".

I'll try to reproduce and investigate.

[Hombre57]

@Beep6581 The crash was due to an uninitialized pointer, occurring in Release build only. Fixed in last commit.

[Desmis]

In Rawtherapee, except for the raw part, it is applied a gamma srgb, g =2.4 slope = 12.92

To see the impact of a change of gamma ... and for other things, you can go to the "gammadif" ... branch that has not had much success. and see the impact of a change of only gamma

However, you can simulate a change in gamma (broadly defined) on the part RGB or RGB + Lab, I introduced the concept of gamma differential.
You can consult the documentation (in french)
http://50.87.144.65/~rt/w/index.php?title=Gamma_-_Differential/fr
;)

[Beep6581]

@Hombre57

PREFERENCES_MONBPC;Black point compensation for the L_a_b*->Monitor transform

I want to change this to be more user-friendly (users don't know that "Lab*" here means the final image coming out of RT before it gets transformed by the output or monitor profile), but I don't know whether this is still accurate. What does it do and when does it do it? What happens if soft-proofing is enabled?

Other languages/default changes:
https://gist.github.com/anonymous/67d55352e6a50035d8f5263fbbb24d2d

[ellelstone]

@Hombre57 @mm2

The posterization simulation was my request, while trying the different scenario offered by RT, like defining a custom output gamma of 1.0. Apparently, it's a non issue because not something a user would want, so just forget about that. We're not in hard-proofing either :wink:

My apologies! for being indeed confused about what the quoted passages were talking about. It didn't occur to me that anyone would want to use proofing to see gamma artifacts, and so I wondered if my frequent failure to express myself clearly had completely obscured communicating one of my main goals for soft proofing, which is the ability to soft proofing _from_ a linear gamma source color space. But again, depending on the RT working space profile TRCs, soft proofing from a linear gamma source might not be an issue (or even an option) for RT users.

@Hombre57

RT can load 32 bits Tiff files. Have you ever tried ? I did and it worked fine. OpenEXR is not supported however, but that's only a matter of incorporating the OpenEXR library, see issue #1895. We're not supporting any Alpha channel though, it would be dropped completely if OpenEXR were add to RT tomorrow.

This screenshot shows why I assumed RT can't load 32-bit floating point tiffs: http://ninedegreesbelow.com/files/soft-proof/sample-files/screenshot-rawtherapee-tif.jpg

IIRC (speaking under the control of the other devs @Desmis @heckflosse @iliasg), RT handles the image in a linear gamma color space all the way up, from the image loading (where the values are converted to float before applying the input profile -> https://github.com/Beep6581/RawTherapee/blob/softproofing/rtengine/rawimagesource.cc#L890) to the end of the pipeline, which is a Lab image. At different point in the pipeline, the data are converted to the RGB, XYZ and Lab color space back and forth. But to be honest, I feel a bit uncomfortable about that gamma thing, so will let the other devs comment.

As the RT shadow clipping default is set to 8 out of a range from 0 to 255, I'm guessing that somewhere along the line the TRC for the RGB working space profile is not linear, or else maybe just the user inputs are expressed using a perceptually uniform scale?

@Desmis

In Rawtherapee, except for the raw part, it is applied a gamma srgb, g =2.4 slope = 12.92

If all of the RT Working Profiles really do have the sRGB TRC (instead of each having its own standard TRC), it might make more sense for the RT Working Profiles to all have the LAB companding curve TRC, which is theoretically (JAB/JCH to one side) exactly perceptually uniform.

Do the RT Working Profiles have point curve TRCs? Or parametric curve TRCs? The equivalent RT Output Profiles all have point TRCs.

[Hombre57]

@ellelstone Could you share your 32 bits image on any sharing platform ?

[ellelstone]

@Hombre57 RT is not reading the embedded ICC profile. Does the RT code just assume that every floating point tif is 1. a linear gamma image and 2. in the sRGB color space? Assigning the correct profile from disk makes the image look correct. Here's a temporary link to a sample file: http://ninedegreesbelow.com/files/soft-proof/sample-files/two-apples-argyll-srgb.tif

[ellelstone]

Very often a camera input profile will produce colors that aren't even real, much less contained in a working space such as ProPhoto or Rec2020 or even ACES, which is designed to hold all real colors. Three such raw files can be downloaded from Section A2 of this page (the raw file white balance is UniWB for all three files, so please do see the notes for the appropriate white balance to use): http://ninedegreesbelow.com/photography/negative-primaries.html . These three files all have bright yellow or yellow-green "slightly imaginary colors". But dark saturated violet-blue colors also can easily be (much more than slightly) imaginary colors as interpreted by a camera input profile, and so easily out of gamut with respect to even the ACES color gamut.

Is there a way to soft proof from the Camera Input Profile to the RT Working Profile? The soft proofing seems to be from the RT Working Profile to the RT Output Profile, which at least for some raw files seems to reduce to a matter of "which profile has the larger color gamut - the Working Profile or the Output Profile?".

Also when the Working Profile and Output Profile have the same color gamut, the soft proofing gamut checks seem fairly random, when theoretically if the colors are indeed clipped upon conversion to the Working Profile, then converting to an Output Profile with the same color gamut should not clip any colors.

[Hombre57]

@ellelstone Gamma problem for 32 bits Tiff files solved in commit 81c5b1c. We were forcing a Gamma value of 1.0 as a workaround to broken Tiff file produced by some software few years ago, but I'm removing it now.

[Hombre57]

I was about to merge this branch into master, but thought again about the Working profile...

Nobody commented this :

So I think we should handle 4 paths :

1. Input (Lab) -> Monitor profile

This branch converts the Lab data (PCS if I've understood correctly) to the output profile. Should I convert it to the Working profile first ? This might shrink the gamut depending on the selected WS. IMHO, I don't see the interest of doing this, i.e. clipping data to a small gamut then storing it in a larger gamut output profile (I know this is not something anyone will do), but I'd like to hear from you.

@ellelstone Softproofing from Input profile to the Working profile will not be part of this issue. Could you open a new issue for that ?

[Beep6581]

@Hombre57 what is "input"? Is "input" actually the output at the end of the RT pipeline before being transformed using the monitor and/or output profile? At what point is the working profile applied?

[Hombre57]

Is "input" actually the output at the end of the RT pipeline before being transformed using the monitor and/or output profile?

Yes, how should I call it ?

At what point is the working profile applied?

Look at the tools/color_management.svg file. The working profile is actually not used when displaying to the monitor or saving the image file. It's only computed for image analysis if you enable Working Profile Histogram in Preferences.

[heckflosse]

@Hombre57 The working profile is actually not used when displaying to the monitor or saving the image file That really sounds disturbing! If the working profile is not used, how can rt work with the image?

[Hombre57]

Addentum : the Working profile is used here and there in the pipeline, so it has its utility, but not at the end of the pipeline. What is previewed is either a transformation from PCS/Lab (which is something different from the Working profile ?) to the monitor or when in soft-proofing mode, a transformation from PCS to output to monitor.

[Hombre57]

If you look at master, the Lab image was converted to the XYZ color space before being converted to the monitor profile, so it's the same behavior, I've only removed the Lab->XYZ conversion (was it wise ?) In the LCMS documentation, it is said that Lab and XYZ are the 2 main PCS, so I don't see why we should convert to XYZ first. Of course, I may be wrong :sweat_smile:

[heckflosse]

@Hombre57 Yes, I know the pipeline. The working profile is used for early steps in pipeline before converting to Lab. I just wanted to point out that your statement The working profile is actually not used when displaying to the monitor or saving the image file can be misunderstood ;-)

[Hombre57]

After some days or weeks of stall in the approval of the soft-proofing branch, I conclude that it's in an acceptable state of feature set and did merged it to master, so we can go on with the Gtk3 branch (see commit 50165da).

I only hope that I haven't forget to report all the cppcheck fix when merging master in to the soft-proofing branch first.

Now you can start flaming me for this merge, or put a constructive one on whether or not should we close this issue and delete the soft-proofing branch.

[heckflosse]

@Hombre57 Now you can start flaming me for this merge : Why should we complain? According to New major release - RT5 #3300 it should be merged.

[Beep6581]

I'm happy you merged it, thank you @Hombre57!

[Hombre57]

Thanks :wink:

I'm closing this issue which is quite long now. If you want a better softproofing or correct some bugs, I'd suggest everyone to open a new issue.

[Beep6581]

master merged into gtk3

[Beep6581]

A heads-up: commit 50165dab20aa4442cdb66fac960e40c062c15e13 is called "Merge branch 'master' into softproofing" when it should actually be called "Merge branch 'softproofing' into master".

[Hombre57]

That's the Git magic :wink: : I first merged master into the soft-proofing branch to solve the conflicts, and then the title is correct, then merged back the result in master. Being a fast-forward, there was no title to set for this merge.

I'm not very comfortable with Git, so I did it my way. Would you have recommended me to merge the softproofing branch into master directly, solving the conflicts here ?

[Beep6581]

I first merged master into the soft-proofing branch to solve the conflicts

That is perfectly fine, or at least I don't know of anything being wrong with doing that.

You are right about the fast-forward re-using the old commit message. It is strange (to me) that the network graph just switches branches like that... master was black, then suddenly its blue while the black line continues straight. Maybe it will make sense after some sleep...

[Beep6581]

I documented soft-proofing, feel free to expand it:
http://rawpedia.rawtherapee.com/The_Image_Editor_Tab#Monitor_Profile_and_Soft-Proofing