ODTs and the Judd-Vos correction

judd-vos
calibration
odt
Tags: #<Tag:0x00007f3c5da26bb0> #<Tag:0x00007f3c5da26a20> #<Tag:0x00007f3c5da26778>

(Jim Houston) #1

From Zach Lewis:

"I’m not sure if this is just Sony, but I do know our BVM-X300s utilize non-CIE-1931 colorimetry (i.e., Judd-Vos); and are thus calibrated to an offset white-point. The net result is a (theoretically) closer perceptual match to CRT displays. I’ve been wondering – in the context of ACES in general – how to express and account for this elsewhere in the pipeline (I presume this wouldn’t affect much outside dictating how any non-mastering / preview X300s in the pipeline need to be set and calibrated). But I have to imagine this would cause a discrepancy between the expected output values listed in the tables here, and actual measurements from such a duly-calibrated display, no? And, at the same time, if the display itself is converting from CIE-1931, and then calibrated to perceptually compensate for the difference, the academy-provided ODTs are ideal as-is. If I’m correct in my presumptions – that the standard ODTs are appropriate for these devices, but / and a correctly calibrated device elicits values different from those listed – how should this be addressed?”

I’ll take a stab at this part…

ODTs can be thought of as outputting the ideal colors for a display, but it assumes you also have an ideally calibrated device that receives the ideal color space signal for the current settings. There is another transform sometimes needed to calibrate the physical devices, and in the ACES system, it is called the ODCT - Output Device Calibration Transform (you can never have enough acronyms sic.) If a device has internal controls for calibration, then the device could be setup properly and no code value would be harmed in transmitting the ideal color to the display. If the device has no controls at all, then you would have to apply an ODCT to change the code values into exactly what that device needed to show the correct color. Then you would potentially have a colorimetric match. The Judd-Vos correction fits in an uneasy place in the model – because it is a perceptual transform. Some ODTs have perceptual adjustments. Because of the narrowness of OLEDs compared to CRT, the correction is an attempt to minimize observer metamerism (and effectively to give a better white). This may have to be tuned individually for different devices as the same offset might not be the best choice for different spectrum coming from a display. It is probably best to treat the Judd-Vos correction as more of a unique device calibration rather than worry about needing a whole new ODT for it. It follows the same principle in many post houses that making the signal be correct is the important thing, and minor perceptual differences should not be baked into the signal (because then some devices would be getting a correction they don’t need). The real test is whether displays being compared are showing roughly the same result. A consideration must then also be, if I am setting up OLEDs with a Judd-Vos correction, does an LCD need the same or is it already broad enough in the three components that it doesn’t need it. I do know that there is still work going on within the industry at looking at the Judd-Vos correction as it applies to the Sony X300 – and at the same time, the X300 is largely the reference monitor of choice. I think you are correct that you may not get colorimetric readings from a JuddVos corrected display, so it helps to know what type of calibration was used, but it may be perceptually closer to the requested color – so a colorist’s judgements are more likely to be correct with the JuddVos correction.


(Zach Lewis) #2

Thanks, Jim – sage words – I really appreciate your response.

When I noticed that we were calibrating our allegedly-D65 X300s and our definitely D65 non-X300s to different cie1931 xy values, I nearly had a conniption, and for a hot second, I thought some guy named Judd Vos had convinced the powers that be to calibrate all HDR stuff to his creative whitepoint. Fortunately, before I started bleeding from the ears, the engineer pointed me to this straight-forward OLED Color Matching Whitepaper from Sony.

There is another transform sometimes needed to calibrate the physical devices, and in the ACES system, it is called the ODCT - Output Device Calibration Transform

Since you bring ODCTs and acronyms and such, I was hoping I could get some clarification here, with respect to Target Conversion Transforms (TCTs) and Display Encoding Transforms (DETs), which were the subject of our most recent technical bulletin (TB-2016-013, I think?). I’ve never really seen anyone mention them. As I understand it… lets see if I can get this right…

  • Within the ODT:
    • The Target Conversion Transform (TCT) serves to map OCES RGB to R’G’B’ values that fit the output device’s luminance range and gamut
      • I believe these are the C9 forward splines, adjusted per output-device luminance ranges and surround; followed by gamut remapping / clamping and possible chromatic adaptation transforms
    • Next, the DET converts these remapped R’G’B’ code values to device-specific signal encoding (ODCES – Output Display Color Encoding Space)
      • i.e., Dolby PQ / ICtCp; or Gamma 2.6 / X’Y’Z’;
  • After the ODT:
    • The ODCT describes a per-device adjustment made to nudge incoming idealized ODCES values into place to compensate for individual differences across units.
      • For instance, a hardware ICC profile generated from probe measurements
      • Or, as discussed (but not recommended), a matrix transform to perform (or compensate for?) a Judd-vos transformation.

Am I understanding TCTs / DETs / ODCTs correctly?

Would this then mean that tweaking a contrast knob on the display itself constitutes an ODCT, of sorts? Or the enabling / disabling Judd-vos corrections, or calibrating to one mode or the other?

Similarly, if a grade were produced on an X300 in HLG at some gamma targeting some peak luminance, it should not only be mathematically possible to convert to a visually identical PQ signal, but it should be possible to communicate / derive the exact settings for the appropriate X300 PQ mode. But that device mode switch… it’s not so much a transform as it is metadata, or implied metadata that dictates an adjustment.

LUTs get passed across facilities without appropriate contexts attached all the time; and communication, already difficult, is about to get much… difficult-er. Meanwhile, the most commonly used means to communicate device settings seems to be via photos of menu settings.

I think this is what I was trying to get at with my original question, without quite knowing how to ask it – how, exactly, could / would / should ACES communicate information about display-specific settings? And to what end? It doesn’t quite feel right to include device settings in the “ODCT” category – and, yet, ACES is well-positioned to serve as both a conduit for vendor-specific support, as well as a means to communicate and validate supported workflows.

I guess where this long-assed post is taking me is towards either vendor-specific CLF extensions building upon the Info/CalibrationInfo ProcessList element, or a suite of vendor / device specific documents… white papers for calibrating a given device for an ACES (or vendor?) ODT.

Similarly / alternatively, ACESclip should / could be able to communicate sufficient information about the mastering display to validate like models against. Or, at the very least, provide enough information so we can begin to pick apart where everything started to go wrong :slight_smile:

So… ah… yeah, sorry, this kind of veered into the abstract end of things; and I’m sure vendor participation to such an end would be tricky, if viable. But I’m sure of three things:

  • We do need a way to formally and unambiguously communicate and validate device settings, since we live in a world where multiple ODTs could apply to the same device, and many devices could accept the same ODT. Whether that’s within the scope of ACES, or belongs better in the BxF or IMF domains is worth further discussion, I think.
  • In the end-user documentation, we should at least note the possibility of differences from expected measurements listed; and I know there isn’t a de facto Judd Vos implementation that vendors abide by, so we wouldn’t be able to list vendor-agnostic expected Judd-Vos-offset values… In any case, probably worth at least a note in an appendix or something.
  • I’m still not sure if display-device settings warrant their own acronym and real estate on the ol’ block diagram, but this kind of information isn’t too far removed from SMPTE ST-2086 mastering display metadata that HDR deliverables already require, in terms of attaching a-priori knowledge of device characteristics to the pipeline, which, in turn, dictates color volume upper bounds and constraints when reproducing on other devices.

Thanks friends.


(Tobias Schaarschmidt) #3

I agree with Jim. The perceptual White Point modification transform is something that belongs completely to display calibration - or what Jim called “ODCT” - in any case after the ODT. BTW, I know you need an acronym for your flowcharts :wink: but i think some people might think that ODCT is something which is exclusively ACES workflow related, but it is not. This white point modification is not something new and there is nothing different to do whether you work in a traditional workflow or ACES. And it is true: when you want to closely match 2 Displays of different technologies to one another you might need different white point modification transforms for the different displays and you will have to obtain these modifications mostly by eyeballing the monitor you want to match to the reference monitor (X300 for example or a Barco DCI Projector). So this white point modification should under no circumstances be part of the ODT! i try to imagine the confusion that would start. You would need one ODT with the modification for Viewing and one ODT without for rendering - that is just a recipe for confusion, maybe even disaster. You would also need these modified versions of ODTs for every target color space…

Some Displays even implement the white point modification in their onboard CMS (like the FSI CM250 OLED). I implement this white point modification in my probe matching preset (in the step when i take a spectral measurement with a spectrofotometer to calibrate my Colorimeter to it) - so my CR-100 colorimeter shows the correct expected standard chromaticity values while the OLED display is calibrated to the perceptual modified white point - which is in my opinion the most elegant way to deal with that issue.