[Bf-vfx] Mango Samples with ACES via rrt_sRGB

[Troy Sobotka]

On May 16, 2012 7:09 PM, "Brecht Van Lommel" <brechtvanlommel at pandora.be>
wrote:
>
> Uploaded some more files from a street test:
> http://download.blender.org/ftp/incoming/Mango/ocio-aces-to-rrt_srgb/
>
> There's the EXR exported as S-Log/S-Linear/ACES, and conversion of
> those files with ACES => RRT sRGB, and the S-Log file with the OCIO
> S-Log spaces => RRT sRGB. I think this shows that we are not
> accidentally applying an S-Log to sRGB transform. Also, letting OCIO
> do the S-Log to sRGB conversion doesn't give the same results, but
> it's slightly worse regarding dark shadows.

Thanks so much for the tests Brecht.

>
> Regardless, it seems unlikely to me that the conversion to ACES in the
> F65 software is wrong, it can't be that broken. It's also the most
> well defined part of the conversion, there is no data loss here. It's
> the ACES => sRGB transform that's tricky, where we need to fit a big
> gamut into a smaller one, and artistic choices play a role.

The sRGB RRT is quite well defined. If indeed the tests show a correct
transform, the creative intent via a LUT would be useful to put into a
chain before the final sRGB display transform.

The entire gamut likely won't be mapped to display, but rather a more
classic curve at the head and toe with a clamp at over / under HDR values
if memory serves.

>
> And I'll ask if there color chart footage, hopefully they have it :)

That would greatly give us an idea as to what he was exposing for. Entirely
possible he undershot to preserve highlights and was going to bring the
elements up during grading.

> Also as a sidenote, I found out a problem to solve for OpenColorIO usage:
>
> * For the spi-vfx and aces configurations in OpenColorIO, the scene
> linear to display sRGB transform is not invertible, it can only be
> applied in one direction. Seems quite silly that you can't pick a
> color and get it back exactly the same in a render.

The SPI sRGB LUT is a 3D LUT if I am not mistaken, so chromacities and non
linear is taken into account in the SPI workflow. dt16 and mp16
(spi-anim);are the input transforms used for textures and traditional matte
paintings IIRC.

> * The aces configuration does not define good color spaces for
> texture_paint/matte_paint/color_picking. The spi-vfx configuration

I would think sRGB would suffice for a few of those. ociobakelut can be
used to generate needs beyond that, such as from ICCs.

> does but its scene linear space seems quite different than aces from a
> quick test.

Indeed, it is. Mr. Selan explained that much of the SPI space and workflow
was generated in house. Not sure the primaries, white point, etc.

As we have seen, color spaces are not intended to be mixed and matched
without careful transforms in and out.

ACES was designed to eliminate much of the custom space needs. I suspect we
will see many houses and pipes adapt to it due to its versatility and depth.

With respect,
TJS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20120516/4b73452a/attachment.htm