The root problem for calibration on M1

[mattspace]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

 

[robgendreau]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

Is there an advantage to that?

I had followed a thread about it, but it was mostly about attempts to fix it, https://forums.macrumors.com/thread...n-in-rgb-color-mode-with-mac-mini-m1.2272978/

I wouldn't want to have to get new equipment just because of such a switch unless there were substantial benefits.

And Eizo said this: https://www.eizoglobal.com/support/compatibility/pc/mac/apple-m1/

 

[strawbale]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

Is there an advantage to that?

I had followed a thread about it, but it was mostly about attempts to fix it, https://forums.macrumors.com/thread...n-in-rgb-color-mode-with-mac-mini-m1.2272978/

Thanks for that link

I wouldn't want to have to get new equipment just because of such a switch unless there were substantial benefits.

And Eizo said this: https://www.eizoglobal.com/support/compatibility/pc/mac/apple-m1/

 

[Tom_N]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

Neither the Eizo link, nor the X-Rite link, support that assertion. The X-Rite link doesn't speak to the issue of YUV vs. RGB.

The Eizo link speaks of a workaround involving turning OFF YUV support in the Color Profile on some Eizo monitors … that is, to say, making it appear that the monitor does NOT support YUV (HDTV-style) encoding, so that the computer will select RGB (monitor-style) encoding. If the computer could not use RGB encoding, this would not work.

I think the issue is that if the Mac thinks that the connected display supports YUV, it will select YUV, even though it could have selected RGB. This has been a known problem on Intel-based Macs, where certain HDMI monitors are treated as if they were HDTVs.

Just about every HDTV and UHDTV on the planet wants to see YUV. Only a few TVs have DVI or DisplayPort links on which they might expect to encounter RGB.

It is news that some Macs now will prefer YUV on DIsplayPort links (if the monitor is one that is advertising that it is YUV-capable), and that this happens only on M1-based Macs. That's the takeaway I'm getting from Eizo's report – that the M1-based Macs are capable of using RGB encoding, but when presented when a DisplayPort monitor that can handle YUV encoding, will prefer YUV (as if the monior was a DIsplayPort-connected TV.)

 

[strawbale]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

Neither the Eizo link, nor the X-Rite link, support that assertion. The X-Rite link doesn't speak to the issue of YUV vs. RGB.

The Eizo link speaks of a workaround involving turning OFF YUV support in the Color Profile on some Eizo monitors … that is, to say, making it appear that the monitor does NOT support YUV (HDTV-style) encoding, so that the computer will select RGB (monitor-style) encoding. If the computer could not use RGB encoding, this would not work.

I think the issue is that if the Mac thinks that the connected display supports YUV, it will select YUV, even though it could have selected RGB. This has been a known problem on Intel-based Macs, where certain HDMI monitors are treated as if they were HDTVs.

Just about every HDTV and UHDTV on the planet wants to see YUV. Only a few TVs have DVI or DisplayPort links on which they might expect to encounter RGB.

It is news that some Macs now will prefer YUV on DIsplayPort links (if the monitor is one that is advertising that it is YUV-capable), and that this happens only on M1-based Macs. That's the takeaway I'm getting from Eizo's report – that the M1-based Macs are capable of using RGB encoding, but when presented when a DisplayPort monitor that can handle YUV encoding, will prefer YUV (as if the monior was a DIsplayPort-connected TV.)

... and as a result seem to make colour calibration impossible, with the current way software does that, no? Or is that for another reason?

 

[Tom_N]

Using YUV when a monitor expects RGB would definitely be an issue for color calibration.

The article referenced in the OP claims that there is a "fundamental issue" with M1-based Macs that keeps them from generating RGB encoded video. That's a pretty serious claim, one that people skimming that blog might interpret to refer to the hardware.

It does not appear to be consistent with the notes at the referenced Eizo site – notes that speak of workarounds on the monitor side, and of the issue possibly being fixed in newer point releases of Big Sur.

 

[JimLong]

I recently got an M1 Mini. I alredy had a Spyder X Pro. I downloaded the lastest software and calibrated both of my monitors (a Dell U2410 and a TCL Roku TV). The calibration went very quick and with no problems. I checked my profiles with Color Think Pro and the Dell was very close to Adobe RGB while the TCL was very close to sRGB. My prints were very close to the soft-proof image on the Dell monitor.

 

[strawbale]

Using YUV when a monitor expects RGB would definitely be an issue for color calibration.

The article referenced in the OP claims that there is a "fundamental issue" with M1-based Macs that keeps them from generating RGB encoded video. That's a pretty serious claim, one that people skimming that blog might interpret to refer to the hardware.

It does not appear to be consistent with the notes at the referenced Eizo site – notes that speak of workarounds on the monitor side,

With some of their monitors, the more expensive CG-series

and of the issue possibly being fixed in newer point releases of Big Sur.

 

[strawbale]

I recently got an M1 Mini. I alredy had a Spyder X Pro. I downloaded the lastest software and calibrated both of my monitors (a Dell U2410 and a TCL Roku TV). The calibration went very quick and with no problems. I checked my profiles with Color Think Pro and the Dell was very close to Adobe RGB while the TCL was very close to sRGB. My prints were very close to the soft-proof image on the Dell monitor.

Spyder X (and Spyder 5) are the only tools that seem to work (with their software).

Display manufacturers' own calibration s/w seem to work differntly (see: https://www.dpreview.com/forums/post/64836212) and maybe therefore not yet with M1?

 

[dmiller62]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

This quote from Image Science is completely incorrect.

From the MacOS side of things, from a development and calibration standpoint, there's nothing any different about how either the built-in display on the 13" M1 laptops work; or how external displays attached to either the laptops (one only allowed) or the mini (2 allowed) work.

Calibration is done by measuring uncalibrated RGB patches on the screen, with all system level calibration and color management disabled, to measure the "raw", uncalibrated, "native" response of the display (affected only by "hardware" controls in the display - the front panel controls for an external, or the brightness adjustment and other System Preferences internals, for a 13" M1 laptop display).

Once those patches are measured, calibration software calculates calibration look-up tables, aka LUTs, that are a set of 3 curves, one per RGB color channel. The upper right endpoints of these LUTs provide the color temperature adjustment for the display ("native", with no adjustment, would be 255's for each channel. Adjustment to color temperature will be provided by one or two of the endpoints being pulled downward. Adjustment to brightness can be provided by moving all 3 endpoints down by the same amount, in addition to the color adjustment). Adjustments to gamma, so that the display being calibrated exactly matches the target gamma for the calibration, is provided by the shape of the curves in all 3 channels.)

The calibration LUTs are stored in the vcgt tag in the display profile that's created, and MacOS automatically uploads these into the video card. The calibration therefore affects all color on that display, with the display profile assigned to it (as seen in System Preferences:Colorisplays).

There is nothing different about how this works on M1 Macs, vs. Intel Macs.

 

[strawbale]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

This quote from Image Science is completely incorrect.

From the MacOS side of things, from a development and calibration standpoint, there's nothing any different about how either the built-in display on the 13" M1 laptops work; or how external displays attached to either the laptops (one only allowed) or the mini (2 allowed) work.

Calibration is done by measuring uncalibrated RGB patches on the screen, with all system level calibration and color management disabled, to measure the "raw", uncalibrated, "native" response of the display (affected only by "hardware" controls in the display - the front panel controls for an external, or the brightness adjustment and other System Preferences internals, for a 13" M1 laptop display).

Once those patches are measured, calibration software calculates calibration look-up tables, aka LUTs, that are a set of 3 curves, one per RGB color channel. The upper right endpoints of these LUTs provide the color temperature adjustment for the display ("native", with no adjustment, would be 255's for each channel. Adjustment to color temperature will be provided by one or two of the endpoints being pulled downward. Adjustment to brightness can be provided by moving all 3 endpoints down by the same amount, in addition to the color adjustment). Adjustments to gamma, so that the display being calibrated exactly matches the target gamma for the calibration, is provided by the shape of the curves in all 3 channels.)

The calibration LUTs are stored in the vcgt tag in the display profile that's created, and MacOS automatically uploads these into the video card. The calibration therefore affects all color on that display, with the display profile assigned to it (as seen in System Preferences:Colorisplays).

There is nothing different about how this works on M1 Macs, vs. Intel Macs.

Thank you for your detailed response.

How would you explain that (some or all?) display manufacturers' own calibration software doesn't seem to work with M1?

What about (most or all?) displays connected to a M1 working in YUV in stead of RGB, does that affect calibration (being possible or not)?

 

[dmiller62]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

Neither the Eizo link, nor the X-Rite link, support that assertion. The X-Rite link doesn't speak to the issue of YUV vs. RGB.

The Eizo link speaks of a workaround involving turning OFF YUV support in the Color Profile on some Eizo monitors … that is, to say, making it appear that the monitor does NOT support YUV (HDTV-style) encoding, so that the computer will select RGB (monitor-style) encoding. If the computer could not use RGB encoding, this would not work.

I think the issue is that if the Mac thinks that the connected display supports YUV, it will select YUV, even though it could have selected RGB. This has been a known problem on Intel-based Macs, where certain HDMI monitors are treated as if they were HDTVs.

Just about every HDTV and UHDTV on the planet wants to see YUV. Only a few TVs have DVI or DisplayPort links on which they might expect to encounter RGB.

It is news that some Macs now will prefer YUV on DIsplayPort links (if the monitor is one that is advertising that it is YUV-capable), and that this happens only on M1-based Macs. That's the takeaway I'm getting from Eizo's report – that the M1-based Macs are capable of using RGB encoding, but when presented when a DisplayPort monitor that can handle YUV encoding, will prefer YUV (as if the monior was a DIsplayPort-connected TV.)

... and as a result seem to make colour calibration impossible, with the current way software does that, no? Or is that for another reason?

From the MacOS side of things: the displays are RGB and behave as such. No difference on M1 vs. Intel.

Software that's running on MacOS (whether it's running under Intel Rosetta2 translation, or natively) and which is used to calibrate the display through ICC display profiles, doesn't need to do anything different when running on an M1, vs an Intel, system.

As far as the manufacturer-specific software that's available for some displays: perhaps that's not the case. The "other" way of calibrating displays is to linearize the calibration LUTs in the video card (by using an ICC display profile that has "straight line" ramps from 0 to 255 in its vcgt tag) and by measuring and then uploading manufacturer-specific calibration LUTs directly into the display, where they're stored internally. In that manufacturer-specific workflow, ICC display profiles and the video card on the host Mac (whether it's Intel or M1) are bypassed. Different display manufacturers have their own software, which typically supports display calibration sensors from assorted manufacturers, like Datacolor and XRite, for physically taking measurements, but everything that happens after that is their own internal process.

 

[strawbale]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

Neither the Eizo link, nor the X-Rite link, support that assertion. The X-Rite link doesn't speak to the issue of YUV vs. RGB.

The Eizo link speaks of a workaround involving turning OFF YUV support in the Color Profile on some Eizo monitors … that is, to say, making it appear that the monitor does NOT support YUV (HDTV-style) encoding, so that the computer will select RGB (monitor-style) encoding. If the computer could not use RGB encoding, this would not work.

I think the issue is that if the Mac thinks that the connected display supports YUV, it will select YUV, even though it could have selected RGB. This has been a known problem on Intel-based Macs, where certain HDMI monitors are treated as if they were HDTVs.

Just about every HDTV and UHDTV on the planet wants to see YUV. Only a few TVs have DVI or DisplayPort links on which they might expect to encounter RGB.

It is news that some Macs now will prefer YUV on DIsplayPort links (if the monitor is one that is advertising that it is YUV-capable), and that this happens only on M1-based Macs. That's the takeaway I'm getting from Eizo's report – that the M1-based Macs are capable of using RGB encoding, but when presented when a DisplayPort monitor that can handle YUV encoding, will prefer YUV (as if the monior was a DIsplayPort-connected TV.)

... and as a result seem to make colour calibration impossible, with the current way software does that, no? Or is that for another reason?

From the MacOS side of things: the displays are RGB and behave as such. No difference on M1 vs. Intel.

What about Eizo's "The signal from the Mac computer changes to YUV Limited Range, which may cause banding. This occurs when using HDMI on a Mac computer with an Intel chipset, or when using HDMI, USB Type-C, or DisplayPort conversion cable on a Mac computer with an M1 Chip."

and their "The color profile automatically created by macOS may be inconsistent with the connected monitor characteristics (e.g. color gamut, gamma). As with the Color Format issue (1.2), this problem can be circumvented on some ColorEdge monitors by changing the Signal Format Settings as described below." (which only works for some of their CG-displays, it seems)

(https://www.eizoglobal.com/support/compatibility/pc/mac/apple-m1/)

Software that's running on MacOS (whether it's running under Intel Rosetta2 translation, or natively) and which is used to calibrate the display through ICC display profiles, doesn't need to do anything different when running on an M1, vs an Intel, system.

As far as the manufacturer-specific software that's available for some displays: perhaps that's not the case. The "other" way of calibrating displays is to linearize the calibration LUTs in the video card (by using an ICC display profile that has "straight line" ramps from 0 to 255 in its vcgt tag) and by measuring and then uploading manufacturer-specific calibration LUTs directly into the display, where they're stored internally. In that manufacturer-specific workflow, ICC display profiles and the video card on the host Mac (whether it's Intel or M1) are bypassed. Different display manufacturers have their own software, which typically supports display calibration sensors from assorted manufacturers, like Datacolor and XRite, for physically taking measurements, but everything that happens after that is their own internal process.

 

[dmiller62]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

This quote from Image Science is completely incorrect.

From the MacOS side of things, from a development and calibration standpoint, there's nothing any different about how either the built-in display on the 13" M1 laptops work; or how external displays attached to either the laptops (one only allowed) or the mini (2 allowed) work.

Calibration is done by measuring uncalibrated RGB patches on the screen, with all system level calibration and color management disabled, to measure the "raw", uncalibrated, "native" response of the display (affected only by "hardware" controls in the display - the front panel controls for an external, or the brightness adjustment and other System Preferences internals, for a 13" M1 laptop display).

Once those patches are measured, calibration software calculates calibration look-up tables, aka LUTs, that are a set of 3 curves, one per RGB color channel. The upper right endpoints of these LUTs provide the color temperature adjustment for the display ("native", with no adjustment, would be 255's for each channel. Adjustment to color temperature will be provided by one or two of the endpoints being pulled downward. Adjustment to brightness can be provided by moving all 3 endpoints down by the same amount, in addition to the color adjustment). Adjustments to gamma, so that the display being calibrated exactly matches the target gamma for the calibration, is provided by the shape of the curves in all 3 channels.)

The calibration LUTs are stored in the vcgt tag in the display profile that's created, and MacOS automatically uploads these into the video card. The calibration therefore affects all color on that display, with the display profile assigned to it (as seen in System Preferences:Colorisplays).

There is nothing different about how this works on M1 Macs, vs. Intel Macs.

Thank you for your detailed response.

How would you explain that (some or all?) display manufacturers' own calibration software doesn't seem to work with M1?

What about (most or all?) displays connected to a M1 working in YUV in stead of RGB, does that affect calibration (being possible or not)?

I have no way of knowing the details. I can only speculate that it's a question of how their software is written, and that non-compatible software may need to be updated, if it's specifically tailored to work with these displays in more specialized ways.

 

[strawbale]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

YUV is a video oriented colour format, and pretty much no colour management systems or tools are built around YUV, or work with YUV.

This means you currently cannot calibrate monitors attached to M1 machines without potentially introducing issues like banding. And in fact, most of the calibration systems don't even run on the M1 systems yet.

This quote from Image Science is completely incorrect.

From the MacOS side of things, from a development and calibration standpoint, there's nothing any different about how either the built-in display on the 13" M1 laptops work; or how external displays attached to either the laptops (one only allowed) or the mini (2 allowed) work.

Calibration is done by measuring uncalibrated RGB patches on the screen, with all system level calibration and color management disabled, to measure the "raw", uncalibrated, "native" response of the display (affected only by "hardware" controls in the display - the front panel controls for an external, or the brightness adjustment and other System Preferences internals, for a 13" M1 laptop display).

Once those patches are measured, calibration software calculates calibration look-up tables, aka LUTs, that are a set of 3 curves, one per RGB color channel. The upper right endpoints of these LUTs provide the color temperature adjustment for the display ("native", with no adjustment, would be 255's for each channel. Adjustment to color temperature will be provided by one or two of the endpoints being pulled downward. Adjustment to brightness can be provided by moving all 3 endpoints down by the same amount, in addition to the color adjustment). Adjustments to gamma, so that the display being calibrated exactly matches the target gamma for the calibration, is provided by the shape of the curves in all 3 channels.)

The calibration LUTs are stored in the vcgt tag in the display profile that's created, and MacOS automatically uploads these into the video card. The calibration therefore affects all color on that display, with the display profile assigned to it (as seen in System Preferences:Colorisplays).

There is nothing different about how this works on M1 Macs, vs. Intel Macs.

Thank you for your detailed response.

How would you explain that (some or all?) display manufacturers' own calibration software doesn't seem to work with M1?

What about (most or all?) displays connected to a M1 working in YUV in stead of RGB, does that affect calibration (being possible or not)?

I have no way of knowing the details. I can only speculate that it's a question of how their software is written, and that non-compatible software may need to be updated, if it's specifically tailored to work with these displays in more specialized ways.

But it seems that their s/w not working and the YUV - RGB issue are two different issues, no? (see my reaction a few posts up)

 

[dmiller62]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

Neither the Eizo link, nor the X-Rite link, support that assertion. The X-Rite link doesn't speak to the issue of YUV vs. RGB.

The Eizo link speaks of a workaround involving turning OFF YUV support in the Color Profile on some Eizo monitors … that is, to say, making it appear that the monitor does NOT support YUV (HDTV-style) encoding, so that the computer will select RGB (monitor-style) encoding. If the computer could not use RGB encoding, this would not work.

I think the issue is that if the Mac thinks that the connected display supports YUV, it will select YUV, even though it could have selected RGB. This has been a known problem on Intel-based Macs, where certain HDMI monitors are treated as if they were HDTVs.

Just about every HDTV and UHDTV on the planet wants to see YUV. Only a few TVs have DVI or DisplayPort links on which they might expect to encounter RGB.

It is news that some Macs now will prefer YUV on DIsplayPort links (if the monitor is one that is advertising that it is YUV-capable), and that this happens only on M1-based Macs. That's the takeaway I'm getting from Eizo's report – that the M1-based Macs are capable of using RGB encoding, but when presented when a DisplayPort monitor that can handle YUV encoding, will prefer YUV (as if the monior was a DIsplayPort-connected TV.)

... and as a result seem to make colour calibration impossible, with the current way software does that, no? Or is that for another reason?

From the MacOS side of things: the displays are RGB and behave as such. No difference on M1 vs. Intel.

What about Eizo's "The signal from the Mac computer changes to YUV Limited Range, which may cause banding. This occurs when using HDMI on a Mac computer with an Intel chipset, or when using HDMI, USB Type-C, or DisplayPort conversion cable on a Mac computer with an M1 Chip." (https://www.eizoglobal.com/support/compatibility/pc/mac/apple-m1/)

This is interesting (thanks for the link - I hadn't seen this before). What they seem to be talking about is that on certain Eizo displays, based on the color format setting in the display itself, connecting to an M1 may behave differently by default, than if they're connected to an Intel Mac. Their suggestion is to prevent this from happening by changing what's effectively a "front panel" setting in the display. If that's the case, their suggestion would potentially benefit all display calibration software being used with the display, as well as their own.

Essentially, this comes down to the concept of what the "raw, uncalibrated" display behaves like. That concept is based on the exact behavior of the display based on all of the obvious, and also non-obvious, front panel settings of the display (and even less obvious things at an even lower level, that may exist in these settings, such as the color format being used over the digital linkage and the actual hardware connection).

It doesn't mean you can't calibrate the display (at least, not with more general products like Datacolor and XRite sensors and software); but it "could" mean that - since the way the display behaves when connected to an M1 vs and Intel is "different" - you need a fresh calibration.

Let's take an example. Say you have display X connected externally to an Intel laptop. Then you upgrade or switch to an M1 laptop, and you migrate over your user account from the older Intel laptop, complete with the display profiles you created on it.

Now you've got your display X connected to the M1. If anything's different, even in subtle ways, about how display X behaves via the connection and "front panel" settings, that older display profile won't look right. Recalibrating the display on the M1 should fix that.

 

[dmiller62]

But it seems that their s/w not working and the YUV - RGB issue are two different issues, no? (see my reaction a few posts up)

There could be any number of issues that could require updates for their software to be compatible. What "framework" it's written with; what lower level device drivers it uses, for different sensors; how it communicates digitally with the display hardware itself, directly, over either the digital connection cable or over USB "on the side" instead. They're going to be "talking" directly, and in a specialized way, to their display via their software.

 

[strawbale]

From Image Science :

The problem is that these machines can currently only output YUV (AKA YPbPr) colour, rather than the type of colour pretty much every other computer on the planet outputs, i.e. RGB.

Neither the Eizo link, nor the X-Rite link, support that assertion. The X-Rite link doesn't speak to the issue of YUV vs. RGB.

The Eizo link speaks of a workaround involving turning OFF YUV support in the Color Profile on some Eizo monitors … that is, to say, making it appear that the monitor does NOT support YUV (HDTV-style) encoding, so that the computer will select RGB (monitor-style) encoding. If the computer could not use RGB encoding, this would not work.

I think the issue is that if the Mac thinks that the connected display supports YUV, it will select YUV, even though it could have selected RGB. This has been a known problem on Intel-based Macs, where certain HDMI monitors are treated as if they were HDTVs.

Just about every HDTV and UHDTV on the planet wants to see YUV. Only a few TVs have DVI or DisplayPort links on which they might expect to encounter RGB.

It is news that some Macs now will prefer YUV on DIsplayPort links (if the monitor is one that is advertising that it is YUV-capable), and that this happens only on M1-based Macs. That's the takeaway I'm getting from Eizo's report – that the M1-based Macs are capable of using RGB encoding, but when presented when a DisplayPort monitor that can handle YUV encoding, will prefer YUV (as if the monior was a DIsplayPort-connected TV.)

... and as a result seem to make colour calibration impossible, with the current way software does that, no? Or is that for another reason?

From the MacOS side of things: the displays are RGB and behave as such. No difference on M1 vs. Intel.

What about Eizo's "The signal from the Mac computer changes to YUV Limited Range, which may cause banding. This occurs when using HDMI on a Mac computer with an Intel chipset, or when using HDMI, USB Type-C, or DisplayPort conversion cable on a Mac computer with an M1 Chip." (https://www.eizoglobal.com/support/compatibility/pc/mac/apple-m1/)

This is interesting (thanks for the link - I hadn't seen this before). What they seem to be talking about is that on certain Eizo displays, based on the color format setting in the display itself, connecting to an M1 may behave differently by default, than if they're connected to an Intel Mac. Their suggestion is to prevent this from happening by changing what's effectively a "front panel" setting in the display. If that's the case, their suggestion would potentially benefit all display calibration software being used with the display, as well as their own.

But only for displays that allow for that 'Eizo' solution (i.e. disabling YUV).

What about all the others, see e.g.: https://forums.macrumors.com/thread...n-in-rgb-color-mode-with-mac-mini-m1.2272978/

Essentially, this comes down to the concept of what the "raw, uncalibrated" display behaves like. That concept is based on the exact behavior of the display based on all of the obvious, and also non-obvious, front panel settings of the display (and even less obvious things at an even lower level, that may exist in these settings, such as the color format being used over the digital linkage and the actual hardware connection).

It doesn't mean you can't calibrate the display (at least, not with more general products like Datacolor and XRite sensors and software); but it "could" mean that - since the way the display behaves when connected to an M1 vs and Intel is "different" - you need a fresh calibration.

Let's take an example. Say you have display X connected externally to an Intel laptop. Then you upgrade or switch to an M1 laptop, and you migrate over your user account from the older Intel laptop, complete with the display profiles you created on it.

Now you've got your display X connected to the M1. If anything's different, even in subtle ways, about how display X behaves via the connection and "front panel" settings, that older display profile won't look right. Recalibrating the display on the M1 should fix that.

 

[mattspace]

dmiller62 wrote

Essentially, this comes down to the concept of what the "raw, uncalibrated" display behaves like. That concept is based on the exact behavior of the display based on all of the obvious, and also non-obvious, front panel settings of the display (and even less obvious things at an even lower level, that may exist in these settings, such as the color format being used over the digital linkage and the actual hardware connection).

Hi David, great to see your input on the topic.

I'm happy to be proven wrong, but up until Big Sur / M1, if macOS decided your display was a YUV display, even if it was capable of RGB, it was often more or less impossible to get it to output colour in RGB-format - there's no manual setting in macOS to force output in RGB.

Also, as far as I can tell, some monitors don't let you override the YUV reduced range, unless the source supports it - eg plug the monitor into an XBox and you can select 16-255 or 0-255, plug it into a Mac and the option is greyed out.

So, the burning question is whether you're running your calibrator on a display that's inherently showing less than its full colour range (eg 16-255, rather than 0-255).

This is one of the reasons people came up with EDID override scripts to redefine individual monitors as being RGB-only. Now, these scripts need to be rewritten, because the M1's GPU doesn't use the same variable naming scheme as those in intel Macs. There's also a question I've seen asked of whether you can even apply an EDID override given the locked nature of Big Sur's system volume.

That is obviously a different question to whether display manufacturers have written the Big Sur compatible hardware drivers to let calibrator software write to the LUT hardware in the displays.

I will be very interested to see if someone can make a turnkey guide to getting full in display hardware calibrated 10bit output on an M1 system.

 

[JimLong]

Thanks, I wasnt aware of that. Guess I got lucky.