IEC 61966-2-1:1999 has not been updated for a long time, and now most monitors support P3 gamut, so where is the next IEC 61966-2-1:1999?
Nowadays so many devices use P3 gamut and have to be able to continue to interface with IEC 61966-2-1:1999, I think this is apple's solution, and under P3 gamut to transmit sRGB gamma.

Should we use DCI-P3 for office and web environment?

Steve, do you have any recommended on this?
I assume you are also reading the forums with a P3 gamut monitor.

There are far too many issues with any such suggestion.
The basic one being that monitor sRGB EOTF is a power law 2.2 gamma.
The compound sRGB gamma is for image encoding.
So Apple's DisplayP3 is just wrong if used for display calibration, if a compound gamma is really used.

And the web is still sRGB based, as is 'the office'.

Steve

So, regardless of P3 or sRGB hardware, the monitor should be calibration to gamma 2.2 instead of sRGB?
Why does this inconsistency occur?

https://lightillusion.com/forums/display-calibration-8/srgb-final-word-791.html

Steve

Maybe an easier way to understand this: color managed apps like the Mac desktop don't care what gamma the screen is calibrated to as long as the same gamma is encoded in the ICC profile TRC tags. They do the math so that the image looks the same on 2.6 a screen as it does on a 2.2 screen.

That assumes the display calibration is ICC managed, and that the tags correctly represent the actual state of the display.
That is unfortunately rarely the case.
And is really not relevant to LUT based calibration, as we are talking about actually calibrating the display, and no relying on ICC aware OS/programs.
(Ignoring the accuracy issues inherent with any ICC approach, of which there are many.)

Steve

I've been thinking about it, and it doesn't make sense.
Without taking icc into account is it any wonder that the mismatch between the image encode's EOTF being sRGB and the display having to be corrected to 2.2 is deliberate?
Shouldn't it be correct to restore the intent of the image?
The context of CRT was the technical limitations of the time, while today's conditions are perfectly capable of allowing displays to match EOTF to sRGB.

In the apple XDR display guide the EOTF for sRGB mode is sRGB and displayP3 is 2.2, obviously apple knows the difference but the image taken with the iphone is displayP3/sRGB EOTF, of course the mac can deal with this issue through icc.

But is there any truth to it?

The concept of an Encoding being different to the displays target for calibration is common.
Rec709 has a different encoding vs. calibration too.
The primary reason is to manage near black issues with capture/encoding, as well as apply a different 'system gamma' to counter viewing conditions, etc.

With sRGB encoding, the assumption was the images would be graphics, so the linear portion near back is to prevent crushing near the black floor/noise level whne the image is displayed.
You do NOT want to add that to the monitor calibration, as that would lift the noise floor.

Steve

If I remember correctly, sRGB, being a scene-referred system like Rec.709, defines EOTF as Lc=OOTF(OETF^-1(V)). If they are the same there is no need to specify a EOTF anymore.

I don't know if you have noticed, the Rec.709 OETF has approx. gamma of 1.96. The equation used to derive 1.96 does not actually mean much since end-to-end (OOTF) gamma 1.2 is derived with reference OETF and reference display characteristics, not vice versa. macOS AVFoundation uses Rec.709 camera OETF without the linear part (pure power law) to linearize the signal.

In my experiments, it only follows the compound ~2.2 gamma when monitor preset is set to presets other than Apple XDR Display or Apple Display (which are presets most people use). This is true both for the sRGB tagged shadertoy canvas and for an sRGB PNG in Preview.app (but surprisingly not in QuickLook which follows piecewise curve).

Really not at all sure what you are suggesting here...
But, EOTF is the conversion of the digital video signal into the visible image as seen on the display.
In reality, it is separate to the camera capture, as different cameras capture in very different ways.
What it is really defining is what the expected image format has to be to be displayed correctly on that display.

Steve

For sRGB, displayP3, or AdobeRGB, their OETF is sRGB, and their EOTF is gamma 2.2.
For REC709, its OETF is REC709, and its EOTF can be any of BT1886, gamma 2.4, or gamma 2.2.
Except for HDR and DCI-P3, there are almost no cases where EOTF = OETF^-1. This is reality.