Hi Gernot Hoffmann



what this "Opti RGB" in page 15?

thank

Thank you Gernot Hoffmann!

A "disaster", uh?

We'll have to tell all those fools who use ProPhoto RGB pronto, then, and let them know with no further delay that all those images that they produced from ProPhoto RGB, and thought looked beautiful, are actually horrible. Because you say so.

Quick!

HP didn’t give their display quality in terms of the percentage of the
gamut, but their press release did say the Elitebook’s DreamColor LCD
could display over 16 million colors. The Adobe RGB color gamut has approximately
16.7million colors in it, and after doing a little math we’re given a
96% gamut representation. Not bad at all.




What utter nonsense. Gamut volume and bit depth are two totally separate things.

It's always shocking (though no longer unusual) to see someone writing a review who understands nothing of the basics of what he is writing about. Where was this review posted? Who is this writer?

Any color space, even the smallest ones, can be subdivided into a theoretically infinite number of steps depending on the bit depth used. The only limit is the processing power available. In 8-bit color spaces with 3 primaries (like RGB) you have 16.7 million [2^(8*3)], in 16 bits you have 281 trillion [2^(16*3)], and so on. None of that increases the gamut by one little tiny amount.

Gamut volume, on the other hand, is the portion of human-visible color range that a given color space is capable of reproducing. The maximum possible color range is (roughly speaking) the volume of Lab, which is a device-independent color space, like XYZ or LCH and a few others. But no matter how gamut volume is expressed (by percentage or by using absolute numbers), the "number of colors" is *never* the way it's done, since it's meaningless for the reasons stated above.

On the contrary, ProPhoto RGB contains two of three primaries which are
non-existing colors (chromaticities
outside the horseshoe contour). Mathematically possible
but practically a disaster, IMO.





Just as Marco did in post #13, I found the above quoted statement in Prof. Hoffmann's #11 disconcerting. I hope further discussion of this is forthcoming.

Actually, I would like to replace 'a disaster' by 'ugly':

Let's have a view at the graphic on p.3 in this doc:
<http://www.fho-emden.de/~hoffmann/gamcomp18062006.pdf>

It shows the chromaticity diagram with gamut triangles for
sRGB, aRGB=Adobe RGB, pRGB=ProPhoto RGB and my private
color space oRGB=OptiRGB.
Furtheron more than 1100 spot inks and the primary inks for
CMYK ISOCoated and for my inkjet, where 'inks' means here
'colors of inks on coated paper under D50'.

Almost all these colors are in-gamut for the wide-gamut color
space oRGB. Compared to this, pRGB seems to be far too large,
which causes quantization problems, unless 16bpc is used.
The primaries for green and blue are non-existing colors
(mathematical constructs), and, what is less obvious, the
primary for red is practically invisible because of lacking
power at 700nm. 255,0,0 in pRGB should be black, but it isn't
in PhS.
That's what I meant by 'disaster'. So we have an RGB space
where we cannot choose for only one channel 255 (or the largest
value for 16 bpc). More precisely: in PhS CS2 we can choose
such a value but there is no warning.
Plenty colors inside the human gamut (which is not indicated
in PhS) are out-of-numberspace in Lab, where a,b are confined
between -128 and +127.
In oRGB this happens as well, but only for a smaller percentage
of possible colors.
The doc shows on the following pages the truly exaggerated range
of pRGB in Lab.

This somewhat strange color space has its roots in the RIMM/ROMM
concept by Kodak, as found here:
Ph.Green+Lindsay MacDonal Ed.
Colour Engineering
Chapter 14
K.Spaulding+E.Giorgianni
Implementation of device-independent color at Kodak

RIMM is scene-referred, ROMM is device-referred.
RIMM can be considered as an RGB space between camera RAW
and the ICC Profile Connection Space (PCS). Concerning the
primaries and some other features it's the same as pRGB.

The authors are talking about nonlinear manipulations for R'G'B'
(gamma encoded) simultaneously to all channels, but without
specifying these manipulations. We can imagine for instance a
contrast improvement by an S-like Curve.
Everybody knows, that this can cause strong color shifts,
depending on the strength of the manipulation.
RIMM/ROMM was optimized for minimal hue variations (as defined
as deviations from straight lines in an a*,b* projection).
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.

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.

Best regards --Gernot Hoffmann

Hi Gernot Hoffmann

It's bossible to obtain this profille (oRGB)?

thank

Well, I've carefully read Prof. Hoffmann's post and his PDF.

While his description of the ProPhoto RGB space seems beyond reproach, and I have no quarrel with any of it, I still see nothing in there to explain why, in actual practice, those of us who have been advised by diverse authors to work in ProPhoto RGB, and have actually done so for years for all our digital photography work, carefully remaining in a 16-bit workflow and ever mindful of the constraints of inkjet and continuous-tone printers, should change our workflow now.

My current ProPhoto RGB workflow certainly beats the results I (used to) get from my old Adobe RGB workflow, let alone the sRGB workflow required by non-pro local labs.

Now, with 16-bit printing in Photoshop 11 ("CS4") on the Macintosh platform, I feel even more confident and am getting improved results. I'm impressed that Adobe gave us this advanced feature, which more than compensates for the lack of 64-bit functionality.

It's good to see disaster downgraded to mere ugliness now, , and I would welcome any corrections to my way of thinking here.

There must be something I'm missing here, doubtlessly due to my own personal limitations.

Any further input will be most welcome.

Kokii,

the profile is here:
<http://www.fho-emden.de/~hoffmann/OptiRGB.icc>

As already explained - an exercise. Personally,
I'm doing everything either in sRGB (simple appli-
cations) or AdobeRGB (high quality).
Furtheron, it's always possible to improve images
in Lab and CMYK.
Following Dan Margulis, Professional Photoshop,
optimal offset printing results are achieved by
final editing in CMYK.

Best regards --Gernot Hoffmann

Aaaaaaaaaaaaah… jetzt werde ich ruhig sclaffen können.

Following Dan Margulis, Professional Photoshop, optimal offset printing
results are achieved by final editing in CMYK.




None of which is remotely relevant to my workflow. I'll sleep well tonight.