Softproofing branch

[Beep6581]

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

[Beep6581]

When I run a1981db 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 - mm2/Little-CMS#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]

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.

[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 😉

@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 😉

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 😅

[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 😉

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 50165da is called "Merge branch 'master' into softproofing" when it should actually be called "Merge branch 'softproofing' into master".

[Hombre57]

That's the Git magic 😉 : 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