search

EatTheFuture / image_tools

Eat the Future's collection of image/color tools.
Other
74 stars 6 forks source link

OCIO Maker: ACES Lite produces black display device in Blender #13

Open MysteryPancake opened 9 months ago

MysteryPancake commented 9 months ago

Hello! I tried using the OCIO Maker to produce an OCIO based on ACES Lite for Blender, but for some reason when I set the "View Transform" to one created by the LUT Maker, it results in pure black.

MysteryPancake commented 9 months ago

Here is a link to my config: https://drive.google.com/file/d/13Z9vsagreFtbmG0Xx7FcQZ6OR4ZDDNzx/view?usp=sharing Set the display device to "Nathan ISO500" to see pure black:

image
MysteryPancake commented 9 months ago

This issue does not occur if I use the "Blender" or "Custom" config presets instead:

image
cessen commented 9 months ago

Thanks for the report! And sorry for the delay responding. I'll take a look at this the next chance I get (probably within the next week or two).

Having said that, at the moment there's nothing really special or useful about the ACES Lite preset. So you can safely ignore it for now and instead use Custom with ACES AP1 selected as your working color space.

Having said that, unless:

  1. You're doing spectral rendering, or...
  2. You're targeting wide-gamut displays for final mastering (and have a wide-gamut display to do that mastering on), or...
  3. You're working for a client that needs wide-gamut footage to round-trip because they're targeting a wide-gamut master...

...there's not much reason to work in a wide-gamut color space like ACES at all. So if none of those are true, it's probably best to stick to a Rec.709 working color space. You won't actually be losing anything meaningful, and you won't be working blind (i.e. your display will actually be able to display the all the colors you're working with).

cessen commented 9 months ago

I believe I've tracked down the issue, and it's not actually specific to the ACES Lite preset. For example, you can make this happen even with the Blender 3.0 preset if you set things up right.

The root cause of the issue isn't actually in OCIO Maker, but rather is this bug in Open Color IO: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1763

More details: at the moment, whenever a user wants to use an input transform also as an output transform, OCIO Maker just reuses the same transform definition for both. But that means that the output transform is reusing the input gamut clipper 3D LUT. Normally the input gamut clipper LUT is applied with the CPU code path, which properly uses full precision floating point. But when used in an output display transform, it goes through the GPU code path. Since the input gamut clipper LUT is both low res and very high dynamic range, that runs into the banding issues in the above-linked issue. And at the extreme (as is the case here), the banding just clamps everything that's not super bright to black.

In this particular case, we shouldn't actually be using the input gamut clipper for an output anyway. That was a bit lazy on my part. So I'll fix that, and in the process we can switch to a higher-res, lower-dynamic-range LUT to mitigate the impact of the Open Color IO precision bug.

marklio commented 4 months ago

I think I ran into this or something similar trying to linearize movie clips in the motion tracker workspace. Footage there was just black, whereas the same footage projected onto geometry with the same color space looked great. Think it's the same issue, or something else that I should bug?

cessen commented 4 months ago

It's very likely the same bug. Thanks for poking me on this.

(I'm currently on vacation, but will take a look after I get back in April. If I forget, feel free to poke me again more harshly, ha ha.)