You seem to be assuming that, upon conversion to ProPhoto RGB, and/or subsequent to an image edit, certain colors in the image will drift into the "imaginary" region of ProPhoto RGB and be forever lost, with dire consequences -- or "disastrous", or "ugly".
In my years as an imaging professional using fully color-managed late-binding workflows I have detected no ProPhoto RGB "misbehavior" that was so glaring that I or others noticed it.
Seems to me that your argument is informed more by Dan Margulis' own prejudices against wide-gamut RGB color spaces than by arguments whose validity I can recognize based on my own experience. I suggest that you take his "advice" with a generous grain of salt.
>RIMM can be considered as an RGB space between camera RAW and the ICC Profile Connection Space
You can say that RIMM is the intermediator between the input scene's Raw data and the ROMM/ProPhoto RGB space that one can use for output, storage and manipulation -- but it should not be implied that Raw itself is a color space.
A color space has primaries and tonal curves. Camera Raw is simply a mathematical construct for input that needs to be translated into colors usable for output. It has no defined primaries or tonal curves.
>The authors are comparing their good result with the bad result for some other nameless wide gamut space.
>Now, for what is it good - useful strategies ten years ago ? For nothing, because nowadays and in future manipulations of this type are done professionally in Lab.
That is, by Mr. Margulis and those who get lost along with him in his "canyons". Not by me or other professionals that I share knowledge with. You wish to sound as if your advice is based on widespread practice, but it's actually free advertising for someone who I have to admit is a sharp self-marketer who, on his way to dubious fame, also manages to dupe intelligent people.
>Surprisingly, the oversize of pRGB, as defined by the gamut triangle in xy, or by a volume in Lab, was not chosen so large because of the necessary gamut size but because of the hue robustness against 'luminosity' changes.
Not true. The gamut size was very much a core consideration in creating RIMM/ROMM, not secondary to what you call "hue robustness". It was a matter of finding the best compromise, among other factors, between quantization due to "out-of-locus" primaries, efficient encoding, gamut large enough to encompass real-world surface colors and suitability for storage and color/tonal manipulation.
To quote:
>ROMM RGB was designed to provide a large enough color gamut to encompass most common output devices, while simultaneously satisfying a number of other important criteria
i [described on page 2 of the PDF document cited below].
>[...] Increasing the gamut can only be achieved by trading off against correspondingly larger quantization errors. If the primaries are chosen to include the maximum possible chromaticity gamut (i.e., the entire area within the spectrum locus), a significant fraction of the color space would correspond to imaginary colors located outside that region. Therefore, in any encoding using such a color space, there would be wasted code values that would never be used in practice. This would lead to larger quantization errors in the usable part of the color space than would be obtained with different primaries defining a smaller chromaticity gamut.
b It is therefore desirable to choose primaries with a gamut that is big enough but not too big.
>[...]
he primaries selected for RIMM/ROMM RGB [...] encompass the gamut of real world surface colors,
b without devoting a lot of space to non-realizable colors outside the spectrum locus.
>"Reference Input/Output Medium Metric RGB Color Encodings (RIMM/ROMM RGB)"
35
Replies
AdChoices