ampas / aces-vwg-output-transforms

Other
0 stars 2 forks source link

Need to try select a single choice for dealing with scene values that lie beyond the models. #13

Closed KevinJW closed 3 months ago

KevinJW commented 1 year ago

Currently we have:

  1. compression mode
  2. LMS matrix options
  3. linear extension
  4. ...

We should remember that straightening out the lines too much will result in us not really using the CAM.

nick-shaw commented 1 year ago

Have we definitely settled on compress mode (combined with a custom LMS matrix, the exact coefficients of which which may not yet be finalised)?

priikone commented 1 year ago

The compress mode seems to have some invertibility issues I've noticed. They may be related to the changes we've made to avoid NaNs/Infs or it maybe just the algorithm itself. Not sure, unfortunately I still have no clear grasp on how it actually works...

priikone commented 1 year ago

But I suppose the overall idea is to do effectively gamut compression. Maybe some other algo could be tried as well. Jed certainly did a lot of work on this (https://github.com/jedypod/nuke-colortools/blob/master/toolsets/chromaticity/GamutCompressCLin.nk is very simple chromaticity linear compressor).

priikone commented 1 year ago

What if we just clamped the input to 0? Isn't that what ACES1 does as well? We're trying to handle all these crazy values out there, most of which is just noise, with a complicated algorithm, that perhaps isn't needed at all. I quickly tested this with compress mode disabled (and with Thomas's CAM16 primaries) and everything looks nice. In fact, in many cases looks better than nice, better than with the compress mode (there will be some skew). This included images like Red christmas and the Blue bar and other problematic images. And there is always RGC for those rare cases (and they really would be rare with the current ACES2 candidate) that may prove problematic. Thoughts?

nick-shaw commented 3 months ago

The release (CTL Developer Release) clamps input to AP1.