Discussion in 'Digital Darkroom' started by dmitry_shijan, Mar 23, 2021.
Yes, as with all your posts on this thread, you guess.
Ahh, touché, my man, I'm cut to the quick.
It's what the ICC say it is in that pdf file I linked to.
With a transfer function of 16x the normalised brightness level below a value of 0.001953, and raised to the power of 1/1.8 above that value.
So in an 8 bit space the first 7 levels are linear, and in a 16 bit space the first 127 levels are linear. Only after that do they have a 'gamma' of 1.8.
It (ProPhoto RGB) follows a gamma curve of 1.8; yes or no?
In the same way that sRGB neither follows a true gamma of 2.2 nor 2.4, then, no.
Just look at the function clearly shown in the ICC's published specification for ROMM RGB: Below a normalised (referred to 1 as maximum) brightness level of 0.001953, the brightness value is simply multiplied by 16, and then further by 255 or 65535 to obtain the digital level number for 8 or 16 bit spaces, respectively. Only beyond that is it raised to an exponent of 1/1.8.
So in the exact same way that sRGB and ECI RGB Version 2 (L*) don't follow true gamma curves, then neither does ProPhoto RGB / ROMM RGB.
You can't argue that the use of the term 'gamma' is incorrect for some TRCs, but not for the TRC of ROMM RGB.
And before anyone else points it out. I made a mistake in calculating the breakpoint in 16 bit space. It's the first 2047 levels (!) that follow a linear slope.
My 'provocation' was in the interest of getting explanations to:
1. Why, exactly do you believe that the steeper tone curve of L* 'gamma' works, but not that of the sRGB or Adobe RGB spaces?
2. How use of 'calibration' against transparency dyestuffs translates to the different dyestuffs used in negative film(s)?
3. How Photoline's 'non-destructive' sidecar file system differs from that of the .XMP sidecar file in ACR?
4. How manual alignment of histograms post-scanning substantially differs from using optical or camera-based means of pre-alignment in a RAW file?
5. And most pertinent; How manual alignment of histograms can possibly be faster and more automated than using Autocolor or other single-click operations?
So you're using this forum as free advertising for your primitive-looking hardware rig and convoluted software solution?
sRGB has a TRC, not a gamma curve; agreed.
There are two options; TRC or a curve that follows the gamma formula. There is nothing unique in ProPhoto RGB or ColorMatch RGB (to name another Working Space) with an actual 1.8 gamma curve. IF you want to talk of such a defined and actual curve, you simply state the curve based on it's behavior and in both cases, it's a 1.8 gamma curve; nothing more.
If such a curve does not follow the gamma formula, it's not a gamma curve. It's a TRC.
See: Charles Poyntons work on this.
Which ROMM RGB patently doesn't, according to its published function formula!
How can you argue with that fact? Published plain as day by the ICC and set in stone in ISO 22028-2:2013.
Of course it follows the gamma formula or it's not a gamma curve. It's a TRC. I don’t know if you are purposely trying not to understand this, or if you are really struggling with it.
As for such published specs; examine the history of SMPTE-240M and Adobe RGB (1998)!
OK kids! Enough! A pure gamma curve is just that: a curve that abides by the gamma formula for all of its parts. It's also a TRC, a tone response curve that just happens to follow a pure gamma formula. A TRC that doesn't follow a pure gamma formula for all of its parts is still a TRC but not a pure gamma curve. Got it? Now move on, show;s over.
Yup. Said pages ago. With a link to an article that said it too.
A gamma curve has to follow that formula, a TRC doesn't have to but may.
Separate names with a comma.