Softproofing branch

[Beep6581]

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

[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