ACES Output Transforms VWG
← Use sidebar to navigate to a particular meeting.
Use Cmd+F or Ctrl+F to search this page.
Meeting #139, February 14th, 1pm PT
- Alex Fry: The should be ground truth for last week's version, I didn't push the right version until later in the week. So if anybody pulled it after the meeting they should pull again. Also the for v53 didn't include the changes made in the meeting. So that might have confused people who weren't using the baked LUTs.
- Pekka Riikonen: Testing the parameters we came up with in the last meeting I saw some artifacts on a color wheel in HDR. I found new parameters to remove them – 1.15 for cusp_to_mid_blenad, and 1.4 for focus_distance.
- Alex Fry: I wonder if that's related to the jumpiness we saw in the top hull gamma.
- Pekka Riikonen: These parameter values don't affect the look. I also found I could reduce cusp smoothing to 0.19 without affecting the inverse. Optionally I also changed focus_gain_blend to 0.5 and focus_gain to 0.6 which I felt made the path to white smoother on the near infra-red ball. It has no affect on other images.
- Alex Fry: It looks better but we need more testing. Just changing parameters, do we still call this v53 or make a v54.
- Nick Shaw: In my DCTL I have no init() so declare all the lookups as constant arrays. I was using debugPrint() in the Blink and copying and pasting and reformatting, which was tedious. So I have ported the init() block to which generates the DCTL declarations. I then took the output of the Blink and Python and compared them in a , and the differences are mostly very small, which I put down to single vs double precision. There is most variation in the top hull gamma, which needs more investigation.
- Kevin Wheatley: I made some plots of the output of Nick's Python. Most plot pretty smoothly. It shows some table entries are wasted on the hue index, or just zeros, which we knew. The reach tables are quantized to integers. The top gamma plot is very noisy and has one very sudden change. I added extra precision to the code, and the plot changes dramatically, so it's not just smoother. So that seems very sensitive to noise and the search values you pick. Nick and I previously discussed smoothing the values, but it's probably better to calculate them better in the first place.
[Kevin showed his plots comparing the original and finer grained top gamma solve]
- Pekka Riikonen: That sharp transition is at the yellow cusp.
- Alex Fry: I'm testing very close to the ends, which may be too sensitive. Maybe pull them in and rely on the cusp smoothing.
- Pekka Riikonen: I think you needed those small samples to capture the yellow.
- Nick Shaw: The sharp change is not necessarily wrong. The concavity could change suddenly across a cusp.
- Kevin Wheatley: It seems odd that searching more finely finds a solution sooner, not just more smoothly. We have to ask how long we keep twiddling, and when we make a cutoff. Pekka tweaking the numbers to improve the image is worthwhile, but it would be good to understand why the artifacts are happening.
- Alex Fry: Does switching to constant top gamma solve it?
- Pekka Riikonen: No [in fact it does, but Pekka was looking at the wrong image] I wondered if it was the cusp to mid blend, which gets clamped at 1.0. The lerp of the focusJ now vaies with cusp height. The bias varies with the cusp so it doesn't darken yellows and cyans.
[Pekka showed the line in the code where focusJ varies with the cusp]
- Alex Fry: What happens if you vary the sample points in the upper hull gamma fit?
- PK: I have a version where those are parameters. It changes the artifacts, but can't fix them.
- Kevin Wheatley: We need to compare the true shape and the found gamma fit.
- [Alex showed his Nuke plot of the fit gamma and true shape]
- Nick Shaw: The jitter we see there is why I started looking at smoothing. Around the yellow there the top surface has a flat part, and the cusp where that becomes curved moves across the top as hue changes. When it gets to the end the large gamma needed to contain it is suddenly no longer required, creating the sudden drop off.
- Alex Fry: It's always seemed odd that the flat part is there.
- Pekka Riikonen: Changing the primaries may affect that. Or compress mode.
- Kevin Wheatley: The display gamut doesn't change with compress mode, but how we represent it does. I've seen similar odd shapes in other gamut visualizations.
- Christopher Jerome: It would be interesting to see what real world emissions from a monitor look like, and what causes the abruptness between those hues.
- Kevin Wheatley: Our approximation isn't a great approximation in some places. Because the search for the gamma fit is noisy it needs improvement. But it doesn't change the look, so we can put it out for testing while we work on improving it.
- Nick Shaw: If the tables are going to be pre-calculated offline we don't need to worry about speed.