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 notifications@github.com 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.