Some questions regarding hardware calibration and software calibration

[earlybird]

Hi,
 I have read about the basic differences between hardware calibration and software calibration, and I have a few questions.

 But first, some comments:

 1) The ability for hardware calibration to maintain calibration when swapping sources seems like a good feature. I doubt I will ever swap sources, so it's not a big plus for me.

 2) An ability to reference a higher bit-depth color table seems like a compelling reason to prefer a hardware calibration system.

Now, some questions:

 1) How does the hardware determine the color space the source is sending? Is there a protocol that includes a description of the source color space in the signal? In other words, how can a hardware calibration convert incoming signals to the display signal without a clear reference describing the source? If my Windows PC sends the hardware sRGB and my 12-bit video camera sends it something else, how does the hardware know what to change to what?

 2) Why is it said that hardware will have greater bit-depth color definitions than software? Is it universally true? Is there a constraint on what Mac or Windows OS appliance can transmit from a software-based ICC profile? If so, is the constraint in the ICC format, the cable connection protocol, or the operating systems?

 3) I am reading about some vendors providing disappointing support, and customers who have trouble using the calibration software associated with the hardware calibration displays they own. Is there any way to future-proof your hardware calibration system? If a vendor has a wonky software package that may or may not work well with the operating system of your choice, is there any prospect of a third-party solution? Is the software that provides calibration routines for hardware specific and proprietary? If so, it seems fairly likely that a modestly priced hardware calibration display may not be supported long enough to make the extra expense seem like a good value. Do some monitor manufacturers make a greater effort to support the software that partners with their hardware?

 The idea of buying a modestly priced, hardware-calibration-capable display seems appealing. Still, I'm having trouble getting past the complaints I have encountered in the reviews of these monitors. The common complaints I see are regarding the use of the calibration software, which leads me to believe that if things are not great at first, the situation is unlikely to improve.

 I probably have more questions, but have yet to figure out what they are.

 Thank you.
 

 

[digitaldog]

1. if you can set the primaries, with TRC/Gamma and white point, you can set and define the color space. Calibration is putting the device into that defined behavior.
2. For high-bit viewing of image data, you need a video card, display, and OS that all support high bit. All must be in the loop.

[earlybird]

1. if you can set the primaries, with TRC/Gamma and white point, you can set and define the color space. Calibration is putting the device into that defined behavior.

So, I think I can imagine that, with 8 bits for example, the three vertices for Red, Green, and Blue would be recognized as a value containing a 255, and any digital stream would use that same number for the vertex. Then, I guess you are saying that the TRC/Gamma and white point define the light value of the three vertices, and this would describe the span of the colorspace.

Is that what you are explaining? If not, please "explain." :-)

So, I still don't understand how signals coming out of a software OS with a system profile of some sort can be interpreted by the monitor and then automatically converted to a display profile, for example, Adobe RGB.

I was working with digital TV video field/studio monitors (and worked in analog video with daily "bars" calibration way before that) when we transitioned past Rec 709 to using LUTs for cameras such as RED and Arri Alexa. We transitioned from a scenario where SDI rec 709 signals were basically plug-and-play to experimenting with a new to us concept called LUTs. The LUTs were stored in the monitor's hardware but were customized for each camera. In other words, some expected signal was sent to the hardware, and an expected signal was displayed. At least back then, you could not simply plug any camera output into the monitor and expect a LUT to provide consistent display results.

It's not like plugging anything in, and the hardware will take care of it, which is a feature that seems to be described as a benefit of using computer display hardware calibration. Maybe I'm missing the details of how the perceived benefit works.

I was hoping to gain a better understanding of what is going on behind the scenes.

Please elaborate if you think you can help.

2. For high-bit viewing of image data, you need a video card, display, and OS that all support high bit. All must be in the loop.

What are some examples of such hardware? My new Photoshop-centric desktop system will be equipped with a Gigabyte Nvidia GeForce 5070 12GB graphics accelerator featuring DisplayPort 2.1 and HDMI 2.1b outputs.  Did I just miss the opportunity to buy a suitable graphics card?

Does Windows 11 support 10, 12, and 14-bit graphics output?

I suppose I assumed that software calibration may have constraints related to legacy and tradition, and anticipated, rightly or wrongly, that hardware calibration with 14 or 16-bit LUTs would somehow interpolate greater detail in the color range while also extending the dynamic range between the black and white points.

When I work with my ProPhotoRGB 16-bit files in Photoshop, I know I'm not seeing all the bits on my current display, but I'm unsure where the bottleneck lies in the signal path. I always assumed it was in the display hardware.

Explanations will be appreciated.

Thank you.

[digitaldog]

Two different topics: video bit depth and color space.
For a fully high-bit path, all the necessary components have to support high bits. Otherwise, high bit gets converted to a lower bit depth; the result is possible visual banding of the image data when no banding is within that data. So the video card, display, OS, and software have to support all this data.
Windows can support a high-bit-depth video system IF all of the above is supported. So, with the right video card, Photoshop, etc., yes, you can get a full high-bit display path.
When you work with ProPhoto RGB, you do not see the entire gamut! This has nothing to do with bit depth. There are numbers that are not colors. No display can produce those numbers, and in fact, no human can even see them; the numbers fall outside human vision! See: http://digitaldog.net/files/ColorNumbersColorGamut.pdf

[earlybird]

I am familiar with the fact that a color can only be considered a color if it is perceived by the human eye as a color. I understand that not every device value corresponds to a color, and some device values represent the same color.

I also accept the idea that there are far fewer actual colors than there are device values in an 8-bit bit depth.

Thank you.

With that in mind, why would a display vendor equip a hardware calibration implementation with lookup tables that offer 14-bit or 16-bit depths?

These bit depths are not the primary reason I am considering these monitors; it just happens to be the specification offered within my budget's comfort range, and consequently, I am curious to learn how the bit depth is utilized in practical terms.

I am entertaining the idea of purchasing an Asus, which I believe is specified with a 14-bit LUT, or a BenQ that offers a 16-bit LUT. Additionally, I am looking at but not really considering a high end Eizo that specifies a 16-bit LUT.

Is there a point to these bit depths if a Mac or a Windows machine can only supply 10-bit data?

I have assumed there would be some benefit, but I have no idea how it can be implemented.

Thank you.



.

[earlybird]

Here is an example of an article by Eizo that purports to explain why 16-bit hardware LUTs are better:

https://www.eizo.eu/colour-management-and-calibration/all-about-monitor-calibration#:~:text=The%2016%20bit%20look%2Dup,unwanted%20LCD%20tonal%20value%20properties.

The writer implies 16-bit is better, the reader infers 16-bit is better, but the article does not adequately explain the details.

It does not specifically explain why 16-bit is better, although it does a great job of impressing me with the thoroughness of the throughput circuitry in the hardware.


Articles like this leave something for the imagination, and that could potentially lead to misunderstanding and confusion.


For example, here is something I am imagining, but certainly can not endorse as being factual:

8-bit bit depth may have many more device values than there are visible colors to describe, but due to the quantization of digital data, the device values available may not coincide optimally with the position some specific color will occupy. Interpolating the 8-bit data into a 16-bit environment provides much finer granularity and increases the likelihood that some specific device value will align more closely with the position of some specific color.

Did I just make that up? Yes, I did. Is it anywhere near accurate?

I would greatly appreciate it if you could provide me with the facts, correct any misunderstandings I may have, and share some valuable information.

Thank you!

[digitaldog]

The idea that "16 bits" is better than 10/12/14 bits is nonsense. What is key is that the system be more than 8 bits per color. Even Photoshop doesn't support 16-bits in reality (it is 15+1 bits). All that matters is that the entire video system be more than 8 bits per color to provide high-bit data. The display may be 16 or so bits, but the video card may be 10-bit, and that's fine. High bit means more than 8-bits per color. That's what matters.
As to colors and bits: you might have an 8 bit document with 10,000 colors and a 16-bit doc with 1! You might have a document with one visible (real) color document with 100 color values like the sRGB example I provided in my PDF. Don't confuse colors with bits, don't confuse colors with numbers or fractions of numbers. R0/G255/B0 OR R0.2/G255.0/B0.5 in ProPhoto RGB is NOT a color. No matter how you divide up the numbers. It is invisible as defined, it isn't a color. It is a color number.

[earlybird]

With that in mind, why would a display vendor equip a hardware calibration implementation with lookup tables that offer 14-bit or 16-bit depths?

[degrub]

smoother transitions in the representation on the screen.

[digitaldog]

With that in mind, why would a display vendor equip a hardware calibration implementation with lookup tables that offer 14-bit or 16-bit depths?

Marketing hype.

[earlybird]

I found an interesting paper discussing the quantization of color descriptions:

Comparative analysis of the quantization of color spaces on the basis of the CIELAB color-difference formula