I have a question about resetting the sliders in Custom Primaries section (after setting Destination primaries: to Custom (sliders).
I noticed, after playing with the Rxy, Gxy and Bxy sliders that when you reset them they go to sRGB related numbers. But when I started they are set to ProPhoto related numbers. There seems to be a discrepancy there; I would expect them to go back to the original settings (The ProPhoto numbers in this case).
Is this something that still needs to be ironed out?
I’m expecting the default values, after resetting, to be related to the Working Profile that has been set. Is this assumption correct? The way it is now results in switching to a really bad looking starting point when resetting (most obvious when resetting all 6).
If you set Abstract Profile to Custom and dial in the Gamma and Slope settings, you then have a look at one of the other available settings and switch back to Custom again your previously dialled in Gamma and Slope settings are “lost”. To be more exact: They are set to the values belonging to the setting you switched to earlier.
Is this by design so that you can tweak the otherwise “fixed” values that belong to, say, BT709? I half expected to see my previously dialled in numbers.
For the second “gamma and slope”, it’s normal, because in all cases the mode “cutom” correspond to the last you have choose. For example, l you choose “Prophoto 1.8” and choose "Custom it is "prophoto 1.8 settings which appear as choices, and which you can modify, for example, change gamma to 1.9 or slope to 4.1…
Fo the first point, its the choice I have made. The GUI is extremely complexe . This brought a lot of code and quite complex optimizations especially by @floessie and @heckflosse. I have tested various solutions, but the “less bad” is the one that is in place, as the number of possibilities is impressive due to the fact that you can choose a destination profile different from working profile, or the same by changing primaries or illuminant (sliders or CIExy).
Wayne @Wayne_Sutton asked me some time ago, about a reset and my answer was what reset because it depends on what you want to do that the GUI can’t guess. To do a reset that returns the primaries and the illuminant to “default”, you must (re)select the same destination profile as “working profile”.
I assumed this was the case, just wanted to be sure. The way it is implemented seems more logical then my (half) expectation.
I can life with the way it is implemented at the moment.
There is another workaround to reset the sliders to their original: Switch to the Default setting and then back to Custom (sliders). Downside being that this resets all 6 sliders. Not that big of a problem.
I don’t think that is needed, certainly not at this point. Once this goes mainstream, and assuming many people will use it, a reason might surface that validates a GUI change, though.
In most cases we act on the 3 channels R,G,B which are at their values at this moment of the process.
So we don’t only act on the luminance. Depending on the case, we use :
either a function of LCMS which calculates according to gamma and slope (TRC parameters) some parameters which will be passed to the virtual profile
or the new RGB values are calculated directly by applying gamma and slope (case where the user does not use the primaries)
The 2 values gamma and slope are used to calculate 5 parameters which allow the connection of the linear part and the parabolic part without discontinuities. This is the absolute condition to have a good result.
The values using cat02 or cat16 are only taken into account if Ciecam is activated, to elaborate the calibration if you want to change the illuminant of the input profile. This will change the RGB values, otherwise everything is the same as before.
This part I don’t understand fully, but probably because I do not know enough about how RT works internally. But the TRC is not derived from a ciecam model if I understand you right. Ciecam is only used, in whatever version, for color adaptation transforms.
I think it’s clear. I’ll try to find something about the linear and parabolic parts of the TRC.
thank you so much!
While the term ‘abstract profile’ makes a lot of sense in the classification of profiles, it may be useful to think about a different name for the module, revealing more about the intended use. The name is pretty abstract (3a or even 1b). Has this been discussed elsewhere?
I have to say I think I agree about changing the name to something else besides abstract profile. Since there’s already a type of ICC profile that does LAB to LAB conversions (basically they are what cube luts are to RGB) it’s kind of odd to see something called “abstract profiles” where you load in the input and output color profiles. One would expect being able to load in that particular type of ICC profile given its location! I think the abstract profiles bit would be good in its own module, perhaps in the same tab as Retinex and CIECAM. Even if the name is kept, at least it wouldn’t be mixed in with the color profiles.
That’s just my two cents. Ultimately it’s not terribly important
There has been a long (very) long debate on this subject since October 2020 (name, location, what it’s for…)
I remind that “abstract profile” does not load or change the input and output profiles…
They only use “working profiles” (which are not ICC profiles, but only RGB->XYZ code)
Yeah, ultimately my opinion is a cosmetic complaint and the most important thing is the function. It’s always nice to have new tools in the toolbox .
Plus if I want to use one or more abstract icx profiles it’s easy to chain them together with the basic input profile at the start with lcms2’s linkicc function. I’m.getting so deep into color management I think I’m starting to “color micromanage”
Hello Jacques, I like your abstract profile tool !
Found a little problem though. Open a raw (nef in my case), then go to the Color tab, choose Abstract profile - User defined. Then choose for Destination primaries Custom (sliders). Set Rx, Ry, Gx, Gy and Bx to 0 and By to 5.0 and RT segfaults.
Terminal says this:
Thread 97 “rawtherapee” received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbaffd700 (LWP 149681)]
0x00007ffff69040fa in cmsWriteTag () from /lib/x86_64-linux-gnu/liblcms2.so.2
(gdb)
