soft proofing for the output profile?

[agriggio]

currently soft proofing is possible only of you have selected a target printer profile. I'd like to be able to soft-proof for the output profile instead. this seems easy to do, if I understand the LCMS docs correctly. what do people think? in terms of UI, the simplest solution would be to have the soft-proof button always sensitive, and just do soft-proofing for the output if no target printer profile is selected in preferences... opinions?

[Beep6581]

Good idea, and the out-of-gamut-check branch works, though I haven't tested yet whether the marked areas are correct and accurate.

[agriggio]

ok, I'll submit a pr. for the oog branch I'm cross checking with darktable and the results seem reasonable: slightly different (to be expected since the pipelines are different) but in the same ballpark

[agriggio]

I've just pushed a branch softproofing-output-profile that implements what described above (and supersedes out-of-gamut-check). Please let me know how it feels. I know that soft-proofing an output profile might seem strange, but I see two use-cases for this:

• for people who have a wide-gamut screen and want to export to sRGB
• for checking out-of-gamut colours

I'd be happy to hear from more knowledgeable people if this makes sense... ping @Desmis @iliasg

[Desmis]

@agriggio Alberto

First, thanks for this new feature, RT is becoming more and more professional :)

I must admit to being a little lost between the various places and soft-proofing settings. And reading Rawpedia does not clear at all... Especially that it is necessary to go click on the icon with a "!" in "image editor" to have the result of "output profile" in the tab "color management". But this is secondary

Soft-proofing seems to work well for common cases, but 2 remarks: 1) the gamma internal to each profile seems to be ignored (or is there extra manipulation to be done?).

• Ex: same result with "output profile" RT_srgb, RT_srgb_gbT709, RT_srgb_g10, while we see the histogram change significantly (but perhaps it is normal)
• same comment with "output gamma" and "free gamma"

When I try with my very very old Photoshop, and "format d'épreuve" , "Couleurs d'épreuve", there are important differences. But perhaps we don't speak of the same thing, or I miss something :)

2) it also seems obvious that no "Munsell correction" is applied when reducing space (Prophoto ==>sRGB) jacques

[agriggio]

Jacques, thanks for your comments, this is exactly the kind of feedback I was looking for. what I tried to do was to generalise the support for soft-proofing to work not only for the printer profile. however, I am not really sure what the results should be :-) my use case was to be able to check for out of gamut colors, and for that it seems to work. I don't really know about gamma, my understanding was that gamma is just an encoding thing so if you have proper colour management you should not see any difference in output, except for posterization differences due to different ways of discretizing of course. I'll double check the code and see what I can do. finally, you'll have to school me on munsell as I have no idea what you mean :-)

[Desmis]

@agriggio Everybody has not or don't want to used "color management", for example for Web. In this case, if your image has a good rending with RT, by the effetct of color management, when you "export" to wb, this image may be very very bad. In Phtoshop for output, you can have an output "RVB internet standard srgb" without color management. In this case, gamma is take into account. If I use, the box in the bottom of the editor, and choose "RT-srgbg10" the image chnage...but I don't think it is the "normal" usage ? or ???

For Munsell correction: 1) when you change saturation in RGB mode, it's anything, nothing happens properly, the colors are changed, the luminance is changed, this explains all the discussions on the curves and sliders in RGB mode or its direct derivatives HSV, HSL 2) Lab mode has been created about 1980, everybody thinks it is "perfect". In fact in 99% cases it is false. Sometimes a little, sometimes huge. For example, when you change chroma for blue , blue becomes purple (with a delta that can reach 0.4 radian), When you change red, red become orange with a delta than can reach 0.3 radians. Most of software live with that, except RT. I have implemented some years ago, A Munsell correction with 195 LUT. "Munsell" is a color system, which correspond to the human view.... But it is for "engeneers", cartesian, not as Ciecam an Cat02 :)

When you check "avoid color shift", this correction is applied. See the comment in Rawpedia- (in English but no translate by me :)
http://rawpedia.rawtherapee.com/Color_Management_addon

But this is only avaible in "internal", when at the end you convert Prophoto, to srgb, there are 2 problems:

• gamut : this correction is obviously done
• Munsel correction : never done

jacques

[agriggio]

thanks Jacques, I'll see what can be done for gamma, indeed what you say makes a lot of sense. for munsell, I'll leave that to me knowledgeable people :-)

also ping @Hombre57 (sorry that I forgot before!) who I think implemented the current soft-proofing

[agriggio]

related: #3781 as I suspected, this is a rabbit hole :-) I'm interested in working on this, but it should be after 5.4 is out

[Beep6581]

The OOG warning does not seem to take the rendering intent into account. I would expect to see no OOG warnings when using the perceptual intent, but it looks identical to that when using relative.

Sample files: https://filebin.net/86yv0uqrad021lbr

"Old laptop" is the monitor profile of my previous laptop, the profile includes perceptual mapping tables.

[heckflosse]

@agriggio Can you choose a different colour? Bright green is already used for the motion mask of pixel shift files. That may confuse users.

[agriggio]

@Beep6581 maybe I misunderstood, but to me oog warning means "show me the pixels on which the rendering intent has an impact". therefore, this is by definition independent from the specific intent selected. this seems sound to me, otherwise all intents will bring all the pixels in gamut... what am I missing?

@heckflosse sure, will do

[Beep6581]

You're right.

[agriggio]

@heckflosse I changed the oog color to cyan (same as darktable). By default LCMS uses mid gray I think, and that's also what GIMP, Photoflow and the current dev of RT use. But to me, cyan is better for this as it's much more visible.

@Desmis I tested other tools to see how they behave wrt. gamma, and they all seem to do the same as what is done here. No matter what gamma the proofing profile has, I always see the same picture. I tested darktable, Photoflow and GIMP. So I'd say that the current behaviour is at least a common one... of course, if there are better ways they are always welcome, but my knowledge of lcms (and color management in general) is too limited to know what to do, sorry.

[Desmis]

@agriggio For me and personal usage no problem :), and it is obvious - it is the goal of color management - that there are very small differences or not visible. (if you use layers differences, you will see that between gammasRGb and gammaBT709, there ares small differences in shadows)

But I think there is number of users using web, with navigators whithout color management, or searching a specific rendering for printing via CMJN. In this cases changing gamma is usefull, and have the possibility to "see" the behaviour seems to me interesting.

Some software as UFRaw have (or had... ??, a long time I have not tested) this possibility to modulate gamma. 2 years ago I had developed a branch called "gamma differential", but in front of the little enthusiasm (it's an euphemism), I deleted it.

jacques

[agriggio]

@Desmis it's not that I don't want to do what you suggest, but I just don't know how to... how is it possible to know how an image will look like on a display with no colour management at all? To me, it seems that your safest bet is to stick with sRGB and standard gamma, but even that doesn't guarantee much (see e.g. the various too bright or too dark entries in play raw threads on pixls.us). But I'll be happy to be corrected! :-)

btw, I just pushed another changeset to the softproofing-output-profile branch, that allows to check for colors that are out-of-gamut wrt. the monitor profile. This is done by having the "soft-proof" toggle unchecked and the "gamut check" toggle checked. I think this is useful, although I don't know how accurate it is (or whether I did it correctly). when cross-checking with GIMP the results seem reasonable but not identical... and I'm still not sure that I did it correctly in GIMP too :-)

[Desmis]

@agriggio

Dont't worry, there is not fire :) I just want to point out some things that seem important to me 1) how an image is seen on web with some navigators whithout CM. You can see how it behaves by putting a profile with a different gamma in the combobox (which has no name) at the bottom of the "image editor", by replacing "monitor profile" by "output profile" (I think it is not a good solution, but you can see the big differences)

2) the final conversion - in general Prophoto (working) to sRGB (output) - is not as efficient as in internal : LCMS does not control delta Munsell<=>Lab. In fact we loose (in part) all benefits in some cases. But I admit that Softproofing is only "The tree that hides the forest"

I will look to your work on the softproof branch.

Best regards jacques