@heckflosse Yes, there is some problem here - the histograms should match according to my understanding of the tool. For another RAW file I see noticeable desaturation after performing the same procedure. The Color correction regions is not documented in RawPedia itself…
Do you think it is worthwhile to submit a bug report about that?
Which raises the question, “Where can I find a v4 ProPhoto profille?”
Not sure why you replied to me, but the RTv4_Large profile in RawTherapee is a ProPhoto v4 profile.
Common ones are
As @Thanatomanic said, large is the counterpart to ProPhoto.
Medium, Adobe RGB.
Rec2020 is in between and nice to use in most cases because it doesn’t include imaginary colours.
Please let me sleep about that issue first!
@teplit If you are so upset with the current state of RawPedia as documentation, feel free to lend your own expertise and help fill in the gaps. Issues · Beep6581/RawTherapee · GitHub
I find the way that ‘gamut’ is normally described/explained counterintuitive, e.g. often in non-linear squiggly Lab plots or such. On the other hand, seen linearly at their simplest, gamuts are all just plain old RGB cubes (or better different parallelopipeds).
As we are normally forced to output our images in bounded non-negative integers (i.e. 8 or 16 bits), at its simplest out-of-gamut refers to those tones that happen to fall outside the parallelopiped, which means that they are necessarily less than zero or above clipping in a given space and color channel. You could also say that they are out of bounds, out of range or off limits, it’s all the same thing.
Clearly as image data is projected from one space to another by 3x3 matrix multiplication, some tones will be pushed of bounds (err… gamut) because the math will push them above clipping or below zero in some color channel. Of course if we were to fully work in floating point we would have no upper and lower limits, therefore we would not have to worry about gamuts during raw conversion - other than for some practical reasons as mentioned upthread or for output.
That’s the gist of it, no mysteries just parallelopipeds.
I do understand this, except I think it is about mathematical convenience. I am not certain real life colour is characterized so ideally; hence the mystery. As I vaguely mentioned above, out-of-gamut and out-of-bounds are two different things. It also depends on the robustness of the transformations and the colour spaces it resides thereafter.
Well, yes, the HVS sure works in mysterious ways and once one starts making non-linear corrections things become more complex. But linear colorimetric gamuts as we intend them in a raw conversion context are just simple parallelopipeds seen from different perspectives, and there is no mystery in that or in the linear transformations between them. Of course one may try backward somersaults to try to keep things in-gamut, but that’s a different game.
Indeed, papers are still being written about that. In any case, what do you think about this checkbox of theirs? (To stay on topic.
)
I think that ideally the whole shebang should stay in linear floating point until the output. But I do realize that some important tools are not designed to work with negative values for instance, so it makes sense to make sure that the image stays in-gamut earlier than that. Making the checkbox a less prominent advanced option makes sense to me, as most users should never need it.
If you have a hypothetical infinite RGB parallelepiped (you cannot really call it that anymore, can you?), an insignificant amount of volume would be dedicated to real, observable colours, wouldn’t it? So, what is the usefulness of this construct?
A color constructed with a negative amount of light makes no sense, it’s non-data, so you need to chuck it out. Even if it happens somewhere along your processing pipeline. Or can the pipeline allow for non-physical things to happen?
I do think in the context of this discussion it is useful (indeed I would say essential) to maintain a distinction between “out of gamut” and “illegitimate” (or possibly, “Out of Range” or “Out of bounds”.
An illegitimate value is one that is less than zero or greater than one. Some processes may produce them and the question is then whether to carry those illegitimate values to subsequent operations or to legitimate them somehow. The default is to legitimate them by the simple expedient of converting negative values to zero and values greater than one to one. The checkbox offers the option not to legitimate them.
An out of gamut value is one that may well be within the legitimate range but is outside the parallelepiped that describes the gamut that can be reproduced.
If we are discussing the processing options then we need to keep in mind the distinction. There is a good reason for allowing out of gamut values during processing that can then be brought into gamut at the end. On the other hand illegitimate values can cause problems with subsequent processes that do not know how to handle them.
The key is to keep things as accurate and legitimate as long as possible. Once suspect, the data is nearly impossible to trace; essentially, it becomes nonsense.
However, legitimacy is a difficult thing because as you can see from @ggbutcher’s camera’s colour space you already have lots of room for imaginary colours to happen.
Maybe, maybe not. It is a bit like saying imaginary numbers make no sense so should be chucked out. However, much electrical and electronic work (particularly with alternating current) would not be possible without taking imaginary numbers into account even though the end result is very real indeed.
If using illegitimate (or “out of range” or “out of bounds”) numbers gives one a desirable result that cannot be achieved another way then they serve a purpose. The only question in my mind is whether preserving them comes at a cost to some of the other processes.
I would favour keeping the option to use illegitimate numbers but would rename the check box to something like “restrain values to within bounds values” and have it checked as a default, which would avoid huge changes to the user interface. (Actually my preference would be to have the box called “use out of bounds values” and have it unchecked as the default, but that might require to much reprogramming elsewhere.)
PhotoFlow can allow such values to pass through. I would imagine it would be possible to do the same in RT (i.e. for the entire pipeline), though it would take some rejiggering. Not sure it would be worth the effort or if there is enough interest.
Yes, that happens after the conversion from camera color space to xyz.
I think that in the camera color space, before the conversion to xyz and the working color space, should not be allowed negative values, they are there only because imperfect algorithms.
Before the conversion to XYZ it’s possible to obtain negative values due to:
-black substraction (?)
-some (not all) demosaicing algorithm
-false colour suppression
-CA correction
-lens geometry correction
-resize algorithms
-capture sharpening (?)
In my opinion these are values that should always be legitimate clamping they to 0.0, ideally at every step
The problem is that the 3x3 color matrix for the conversion to xyz ( and then the working space) doesn’t expects negative values
These are way after conversion to XYZ. That does not mean, they are linear btw…
I think I understand the distinction you are making, though in the context of raw conversion I am more comfortable with the more precise terminology used in the last paragraph:
By this wording, which I subscribe to, the parallelopiped of the active space (say with origin at zero and normalized to 1) IS the gamut. Tones are either within or without it. Values less than zero and above 1 are outside of it, hence out-of-gamut. Terms like ‘range’ and ‘bounds’ at this stage confuse the issue and need not apply.
Of course there is value in preserving some out of gamut tones to try to bring them back into gamut later on in the process. There is also value in getting rid of out-of-gamut tones that may cause difficulties in later processing (for instance some values less than zero), call them illegitimate if you will. I don’t think the end user needs necessarily to know or understand the distinction.
In this reading one suggestion for the checkbox’s name could be ‘Preserve Out of Gamut Values’ and the relative hint could read ‘Out-of-Gamut tones will not necessarily be clipped/blocked early on in the conversion process and attempts will be made to bring them back into gamut before output’.
No, that was not my meaning. Les us assume that I am using sRGB as my working profile and output profile. An RGB value of 1·00, 0·985, 0·001 would be a legitimate value but could well be a colour that is outside of the RGB colour space and so is out of gamut.