Meeting Summaries 

ACES Output Transforms VWG 

← Use sidebar to navigate to a particular meeting.
Use Cmd+F or Ctrl+F to search this page.

Meeting #93, March 15th, 1pm PT

Attendees

Alex Fry
Kevin Wheatley
Scott Dyer
Nick Shaw

Lars Borg
Daniel Brylka
Chris Clark
Alex Forsythe
Francesco Giardiello
Luke Hellwig
Zach Lewis
Jeffrey D Mathias
Pekka Riikonen
Juan Pablo Zambrano

Meeting Notes

  • Kevin Wheatley: To help document the DRT I've been breaking it down and implementing the model in C++. Luke sent me expected input and output values to verify my implementation. Pekka posted on ACES Central about his latest experiments.
  • Pekka Riikonen: I've been looking at simplifying the chroma compression. I started by scaling down the values, and working from that. I like the results from my new prototype. I enable cusp smoothing, and removed ZCAM and linear extension, to simplify the code. The new chroma compression is much simpler. I scale M by the same ratio as J, then normalize so it's 1.0 at the cusp. So it's now hue dependent because we use the cusp. My compression curve is much simple than the old one, but has more control. I then reverse the normalization and add saturation. The compression is driven by tone scale lightness, so there's more compression for brighter values creating a path to white. I'm currently always using Rec.709 as the compression gamut. It means anything within Rec.709 is identical on all displays. The rendering is very similar is SDR and HDR. I also scale the cusp with an eccentricity factor. I tried three curves for that - CAM16, Luke's curve, and a custom curve. My custom curve doesn't have the dip around cyan that Luke's does, to prevent under-compressing cyans and blues. I find the custom one works best.
[Pekka showed the inverse with the three curves]
  • Pekka Riikonen: Luke's curve is fitted to the Munsell data-set. Maybe that just doesn't have enough samples in that region. Without the eccentricity we get very small compression of blues, and yellow goes too far out on inverse.
  • Luke Hellwig: You're concerned about where things fall on a chromaticity diagram. But that's not perceptually uniform. That's why the lines aren't straight.
  • Pekka Riikonen: It's not the eccentricity the model does. It's only applied to the cusp.
  • Luke Hellwig: So it's only an issue if you start from Rec.709 and only use the inverse model.
  • Alex Fry: You would never do that. You only use the inverse so things end up in the same place when you go back forward.
  • Kevin Wheatley: If the inverse ends up with negatives because they are outside the working space, if you use any tool before the forward transform that doesn't preserve those, you lose that detail and it clips. Or you get yellows that the display device can't make through the transform.
  • Pekka Riikonen: There are now parameters for the chroma compression - a limit, compression strength, and 'expansion strength' (how quickly the compression increases). It affects the path to white, for example. Currently it uses Rec.709, but it doesn't have to.
  • Alex Fry: Have you tried having it follow the limiting gamut?
  • Pekka Riikonen: That's what I tried initially. That changed the 'interior compression' for different gamuts. It made the compression gamut specific.
  • Kevin Wheatley: It's effectively part of the look of our rendering, and shouldn't vary with target. Rec.709 may not be ideal. It could be P3. But there's no reason it should be a display gamut.
  • Pekka Riikonen: Initially the SDR HDR match was bad, but then I mate the expansion rate depend on peak luminance. Pure red still stands out a bit much. Maybe we should chose a space to normalize to which makes better HDR colors.
[Pekka showed the images from his post which compare v31 and the new v32]
  • Alex Fry: The fire image made me worried we had introduced some skews.
  • Pekka Riikonen: Nothing is clipped, so the curves in CIExy are the hue lines in the model. We may just be seeing some orange that was always there, but was previously desaturated.
  • Lars Borg: Can I suggest another test image? With Sony's HDR demo you need to compress the clouds round Mount Fuji without making them look like air pollution. If you increase saturation you make ugly clouds.
  • Alex Forsythe: Did you look at large smooth sweeps of color? I was concerned that the Alexa35 diving image with the red. light had Mach bands. It may be internet compression.
  • Pekka Riikonen: Without cusp smoothing there is a noticeable band. With it I think it's better.
  • Alex Fry: We've used two different cusp smoothing. One which cuts into the gamut at at the cusp.
  • Pekka Riikonen: Matthias's original did that, so mine compensates by scaling it out, and going up. It does introduce more clipping, but the angle is so shallow it shouldn't be visible.
  • Alex Fry: Maybe the sharper cusp is what causes the band in the image.
  • Pekka Riikonen: With this image the red light comes out bright pure red, which doesn't match SDR.
  • Alex Fry: It's tricky. We don't want to limit HDR with the SDR desaturation. It's easier to desaturate HDR highlights if you want that. Harder to add saturation if the rendering desaturates.