Middle Gray confusion

[soenke.heuer (Sönke Heuer)]

Hello everyone,
We shot some HDRIs with a colorchecker on the floor and normalized the “50%” patch to 0.18 in Nuke.
0.18 because the ACES white papers are saying that middle gray is 0.18 and we are used to it from the old linear/sRGB workflow as well.
If we want to match that patch for example in Nuke in an intuitive way, then I would expect to create a constant with R=G=B=0.5 and convert it via OCIO colorspace from “Texture - sRGB” to “ACEScg”. The result is a value of 0.214. Which makes sense somehow, but here is the point where my confusion begins.

Is this the value we actually WANT to get and if not, how do I archive the right value (besides typing in “0.18”)?

There are a lot more questions around this topic, but first off I would like to understand this “simple” context.

Regards,
Sönke

[flord (Francois Lord)]

Hi Sönke,
The gray patches on the colorchecker are not perfectly neutral. The simplest way to get the right color in Nuke is by using this gizmo. Set it to the right colorspace (ACEScg in your case)
Then apply a grade to your hdr image, activate the color picker for the whitepoint parameter and pick the brightest patch on your image while viewing your image. Then activate the color picker for the gain and pick the brightest patch on the colorchecker gizmo. Notice how the gray patches vary slightly in temperature on the gizmo image.

This will set the exposure and the white-balance at the same time. If you don’t want to white balance, you need to set both values (whitepoint and gain) to a the same value for red, green and blue.

If you want to push the exercise a little further, you can use the mmColorTarget gizmo. But it’s tricky to install as you need an additional python package. It warps the colors to try to match the colorchecker better.

Cheers,
F

[flord (Francois Lord)]

And to answer your question, no… 0.18 is not the value you want. And 50% is not a good starting point.
What we call the 50% perceptually gray patch is really just an approximation. And it practice it’s not perfectly 18% reflective either.
The OpenEXR spec says that an object correctly exposed that reflects 90% diffuse light should have a value of 0.9. So the best way to set the exposure for an HDR image (or any image for that matter) is to set the values of the color checker chart to their real reflectance values.

Of course, this works if the color checker is lit in a way that represents the entire image.

[Thomas_Mansencal]

@soenke.heuer: In addition to what @flord said, here is some reading on the many perceptually middle grays: https://en.wikipedia.org/wiki/Middle_gray

[soenke.heuer (Sönke Heuer)]

Thank you for your answers.
I just realized that my question was a bit misleading, but since your answer gave me new questions - lets clarify those first.
So far we used the colorchecker values from the AMPAS github reference images. I just compared those values with the values the gizmo is giving me. Unfortunately they are not matching:

The chart in the background is the one from AMPAS, the inner squares are from the Gizmo. Both in ACES2065-1 and viewed through the Rec709 ODT.

@flord

And to answer your question, no… 0.18 is not the value you want. And 50% is not a good starting point. What we call the 50% perceptually gray patch is really just an approximation. And it practice it’s not perfectly 18% reflective either.

I don’t understand that point. I thought if we are working with linear data, then it should not make any difference at which brightness value we are “leveling”. Because, well, it is linear… am I missing something?

@Thomas_Mansencal

In addition to what @flord said, here is some reading on the many perceptually middle grays: Middle gray - Wikipedia

This page is always open in my browser!

Ok, let me try to ask my basic question in a different way:
I want bring in a perfectly neutral gray patch at 50% brightness into my ACES scene. And I am searching for the right transform to do that in an intuitive way. So I can reproduce the transform in Nuke, Maya etc.

[Thomas_Mansencal]

@soenke.heuer: I have made the following comparison between the AMPAS Golden and the Gizmo (well an output image to minimise the paste length), it matches quite well:

The differences are likely to be caused by the source data being different for the Colour Rendition Chart, our Gizmo is using data from:

BabelColor. (2012). ColorChecker RGB and spectra. Retrieved from The BabelColor Company - Contact

I don’t know where is the data from the AMPAS coming from but @sdyer will know!

Here is the Nuke paste if you want to reproduce:

set cut_paste_input [stack 0]
version 10.0 v4
Read {
 inputs 0
 file /Users/kelsolaar/Documents/Development/colour-science/colour-nuke/colour_nuke/resources/images/ColorChecker2005/ACES2065-1_ColorChecker2005.exr
 format "3583 2525 0 0 3583 2525 1 "
 origset true
 name Read2
 selected true
 xpos 70
 ypos 83
}
set N1f78c0 [stack 0]
Transform {
 scale 1.04
 center {1791.5 1262.5}
 name Transform1
 selected true
 xpos 70
 ypos 159
}
set N2ae7deb0 [stack 0]
push $N1f78c0
Keyer {
 operation "luminance key"
 range {0.025 0.025 1 1}
 name Keyer1
 selected true
 xpos 180
 ypos 107
}
FilterErode {
 size 65
 name FilterErode1
 selected true
 xpos 180
 ypos 227
}
Read {
 inputs 0
 file /Users/kelsolaar/Downloads/syntheticChart.01.exr
 format "2048 1080 0 0 2048 1080 1 2K_DCP"
 origset true
 name Read1
 selected true
 xpos -150
 ypos -109
}
Crop {
 box {1987 20.89999962 2032.48999 981}
 reformat true
 crop false
 name Crop1
 selected true
 xpos -150
 ypos -33
}
set N1d630550 [stack 0]
Crop {
 box {-0.5499992388 -0.5999999046 44.54999924 243.1000061}
 reformat true
 crop false
 name Crop5
 selected true
 xpos -40
 ypos 15
}
Reformat {
 format "490 90 0 0 490 90 1 490_90"
 turn true
 name Reformat4
 selected true
 xpos -40
 ypos 35
}
push $N1d630550
Crop {
 box {-0.5499992375 239.1999969 44.54999924 482.2000122}
 reformat true
 crop false
 name Crop4
 selected true
 xpos -150
 ypos 15
}
Reformat {
 format "490 90 0 0 490 90 1 490_90"
 turn true
 name Reformat3
 selected true
 xpos -150
 ypos 35
}
push $N1d630550
Crop {
 box {0 477.7999878 45.09999847 720.0999756}
 reformat true
 crop false
 name Crop3
 selected true
 xpos -260
 ypos 15
}
Reformat {
 format "490 90 0 0 490 90 1 490_90"
 turn true
 name Reformat2
 selected true
 xpos -260
 ypos 35
}
push $N1d630550
Crop {
 box {0 716.8800049 45 960}
 reformat true
 crop false
 name Crop2
 selected true
 xpos -370
 ypos 15
}
Reformat {
 format "490 90 0 0 490 90 1 490_90"
 turn true
 name Reformat1
 selected true
 xpos -370
 ypos 35
}
ContactSheet {
 inputs 4
 width 490
 height 360
 rows 4
 columns 1
 roworder TopBottom
 name ContactSheet1
 selected true
 xpos -260
 ypos 135
}
Reformat {
 format "3583 2525 0 0 3583 2525 1 "
 resize distort
 name Reformat5
 selected true
 xpos -260
 ypos 155
}
push $N2ae7deb0
Merge2 {
 inputs 2+1
 name Merge1
 selected true
 xpos -150
 ypos 159
}
Viewer {
 inputs 2
 frame 1
 frame_range 1-100
 name Viewer1
 selected true
 xpos -150
 ypos 255
}

@soenke.heuer

I want bring in a perfectly neutral gray patch at 50% brightness into my ACES scene.

I’m a bit unclear of what you are trying to achieve sorry for not being helpful here.

Cheers,

Thomas

[soenke.heuer (Sönke Heuer)]

Thanks Thomas for your detailed answer.
The comparison you made looks very satisfying for me.
I was wondering why your comparison matches much better than the one I did.
I opened your Nuke script and saw that we are using different parts of the synthetic chart for the comparison.

I was using the colors at the bottom (the red box) and you are using the colors at the right (the blue box), which are obviously different.
But why are they different? I was thinking they are the some, just in a different figure. And if the colors on the right side are the right ones, what are those color at the bottom then?

[sdyer (Scott Dyer)]

@soenke.heuer

But why are they different? I was thinking they are the some, just in a different figure. And if the colors on the right side are the right ones, what are those color at the bottom then?

All colors in this image are synthetically calculated using the ACES Reference Input Capture Device (RICD). The reason the two “ColorChecker” charts are different is because the spectral reflectances used for each are slightly different. While in theory, all “ColorChecker” charts are the same, physical versions are not all spectrally identical to each other or to “standardized” spectral reflectances.

The values along the right are the ACES values defined in SMPTE 2065-1 Annex D, which use the RICD, D60 and the spectral reflectances defined in ISO 17321-1 Tables C.2 and C.3.

The values on the bottom are ACES values calculated using the RICD, D60, and empirical measurements of the spectral reflectances for a ColorCheckerSG chart.

I would recommend using the chips along the right for future comparison as they are traceable to a standard.

[soenke.heuer (Sönke Heuer)]

Thanks for clarification Scott!

Ok, back to the other question:

@flord

And to answer your question, no… 0.18 is not the value you want. And 50% is not a good starting point. What we call the 50% perceptually gray patch is really just an approximation. And it practice it’s not perfectly 18% reflective either. The OpenEXR spec says that an object correctly exposed that reflects 90% diffuse light should have a value of 0.9. So the best way to set the exposure for an HDR image (or any image for that matter) is to set the values of the color checker chart to their real reflectance values.

@soenke.heuer

I don’t understand that point. I thought if we are working with linear data, then it should not make any difference at which brightness value we are “leveling”. Because, well, it is linear… am I missing something?

I still don’t get that one. Could someone help me there?