Just did a factory reset on the Eizo CG247X I’ve got in front of me. By default it uses the piecewise sRGB EOTF (for sRGB modes). Same was true of the Dreamcolors at my previous employer.
I see both 2.2 and piecewise in the wild, sometimes from the same manufacturer. It’s super frustrating.
Yeah, wanted to mention Eizo, we calibrate ours using the sRGB piecewise.
Yes, I do know that EIZO comes with the piecewise… and their competitor NEC comes set with simple gamma, though the Spectraview software does offer the piecewise (both the NEC app and the one they licensed from BasICColor).
And any high end monitor with internal programmable LUTs of course you can do what you will…
I think my point though is here we set all our monitors to a simple curve because:
The only exception is delivering stills for web deployment, but that’s when it does not really matter, because… MacOS color management and/or A Dough Bee color manglement will end up displaying the same since everything gets “managed” based on the hardware calibrated profile to come out quite literally the same no matter the TRC.
So… if everyone had functional color management, we could quite literally discard the piecewise TRC, and just make sure all images are tagged with whatever space you felt like exploring on the day.
But color management is a problem for mobile devices due to overhead and powerdrain… so that dream is still a few years off…
…But here near the end of 2021, at least we are finally making movies at 24 flat and not 23.976…
Interesting that when I read the LUT our of my EIZO set to sRGB I get the same curve as when it is set to 2.2, go figure I know we don’t program the monitor to do anything LUT wise as it has the ones we need built in!
23.976 - get that all the time.
Kevin
[quote=“KevinJW, post:33, topic:4024, full:true”]
Interesting that when I read the LUT our of my EIZO set to sRGB I get the same curve as when it is set to 2.2, go figure I know we don’t program the monitor to do anything LUT wise as it has the ones we need built in![/quote]
You’re reading the internal monitor LUT? Interesting… does the EIZO software also change the ICC profile when you change the monitor setting and are you on Mac or Win?
Yea, one of the studios I work with just in the last year or so started doing everything 24 flat. I have no doubt 23.976 lives on if at least in that special hell reserved for endlessly repeating decimals…
Fascinating thread! Thought I’d mention that you can see what the color profiles are set to on a Macbook Pro M1 by going into the custom menu in the Display settings as described here:
Here you can see that the HDR P3 displays (Apple XDR Display (P3 1600 nit), Apple Display (P3 500-nit), HDR Video (P3-ST2084) displays use a pure 2.2 power function:
This is interesting and I remember you mentioned it on Slack. Our CG2730, upon being set to sRGB are certainly using the piece-wise EOTF. It is both measurable and verifiable with test patterns.
Nowadays, technology allows us to calibrate our monitors to sRGB gamut. But do we need to do that?
When you calibrate your monitor to sRGB you get less shadow tones than you would with gamma 2.2. As a result, in an image with embedded 2.2 profile on an sRGB monitor in Adobe Photoshop, the shadows will be cut off: 8 bits RGB 5 5 5 5 will turn into 8 bits sRGB 0 0 0. Now about video. Video viewer apps usually do not have Color Management, so videos with gamma 2.2-2.4 (youtube) will look on sRGB-monitor not contrast, with light shadows.
In my opinion, a good option, monitor calibrate with gamma 2.2 (2.4), and sRGB images watch using Color Management 
My opinion, the sRGB standard was not originally intended to calibrate monitors. The sRGB standard was only designed to work in systems (apps) that support Color Management. In that case on a dim monitor with gamma 2.2 and brightness of 80 cd/m2 (in sRGB standard such monitor was called the reference display) in a graphic program with Color Management enabled any image without color profile or with embedded sRGB profile became lighter in shadows and details in shadows became better visible. The monitor was not bright and the shadows were very black, so I wanted to make them lighter 
In short, the monitor was calibrated with gamma 2.2, and all sRGB images were viewed on it only with apps supporting Color Management. For example, Adobe Photoshop.
Damn, I thought my opinion would solve all the problems
We need more lawyers of colour to clarify what is written in this document
@jack.holm is the only person that contributed to the authoring of the standard in this discussion and he kindly provided clarifications about it. People, as he said, are free to do what they want with it.
Is this correct?
I looked. I only saw four names explicitly listed in the authors section, and five listed in the acknowledgments directly.
Has anyone actually reached out to any of the authors listed, or to those in the acknowledgements?
Your quote is incomplete, I said “in this discussion”.
I simply asked if he was one of the four original authors?
If he is one of the authors, perhaps we can work to get that reflected in the origin document included at A Standard Default Color Space for the Internet - sRGB so that it is historically accurate?
You asked whether Jack was one of the authors, the IEC standard does not list any. The standard specifies that “International Standard IEC 61966 has been prepared by project team 61966: Colour measurement and management in multimedia systems and equipment, of IEC technical committee TC100: Audio, Video and Multimedia Systems and Equipment.” Jack was the technical secretary of TC100 (and also vice chair of ICC by the way), so yes he did contributed to the authoring of the standard.
That being said, good point about contacting some of the 4 authors in your link.
Cheers,
Thomas
It can’t be called necroposting, when it’s an immortal topic, right? 
Current ACES candidates still have sRGB only option for “office” displays. I think (and hope), the final product should provide an ODT for pure 2.2 power function as well.
For now with ACES 1.x many artists (probably the most?) don’t even have the option to monitor their work correctly. Only the ones, who have either their monitors switched to sRGB mode that also have piecewise sRGB EOTF (or have this by a random decision of a display vendor), or calibrate their displays via ICC profiles, that force their usually pure power function displays to perform like piecewise sRGB EOTF monitors.
And all the rest, who either choose to calibrate their monitors to Gamma 2.2 for bright surround (by uploading calibration LUT to a monitor for example), as it was originally intended for sRGB encoded content, or just can’t afford calibration at all and thus most likely also have pure power function displays, have to see their shadows darker without Gamma 2.2 option available.
Hi @meleshkevich,
If ACES was to keep only the piece-wise EOTF this should not prevent OCIO or implementations to define both or only the pure power variant. OCIO 2 makes that quite a lot easier actually!
Hi! Recently I was trying to add pure gamma 2.4 there for Unreal Engine. I spent several hours with no luck. Was only able to do it modifying legacy “nuke default” config.
I’m absolutely sure most artists don’t even know that config file can be opened in notepad. Editing it? No chance most of them are going to try it.
So for now it’s like this:
“ACES exists to make everyone’s live easier. Just learn everything about coding OCIO. But first get lucky to even know from somewhere, that sRGB and Gamma 2.2 are different things.”
The majority of artists are artists, not coders.
Irrespective of whether ACES was to choose to have Gamma 2.2, an implementation still need to support it. I would read and contribute to that issue here: Add pure gamma 2.2 display to ACES configs · Issue #56 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub
