Yes, point being the value can’t change with the gamut, or has to come to same value (like maybe use cusp lightness of Rec.2020 gamut always).
Thanks again Alex for all the visualizations, these are crucial to understanding what is happening inside the model.
I am going to post two images just as a point for continued discussion.
These were made by the simplest means to show a simple point, and could be easily done on any images if someone was curious.
These are simply a 50/50 blend of P3 and 709 limited P3.
One version is kept in P3 and the other is converted to Rec709 (2.4 Gamma)
The only point that is worth making with this example is that as certain logic should be that the rec709 image that has clipping if it is to be as “colorful” as P3 and P3 should be able to be as colorful while retaining more detail.
That said, it does not mean that this logic applies if the tools available do not agree!
But what this example could suggest is that maybe there is an abstract/virtual middle cusp that that clips 709 and is well inside P3/2100.
Pictures are not really needed to make that point, but these images do match very well and the 709 is a little brighter/more colorful and the P3 is only a little dimmer but with all the detail/tone retained.
None of this changes all the work Alex, Nic and Pekka have been doing regarding focus distance and angles, but it could demonstrate what a target could look like and whether it is a good target.
I don’t know if ACES Central processes images when you upload them, but when I download both images it’s not that they look identical. They ARE identical to all intents and purposes, and both tagged as sRGB.
1 Like
If they look identical that is good. (they should)
If they are tagged srgb that is bad.
Maybe I should tag both srgb or no tag so they will look wrong in browser but correct if you download?
Here are the images above untagged
Again, just a simple/stupid experiment that anyone can replicate, but might be a quick way to visualize what tradeoffs could look like and what should/could be targeted in the gamut mapper.
Following the 101th meeting, I would like to make a few comments about Alex´s latest experiment.
Why do I prefer the focus distance at 1000 ? Because I feel like tonality and luminance is much more preserved. It really reminds me these experiments from back in the day where we tried to show that “tonality” matters.
Look at this for instance :
With a focus distance at 3, I don´t feel at all the (quadratic) decay of the light. This looks “wrong” to me. 
I really agree with this statement from Christopher :
- We don’t absolutely need to know how the human visual system works.
- We only really need to know how to make pictures work! […]
- WTF is going on with the shadows and the blue light on the pool table in blue bar!
- How did it look? How should it look? How could it look? […]
And my take on “how pictures work” is that (smoothness of) gradients are absolutely essential to picture formation (this is what I care about as a lighter). So I support 100% Pekka´s suggestion to look at gradients and I do agree that the “compression rate” on the “path-to-peak-brightness” is essential.
Overall I feel it is complex to wrap up this VWG because we haven´t made a clear choice as a group on which design requirement should be prioritized above others. On the list we have :
- Should look good out-of-the-box.
- Must be invertible.
- Must reach corners of the display gamut (somehow ?)
And my fear is that because we try to please these three requirements, we will end up with a “jack-of-all-trades” Output Transform (I will not use the acronym DRT here since it is a Baselight term).
The only way that I can think of to satisfy these tree requirements is to provide a very good set of LMTs to be used with ACES 2.0.
Regards,
Chris
PS : About the “looking good out of the box” requirement, just a friendly warning that it seems that this prototype is clipping (breaking the smoothness of gradients). You can see it on the neck here :
1 Like
I repeat myself saying that the choice doesn’t have to be between not doing lightness mapping at all (preserve original lightness == horizontal projection) and the current projection. There’s a whole world between those two. Doing horizontal projection below the cusp I think is perfectly reasonable. Less so above the cusp as it can desaturate colors too much and make them appear clipping when there’s no reason to do so. I think @bottosson says it well in:
One challenge with preserving lightness though is that all colors … get projected to a single point, and that highly saturated colors can become almost completely desaturated if light or dark enough, even though sacrificing just a small amount of lightness would have resulted in a much closer match.
Björn’s page is a good read obviously. I’ve implemented most of those mappers previously and the one I like the best is Adaptive L hue dependent one. I have a blink version of that somewhere but the behavior with dark colors doesn’t make it suitable for this DRT, was my conclusion.
Here’s few images comparing v035, v035 horizontal projection and ARRI Reveal (for state of the art third party comparison), in that order. I’m showing here what I would consider over desaturation that happens with horizontal projection above the cusp:
Here’s just an example with RED christmas of v035 and v035 with an LMT that changes contrast. One thing to keep in mind is that the rendering out of the box is less contrasty than ACES1, so if we assume people are going to increase contrast it’s good to check how it looks (I’ve been doing this throughout the DRT development). This is still less contrasty than ACES1 but much closer. Make what you will of it.
But, the problem at hand was that the the ARRI bar cyan-green appearance match was less than perfect between Rec.709 and P3. My feeling is we should primarily address that issue rather than revamp the whole rendering. The Rec.709 rendering, with its darker mapping, is a result of developing the SDR/HDR appearance match, and I can take the blame for it. Obviously we could do it the other way around and match HDR to SDR instead. Horizontal projection would create more of a mismatch for SDR/HDR.
So, I think we should first do what we did in the meeting, which is to bring the projection on the same trajectory in different gamuts. That should make it a little bit better. If that’s still not good enough appearance match for Rec.709 and P3 (SDR), then we could think about matching the lightness also between the gamuts. And that then opens that whole world of possibilities between the horizontal projection and the current one. I assume the biggest discrepancy in the match between Rec.709 and P3 comes from the brightness of the color, so it would then make sense to test how they look when the lightness mapping is identical for all the gamuts.
But, personally, I consider the less than perfect appearance match between different gamuts less of an issue compared to following:
Correct. The mapping is not smooth. I’ve tried to bring this up a few times. It seems doing the compression along the constant hue lines results into discontinuities in the final mapping. This is what we should address - somehow.
Here’s those three example DRTs again in same order.
Anyway, these are my thoughts on this particular issue…
5 Likes
Cool. Thanks Pekka for the insight !
I can share with you two examples (red xmas and blue bar) which I thought to be good attempts at smoothness.
I agree this should be looked into.
Regards,
Chris
Hi @ChrisBrejon, thanks for keeping the conversation going. I just want to çlarify the intent of the two pictures you posted… are you proposing these as examples of an acceptable rendering?
Yes, exactly. If you look at blue bar, I find the example very compelling, probably a better starting point for an Output Transform.
In the CAM DRT prototype, those areas look concerning or “wrong” :
Troy might call these two screenshots “cognitive dissonant”. Now the challenge is to define precisely what and why it looks “wrong”.
Chris
Those images look very much lifted and not in the right RGB colourspace. What DRT did you use to produce them?
Hello,
to avoid any confusion, I re-generated the image, encoded for BT.1886 display. And a version also with an LMT so it does not look lifted.
But what I was hoping to discuss are those “kinks” I can see here and there :
I am wondering if they are similar to what Alex Forsythe pointed out a month ago as Mach bands in the diver image. For the past week or so, I haven´t stopped thinking about Christopher´s sentence :
We don’t absolutely need to know how the human visual system works. We only really need to know how to make pictures work!
And I think he is right on. Since none of us were present in the blue bar or red xmas shoot, maybe we could focus more on the picture´s quality and less on the scene and “what our eyes saw” ? And to me one of the most important aspects of a picture is the smooth tonality. So what are those kinks from ? Are they similar to the ones present in those ramps ?
And what is happening in those screenshots of blue bar I shared in my last message ? Is there some kind of threshold (g0 ? brilliance ?) that makes these areas look “wrong” ?
My tuppence,
Chris
Might be helpful to look at how these things appear in RED IPP2 and ARRI Reveal as a point of comparison.
1 Like
ARRI Reveal would be interesting to look at because beyond the Output/Display transform there’s also some transformation done as part of ACE4 (Arri Color Engine 4) to handle clipping of certain colors, like blues. I wonder if it’s similar to the reference gamut compression?
Source: https://www.fdtimes.com/pdfs/free/115FDTimes-June2022-2.04-150.pdf
1 Like
Posting some comparisons of CAM DRT v35 and ARRI Reveal.
RED
In this first one I’m noticing that the reds in the CAM DRT seem more “lit” and “punchy” (I think this has always been the case with ACES and reds). The red on the Sunkist raisin box in ARRI Reveal looks more true to life to me.
Same could be said for the orange jump suits on these astronauts.
which brings us to how this impacts skin.
Red in these swatches appears more magenta in the CAM DRT than in the ARRI Reveal, and goes quicker to white (AKA pink) while the ARRI Reveal holds the red longer.
Finally for red we of course need to see Red Christmas
BLUE
Now some observations about blue.
Looking again at the blues in the color chart in this still life, and comparing this to the blues in the color chart in my hand, I’d say the CAM DRT looks closer to what I see.
However the blue in these swatches in CAM DRT seems to be going a bit magenta.
also here in the blue screen
note blue here, including on the woman’s face. Going magenta in CAM DRT.
The ARRI Reveal appears to lift the blue a bit, compared to CAM DRT. For example on the blue glass on the table in this image
or on the blue bottle here
and of course Blue Bar
Hope that’s useful.
1 Like
Let me add one more comparison. Compare the red and blue spheres, which illustrates many of the things I noted above.
In addition you can see here in the dragon that the ARRI Reveal appears to be desaturating darker colors. At least that’s what I believe is happening. I feel I see that on this fruit still life, which gives it that “filmic” look. I suppose one could argue this might be more appropriate in an LMT.
1 Like
Following on from what @priikone said last meeting, it is fairly simple to make it so the compression slope gets steeper instead of shallower as the cusp gets more saturated. This Desmos simply changes the expression for the slope control variable to:
\;\;\;\;g=\frac{50J_{max}G_{dist}}{M_{cusp}}
instead of:
\;\;\;\;g=G_{dist}M_{cusp}
Since g is effectively a constant in the equations, the quadratic solve still works exactly as it did before (I was initially worried I would have to redo that maths, and it might break!)
The factor of 50 and J_{max} (Hellwig J value for display peak) are to get the resulting values back up into the same kind of range as they were previously, and also scale with the larger cusp M values in HDR.
This did make me think about what happens currently in HDR. Because M_{cusp} is larger for HDR, g currently ends up larger. So the slope may be steeper in HDR. Of course the whole cusp is larger in HDR, so I’m not sure what the net effect actually is. It certainly merits consideration.
1 Like
I think it’s interesting to see that ARRI Reveal shows quite more (perceived) noise in the frame labeled 050 and CAM DRT v035 is much cleaner in the bottom end. Too clean perhaps? The odd thing about CAM DRT v035’s rendering is that the table and other black objects look much more magenta-ish where on Reveal it’s quite neutral.
2 Likes
On closer look it seems to me that ARRI Reveal is rendering darks a bit darker making the color difference less noticeable resulting in less of a cast. Here I took a look at it with two other renderings. I used v034 because I didn’t install v035 yet but I don’t think the rendering changed there in that regard? In any case I do like how CAM DRT is rendering the bottom end.
(images were scaled up for comparison, not 1:1 pixel)
Derek, have you also compared ARRI Reveal with CAM DRT v35 in HDR? If so, are the comparisons similar in their differences between SDR and HDR, or what are the differences?
Also, does ARRI Reveal only work with ARRI Wide or can it be applied to DaVinci Wide from Braw? And where did you get ARRI Reveal to apply to the sample frames? The ALEXA 35 Supporting Tools & Software page indicates that Reveal is supported in DaVinci.
Shebbe, I am glad you are looking at comparing various ‘renderings.’ Same questions.
Thanks