All color is best-effort

Thanks to my sponsors: John Horowitz, Xavier Groleau, Romain Kelifa, Matt Heise, Lyssieth, Dirkjan Ochtman, David White, Niels Abildgaard, Philipp Hatt, traxys, Zac Harrold, Marie Janssen, Dimitri Merejkowsky, Eugene Bulkin, Kyle Lacy, Morgan Rosenkranz, Kevin Anderson, Tyler Bloom, Xirvik Servers, Alex Krantz and 277 more John Horowitz, Xavier Groleau, Romain Kelifa, Matt Heise, Lyssieth, Dirkjan Ochtman, David White, Niels Abildgaard, Philipp Hatt, traxys, Zac Harrold, Marie Janssen, Dimitri Merejkowsky, Eugene Bulkin, Kyle Lacy, Morgan Rosenkranz, Kevin Anderson, Tyler Bloom, Xirvik Servers, Alex Krantz, Gorazd Brumen, Matěj Volf, Malik Bougacha, Zalán Bálint Lévai, Yann Schwartz, Scott Steele, Alex Rudy, Jan-Stefan Janetzky, Antoine PESTEL-ROPARS, Geoffroy Couprie, Henrik Tudborg, Chris Biscardi, Pete Bevin, pinkhatbeard, Justin Ossevoort, Chris Emery, Stephan Buys, Mark Old, milan, Joshua Roesslein, Zachary Myers, Christopher Valerio, Mark Tomlin, villem, Senyo Simpson, Guy Waldman, Nicholas, Sung Jeon, std__mpa, Arjen Laarhoven, Jean-David Gadina, C J Silverio, Yves, Paul Horn, Jonathan Adams, Ripta Pasay, Enrico Zschemisch, Geoffrey Thomas, Ula, Brandon Piña, Elendol, Colin VanDervoort, psentee, DaVince, Marco Carmosino, Chris, messense, Zachary Thomas, L0r3m1p5um, Chris Thackrey, avborhanian, Horváth-Lázár Péter, Max Bruckner, xales, Ross Williams, Jesse Luehrs, Seth, Max Heaton, Tabitha, Tiziano Santoro, Beth Rennie, Elnath, Alan O'Donnell, budrick, Yuriy Taraday, Reto Trappitsch, James Brown, Paul Marques Mota, jatescher, Mike English, Michael, Integer 32, LLC, Pete LeVasseur, Antoine Rouaze, you got maiL, Walther, Guilherme Neubaner, Ryan, Angelo, Aalekh Patel, Ahmad Alhashemi, Jon Gjengset, Marty Penner, jer, Ronen Cohen, ofrighil, Jake Demarest-Mays, René Ribaud, ZacJW, Justin Smith, Brian L. Troutwine, Mattia Valzelli, Santiago Lema, Marc-Andre Giroux, notryanb, Andy Gocke, Noel, Josiah Bull, Ronen Ulanovsky, AdrianEddy, Sylvie Nightshade, Menno Finlay-Smits, Felix Weis, bbutkovic, Michael Alyn Miller, Björn Marschollek, Paige Ruten, Samit Basu, playest, Corey Alexander, Cole Tobin, WeblWabl, Adam Gutglick, Valentin Mariette, Andrew Henshaw, Jack Duvall, Julian Schmid, John VanEnk, qrpth, genny, zed, alethiophile, Jim, Romet Tagobert, Mario Fleischhacker, Marky Mark, Sarah Berrettini, Olivia Crain, Matthias Zepper, Alexandra Østermark, Scott Sanderson, Urs Metz, Chris Walker, Garret Kelly, Isak Sunde Singh, Neil Blakey-Milner, Zoran Zaric, Kamran Khan, Antoine Boegli, Benjamin Röjder Delnavaz, Mikkel Rasmussen, ShikChen, Anna M, Borys Minaiev, Mason Ginter, Matt Jadczak, Tomas Sedovic, Sindre Johansen, Beat Scherrer, Vincent Mutolo, Max von Forell, Raphaël Thériault, Wyatt Herkamp, Gioele Pannetto, Egor Ternovoi, Kai Kaufman, Yufan Lou, 0lach, Richard Pringle, Tom Forbes, Daniel Wagner-Hall, Cole Kurkowski, Thehbadger, dataphract, Aaron Gorodetzky, callym, Daniel Papp, Aiden Scandella, Hadrien G., Twan Walpot, Lena Schönburg, Michal Hošna, Jelle Besseling, Sean Bryant, Tobias Bahls, Kevin Nguyen, Mateusz Wykurz, James Leitch, Raine Godmaire, Bob Ippolito, Laine Taffin Altman, Jörn Huxhorn, Josh Triplett, belzael, e9zaktw1, Chris Sims, Dylan Anthony, Radu Matei, Matt Jackson, Brooke Tilley, Simon Menke, Christoph Grabo, Òscar Pérez, Philipp Angerer, Marcus Griep, Evan Relf, Torben Clasen, Andrew Neth, Victor Song, Justy, anichno, SeniorMars, Matthew T, Marcus Griep, David Cornu, clement, me, Hamilton Chapman, Olly Swanson, Herman J. Radtke III, Ivo Murrell, Lucille Blumire, Olivier Peyrusse, Tanner Muro, Sawyer Knoblich, Steven Pham, Toon Willems, Andronik, Richard Stephens, Boris Dolgov, Mark, Guillaume Demonet, Aleksandre Khokhiashvili, Andy F, Ben Wishovich, Michał Bartoszkiewicz, James Rhodes, hgranthorner, Jonas Platte, Marcin Kołodziej, Wojciech Smołka, Vladimir, Dom, Dave Minter, Michał Zalewski, Ives van Hoorne, Christian Bourjau, Matt Campbell, Johnathan Pagnutti, Adam Lassek, Nyefan, Geoff Cant, Thor Kamphefner, Blake Johnson, David Barsky, Ian McLinden, Jimmy Hartzell, Nicolas Riebesel, Diego Roig, Timothée Gerber, Astrid, Daniel Silverstone, Sam Leonard, Dominik Wagner, Ben Mitchell, Zaki, old.woman.josiah, teor, Guillaume E, Romain Ruetschi, Makoto Nakashima, Berkus Decker, Manuel Hutter, Peter Shih, Taneli Kaivola, Lawrence Bethlenfalvy, Daniel Strittmatter, Braidon Whatley, Mathias Brossard, Philipp Gniewosz, prairiewolf, compwhizii, Nicholas Orta, David E Disch, Duane Sibilly, Luke Yue, Luke Konopka

I do not come to you with answers today, but rather some observations and a lot of questions.

The weird glitch

Recently I was editing some video and I noticed this:

Not what the finger is pointing at — the dots.

Here are the separate layers this image is made up of: the background is a stock image I’ve licensed from Envato Elements:

Because I use it as a background image, I’ve cranked down the exposition in the Color tab:

And for a little added style and some additional readability for subtitles, I’ve added a tilt-shift blur:

On top of that, we have some text captured from Safari as a transparent image by right-clicking on an element in the Inspector and picking “Capture Screenshot”, one of my favorite tricks as of late:

However, the transparency is not complete. GitHub’s CSS has tables with an opaque background. So I added an additional 3D keyer to remove the background:

Those two layers composited already show some strangeness:

Very well — enhance!

It’s still kind of subtle, but you can see the dots.

No, they’re not:

They are also not here on the Fusion tab at all:

The dots are bad when playback is using full resolution:

But things get a lot weirder once you scale down. This is half resolution:

And this is quarter resolution:

I have investigated this for half a day and I have good news and bad news.

The good news is: unpausing makes all the artifacts disappear!

Well bear, what do you think the bad news are?

Even if I considered those artifacts acceptable, the Tilt-Shift Blur effect makes them impossible to ignore: it blows up every single point into those large colored circles. Even with a strength of zero, it turns those dots into streaks that are reminiscent of memory corruption:

Disappointingly, I don’t know what is causing this particular problem.

There’s a whole bunch of things that don’t solve it: the 3D Keyer can work in different color spaces:

…and has a bunch of knobs you can turn:

But none of them truly fix it. The other keyers exhibit the same issue, here’s the Ultra Keyer instead:

Same with the Luma Keyer, the Chroma Keyer, etc. No amount of checking “Pre-divide / post-multiply” makes a difference. Manually adding an “Alpha multiply” node does jack shit. Same with “Gamut limiter” — there goes my theory that it’s just outputting colors outside the gamut but that… because it might be using f32 values internally, uhhh something happened?

But nope.

Playing with color spaces

Bear, it’s in the most vanilla colorspace you can imagine: sRGB.

Oh that’s just the IEC standard for it:

Among other things, the standard (published in 1999, amended in 2003) specifies the proper transfer function to use, which is almost like gamma = 2.2, but not quite:

Close enough though: even if some part of the pipeline used “simplified sRGB” by doing gamma 2.2 instead of using the IEC curve, we wouldn’t see that.

In that case, probably nothing - but when we use the wrong color profile, things look, well, wrong. They can look washed out, they can look too saturated, too dark, too bright, any of these.

Believe it or not, HDR is the main reason I’m using iPhones all around now. By default, my iPhone 14 with the Camera app will shoot HDR video.

You can disable HDR in the settings:

…but personally, I prefer shooting with the Blackmagic Camera app for iPhone, which calls color spaces by their actual names:

I took 4 short videos in quick succession and dragged all those in DaVinci Resolve just to find out what would happen:

Indeed they do! First off, there’s most likely an exposure / white balance / etc. mismatch between the built-in Camera app (which had everything on full auto) and the Blackmagic Camera app, but even just looking at the three pieces of Blackmagic footage, things look different, even on this sRGB screenshot, shown on my DCI-P3 display.

CIE Chromaticity diagram

If we switch to Resolve’s Color tab, we can see which colors are actually used in each image, via CIE Chromaticity diagrams.

Rec.709:

P3-D65:

Rec.2020-HLG:

iPhone Camera app:

The “horseshoe” shape in white represents the visible spectrum, and the triangle labelled “Rec.709” represents our color space: which colors of the visible spectrum we’re able to “represent”, or “encode”.

The circle is the “white point” — Rec.709, P3-D65 and Rec.2020-HLG are all using the same white point, D65, which…

…is intended to represent average daylight and has a correlated colour temperature of approximately 6500 K. CIE standard illuminant D65 should be used in all colorimetric calculations requiring representative daylight, unless there are specific reasons for using a different illuminant. Variations in the relative spectral power distribution of daylight are known to occur, particularly in the ultraviolet spectral region, as a function of season, time of day, and geographic location.

— ISO 10526:1999/CIE S005/E-1998, CIE Standard Illuminants for Colorimetry

Without agonizing too much about the science of it, we can see a couple interesting things: the Rec.709 feels very “noisy” for some reason:

I have no idea if it’s normal or not, but we don’t have the same thing in the P3-D65 footage:

So… maybe it’s an encoding artifact? Not sure.

But the thing that’s hard to ignore is on the Rec.2020 chromaticity diagram. Much like, if you crank the gain on an audio track, you can see it clip: you can see the peaks being flattened to the minimum and maximum representable value, as if “clipped” with a scissor:

Similarly, we can feel that our Rec.2020 footage feels a little cramped in our Rec.709 color space: it wants to get out!

But that’s not even what feels wrong with this comparison… the Rec.709 footage looks “less wrong” to me — the Rec.2020 one has some colors that look… off. The floor is too bright. The cat’s fur becomes too bright too quick.

Right!!! The whole reason we have a “gamma curve” in the first place is to spend our bits wisely.

If all you had was 16 shades of grey (sorry E.L James), which would you choose?

Linear, or sRGB?

Exactly — with a “linear” progression (in terms of light emission), the shades become “too bright” much too quickly.

And that’s what the curve I showed earlier is all about:

Reading this graph, we can see that an encoded value of 0.1 is barely equivalent to 0.01 lightness. To obtain 0.1 lightness, we have to go all the way to 0.35!

If we weren’t using “gamma curves” like these, colors would look a lot worse, especially given how long we’ve been using 8-bit color.

Our first transfer function

Before things get a lot more confusing, let’s ask ourselves: what is the exact name of the transfer function we just plotted?

As far as I can tell, it’s a “reverse OETF”.

An OETF (opto-electronic transfer function) is used when capturing/encoding: The camera sensor detects some amount of light and we need to figure out which integer value to encode it as in the video signal.

An EOTF (electro-optical transfer function) is used by monitors/displays, taking a signal and deciding how much light to emit for each integer value of the signal (more or less).

Finally, an OOTF is the composition of the OETF and the EOTF and we do not need to worry about it at all — check the Wikipedia page on transfer functions in imaging if you really must.

Really, the only one we have to care about is the “OETF”, which has been done in our camera and that we need to reverse in order to know how things are.

For sRGB, the OETF is defined as:

$$E(v)=\{\begin{array}{cc}Av& v\le V\\ \\ (1+C)v^{1/\mathrm{\Gamma }}-C& v>V\end{array}$$

where $V=0.0031308$, $A=12.92$, $C=0.055$, and $\mathrm{\Gamma }=2.4$

$v$ is the lightness value (how much light hit the camera sensor), and $E(v)$ is the encoded signal (the RGB value we put in the video file).

The “reverse OETF” is then:

$$D(u)=\{\begin{array}{cc}\frac{u}{A}& u\le U\\ \\ {\left(\frac{u+C}{1+C}\right)}^{\mathrm{\Gamma }}& u>U\end{array}$$

where $U=0.04045$, and $A$, $C$, and $\mathrm{\Gamma }$ are the same as for $E(v)$.

How do we know we got the inverse right?

Although not very rigorous, plotting them allows us to see a symmetry across the $y=x$ axis.

It looks a little like an almond!

Another way is to do $D(E(v))$ and simplify to see if we fall back to $v$.

First the linear part:

$$\begin{array}{c}D(u)=\frac{u}{A},E(v)=A\cdot v\\ \\ \begin{array}{cccc}D(E(v))& =\frac{E(v)}{A}& & \text{Apply D}\\ \\ & =\frac{A\cdot v}{A}& & \text{Apply E}\\ \\ & =v& & \text{Cancel out A terms}\end{array}\end{array}$$

Then the exponential part:

$$\begin{array}{c}D(u)={\left(\frac{u+C}{1+C}\right)}^{\mathrm{\Gamma }},E(v)=(1+C)v^{1/\mathrm{\Gamma }}-C\\ \\ \begin{array}{cccc}D(E(v))& ={\left(\frac{E(v)+C}{1+C}\right)}^{\mathrm{\Gamma }}& & \text{Apply D}\\ \\ & ={\left(\frac{(1+C)v^{1/\mathrm{\Gamma }}-C+C}{1+C}\right)}^{\mathrm{\Gamma }}& & \text{Apply E}\\ \\ & ={\left(\frac{(1+C)v^{1/\mathrm{\Gamma }}}{1+C}\right)}^{\mathrm{\Gamma }}& & \text{Cancel out C terms}\\ \\ & ={\left(v^{1/\mathrm{\Gamma }}\right)}^{\mathrm{\Gamma }}& & \text{Cancel out (1+C) terms}\\ \\ & =v& & \text{Cancel out exponents}\end{array}\end{array}$$

And finally, the breakpoint for $D(u)$ was at $U=0.04045$, which gives us:

For the linear segment:

$$\begin{array}{cc}D(U)& =\frac{U}{A}\\ \\ & =\frac{0.04045}{12.92}\\ \\ & \approx 0.0031308\end{array}$$

For the exponential segment:

$$\begin{array}{cc}D(U)& ={\left(\frac{U+C}{1+C}\right)}^{\mathrm{\Gamma }}\\ \\ & ={\left(\frac{0.04045+0.055}{1+0.055}\right)}^{2.4}\\ \\ & ={\left(\frac{0.09545}{1.055}\right)}^{2.4}\\ \\ & \approx 0.0031308\end{array}$$

Yup, looks like we got it right — that explains where the breakpoint for $E(v)$, $V=0.0031308$ comes from.

Parade scope

Back to our footage, there’s another fun color visualization we can look at: the “Parade”. This displays red, green, and blue values (here on a scale of 0 to 1024, to mimic 10-bit encoding, although that’s configurable) from left to right.

Our Rec.709 footage, which looks “good”, has a good spread:

Our Rec.2020 footage however, seems squished at the top of the scale:

Luckily, there’s a slider for that!

But here’s the thing: the footage looks fine when reviewing it on my iPhone:

It’s not “blown out”, or anything.

Good question! I Airplay’d the screenshot to myself and got an sRGB JPEG file. It definitely looks more “vivid” on my iPhone screen than on the webpage. I’m not actually sure iPhones can take HDR screenshots?

But the point is: the iPhone did something to that Rec.2020 footage. It’s showing more colors to me on the iPhone screen, but it’s able to save an sRGB version as a screenshot that doesn’t look as wrong as what I had when I dragged the video file on my DaVinci Resolve timeline.

In fact, my mac can do “that” too: opening the footage in QuickTime shows “correct” colors as well:

And what “that” is, is tone mapping.

More transfer functions

How do we know for sure how color is encoded into our H.265 files?

The macOS finder gave us three numbers for each of these files:

• 1-1-1 for Blackmagic Cam in “Rec.709” mode
• 12-1-6 for Blackmagic Cam in “P3 D65” mode
• 9-18-9 for Blackmagic Cam in “Rec.2020 - HDR” mode

Those numbers tell us all we need to know, and are standardized in the ITU-T H.265 Recommendation, which is a free download, and I have gone through its 728 pages to fish out the relevant information.

The first number is for color primaries. Notable numbers include:

• 1 for Rec. ITU-R BT.709-6 and IEC 61966-2-1 sRGB or sYCC (HD but SDR video content)
• 4 for Rec. ITU-R BT.601-7 625 (PAL)
• 5 for Rec. ITU-R BT.601-7 525 (NTSC)
• 9 for Rec. ITU-R BT.2020-2 and Rec. ITU-R BT.2100-2 (HDR)
• 12 for SMPTE ST 2113 “P3D65” (hey that sounds familiar)

These are the xy coordinates of what the color space considers red, green, and blue, in the CIE 1931 color space.

Again, the horseshoe is the entire visible spectrum and the triangles are “color gamuts” that represent which colors we can actually encode.

The Rec.2020 gamut (thick circles) is larger, it covers more of the visible spectrum than Rec.709 (thin circles) — that’s why the cloud of points in this chromaticity graph feels cramped: it’s actually Rec.2020 footage that we’ve clamped to Rec.709: we have to throw away some of the colors that were encoded into the original footage.

Go right ahead.

The short answer is 8-bit color: we talked about spending our bits wisely and it’s time to visualize it:

Without gamma curves, all of our possible encoded colors are concentrated near the illuminant, and there’s a lot of gaps near pure red, green, and blue colors.

But if you check “Apply TRC”, you can see all the discrete colors spread out away from the illuminant, and closer to the color primaries. This is valid for Rec.709 and Rec.2020 just as well.

And that’s what the second number is for! TRC for Transfer characteristics, which really is “transfer functions”, or “tone response curve” (also TRC), or “gamma curve”, yada yada.

Well. It’s not that simple. Note 5 says, paraphrasing:

some values of transfer_characteristics are defined in terms of a reference OETF, and others are defined in terms of a reference EOTF, according to the convention that has been applied in other Specifications.

In the cases of Rec. ITU-R BT.709-6 and Rec. ITU-R BT.2020-2 (which can be indicated by transfer_characteristics equal to 1, 6, 14, or 15), although the value is defined in terms of a reference OETF, a suggested corresponding reference EOTF characteristic function for flat panel displays used in HDTV studio production has been specified in Rec. ITU-R BT.1886-0.

Here’s the ITU-R BT.1886 EOTF in question:

$$L=a(max[(V+b),0]{)}^{\gamma }$$

(Source: ITU-R BT.1886 on Wikipedia)

$V$ is the “input video signal level”, in the range $[\mathrm{0,1}]$, so far so good — we can divide our 8-bit values by 256, or our 10-bit values by 1024, no worries there.

$L$ is the screen luminance in $cd/m^2$ (candelas per square meter, also called nits), which, uhhh, where did my beautiful normalized $[\mathrm{0,1}]$ light-linear value go? This is much too real-world for me. $\gamma$ is 2.4, which is unsurprising for Rec.709 / SDR (see below).

$a=({L_W}^{1/\gamma }-{L_B}^{1/\gamma }{)}^{\gamma }$ is user gain, previously known as “contrast”, because, that’s right, EOTFs are for displays.

$b=\frac{{L_B}^{1/\gamma }}{{L_W}^{1/\gamma }-{L_B}^{1/\gamma }}$ is user black level lift, aka “brightness”.

Finally, $L_W$ and $L_B$ are screen luminance for white and black, respectively, also in $cd/m^2$.

So yeah. What we plotted earlier isn’t the EOTF, it was a reverse OETF.

Notable transfer_characteristics values for H.265 include 1, for Rec. ITU-R BT.709-6.

They give this OETF:

$$\begin{array}{cccc}V& =\alpha \ast {L_c}^{0.45}-(\alpha -1)& & \text{for }1>=L_c>=\beta \\ \\ V& =4.500\ast L_c& & \text{for }\beta >L_c>=0\end{array}$$

How do we know it’s an OETF? Because its input is L_c, a “linear optical intensity with a nominal real-valued range of 0 to 1”.

The value $\alpha$ and $\beta$ are constants defined for the the curve segments to meet at the breakpoint.

For TRC 1, 6, 11, 14 and 15 we have:

$$\begin{array}{cc}\beta & =0.018053968510807\\ \alpha & =1+5.5\ast \beta \\ & =1.099296826809442\end{array}$$

Sure! Let me just rewrite the OETF in a way that’s a little more consistent with our sRGB work from earlier:

$$E(v)=\{\begin{array}{cc}Av& v\le V\\ \\ (1+C)\cdot v^{1/\mathrm{\Gamma }}-C& v>V\end{array}$$

where:

• $V=0.018053968510807$
• $C=1-\alpha =0.099296826809442$
• $\mathrm{\Gamma }=\frac{1}{0.45}$
• $A=4.5$

Yup, only with a different slope $A$ for the linear bit, a different breakpoint $V$, a different constant $C$, and $\mathrm{\Gamma }=2.\bar{2}$ rather than $2.4$.

Here’s a plot of the sRGB gamma curve, zoomed into $v\in [\mathrm{0,0.01}]$

And here’s the Rec. ITU-R BT.709-6 curve, which we’ll hereafter lovingly refer to as just BT.709 (BT for “broadcast television”):

Moving on to HDR, value 18 refers to ARIB STD-B67, also Rec. ITU-R BT.2100-2 HLG, which we’ll simply refer to as “HLG” moving forward, for Hybrid log-gamma.

The definition given in the H.265 spec V10 is:

$$\begin{array}{cccc}V& =a\ast Ln(12\ast L_c-b)+c& & \text{for }1>=L_c>1÷12\\ V& =Sqrt(3)\ast {L_c}^{0.5}& & \text{for }1÷12>=L_c>=0\end{array}$$

Where $a=0.17883277$, $b=0.28466892$, $c=0.55991073$.

With pleasure:

$$E(v)=\{\begin{array}{cc}A{v}^{1/\mathrm{\Gamma }}& v\le V\\ \\ a\ast ln(12v-b)+c& v>V\end{array}$$

Where $V=\frac{1}{12}$, $A=\sqrt{3}$, $\mathrm{\Gamma }=2$, and the same $a$, $b$, and $c$ values already mentioned.

Well! Because in spirit, lightness levels are no longer $v\in [\mathrm{0,1}]$, they’re $v\in [\mathrm{0,12}]$.

That’s right, HDR is not just 10-bit (or 12-bit), it’s also brighter colors.

How white is your white?

There’s a cool demo called Wanna see a whiter white that embeds an HDR video to show you that, when you say #ffffff on a webpage (or rgb(255, 255, 255)), you’re really referring to “the brighest SDR white”, which really depends on your display.

Me, I have a pair of LG 27UP85NP-W computer displays at home, which sport the “VESA DisplayHDR(TM) 400” badge, meaning they should be able to reach all the way to 400 nits (remember, nits are just $cd/m^2$, candelas per square meter), and they’ve been tested to reach 413, so that’s cool.

But that’s the absolute highest they’ll go.

Right now I have them using the DCI-P3 color profile:

And I have the “High Dynamic Range” option left unchecked in macOS’s Display settings:

So… how white is my white? I don’t actually know! Because I don’t have a luminance meter, like the Konica Minolta LS-150:

So I can’t measure how much light my screen puts out: I can only compare various shades with my eyes, which adapt quickly to various lighting conditions!

In fact, that’s precisely why sRGB is traditionally displayed with a gamma of around 2.2, suitable for a typical office setting, Rec.709 is displayed with gamma 2.4, for darker living rooms in the evening, and DCI-P3 is displayed with gamma 2.6, for near-dark movie theaters! (DCI for “Digital Cinema Initiative”):

The higher the display gamma, the deeper the blacks — in other terms, it “improves contrast”.

But, and that’s where things get confusing, this display gamma is not the same as the encoding gamma that’s used in the OETFs we’ve seen.

The sRGB OETF is pretty close to a Gamma of 2.2:

The Rec.709 OETF, even though it uses $\mathrm{\Gamma }=\frac{1}{45}=2.\bar{2}$ for the exponential part, is overall better approximated by Gamma 1.96:

The gamma used in OETF, again is really just here to make sure that we make the most out of our bits, whereas the display gamma is usually adjustable on computer monitors and TVs, to suit the overall lighting environment: it’s all about contrast.

Gamma is such a fascinating operation for me, because it always maps back to $[\mathrm{0,1}]$, as opposed to something like lift:

Or gain:

Conclusion

I left this article in that state for months — working on other projects in the meantime.

At some point I thought I discovered that if you tell DaVinci Resolve to use an HDR color space while editing, then the stars were gone. But I never could really put my finger on what was going wrong.

And then it happened again:

Like before, it’s barely noticeable in Full resolution:

And impossible to ignore in Half resolution:

I discovered that in the Color tab, increasing the gamma slider makes the problem lesser (although it also changes the colors), and decreasing the gamma slider makes the problem much, much more visible:

I even found a way to isolate just the artifacts, so you can see a night full of stars:

My conclusion was that if you use a gamut mapping node, then it works around the problem, since that’s how I worked around the problem for my unsynn video:

But you know what? It doesn’t work anymore. My workaround workaroundn’t.

And so, the mystery remains complete. It’s probably a floating point thing. But which one? Who knows. Not me! Not me.