ACES...

[Brendan Bolles]

Using a conversion from a given camera space to ACES, as a rendered transform, means taking a smaller colour space and placing it in a larger one, and if the bit depth remains the same that means reducing the image granularity, so reducing the image quality, and potentially making it harder to grade.

In theory you will certainly lose some data going from the camera's color space to ACES if the pixel format is unchanged. You're basically desaturating the data, and then increasing saturation later when you convert it back. Since ACES also involves converting to linear 16-bit float, it's not as obvious how the loss will take shape, but there would have to be a loss from 16-bit integer.

But on the other hand, I don't really believe that the RED or any other sensor can deliver 16-bits of meaningful data, even if that's what they give you in the raw file format. Also, the number of bits you claim to use is less important if you use a compression format that isn't lossless. The data rate becomes the important number, not the number of bits.

A good way to test this is to run out your 16-bit sources into 10-bit DPX or 8-bit TIFF/PNG. If you swap in the lower bit depth footage, is there any test you can do (like some sort of extreme color correction) that shows a difference between the 16-bit original and the lower bit replacement? If not, then I think those extra bits aren't really doing anything.

Another way to look at it is if you have visible noise (grain) that you can see on your 8-bit computer monitor, then surely the bits beyond 8 are just more noise. The need for higher bits is more evident for images where you would not have noise, like motion graphics or 3D renderers where the computer can create as many bits as it wants, not limited to what a CCD can do. Likewise, once you start processing the images, the computer might introduce data that you want to hold on to. I'm just talking about the source footage here.

[Gavin Greenwalt]

In theory you will certainly lose some data going from the camera's color space to ACES if the pixel format is unchanged. You're basically desaturating the data, and then increasing saturation later when you convert it back. Since ACES also involves converting to linear 16-bit float, it's not as obvious how the loss will take shape, but there would have to be a loss from 16-bit integer.

But on the other hand, I don't really believe that the RED or any other sensor can deliver 16-bits of meaningful data, even if that's what they give you in the raw file format. Also, the number of bits you claim to use is less important if you use a compression format that isn't lossless. The data rate becomes the important number, not the number of bits.

Well technically speaking the Half-Float (16 bit lin/float) file format supports 30 f-stops with 10bits (1024 steps) per stop precision. So that should be plennnnty of precision even if the image is desaturated. Considering we are used to working with Cineon (10 bits for 15+ stops of film scan) that's 30x more precision than normal film-based workflows which are pretty similar to the ACES workflow of LUTs.

I believe the OpenEXR/IIF formats are "16 bit linear" but the file encoding itself is actually in LOG space. So it would be like going from 16 bit linear to 16bit LOG and back to 16 bit linear with only a little bit of loss in upper stops like dpx/cineon.

[Gabriel Scindian]

I was going through an Autodesk Flame 2013 workflow presentation today and they said that ACES is becoming the standard format in holding the highest quality in color fidelity similar to OpenEXR but better. Does ACES handle R3D files any better than when this thread was first initiated?

[Graeme Nattress]

ACES as a colour space works just fine. RED files into that colour space just fine. AFAIK there's still rendering issues with the standard outputs as provided, but there's no reason why you can't roll your own and get something that looks fine. The other problem is that grading tools still don't really deal with linear light data all that well, being designed primarily for log or video encoded images.

Graeme

[M Most]

ACES as a colour space works just fine. RED files into that colour space just fine. AFAIK there's still rendering issues with the standard outputs as provided, but there's no reason why you can't roll your own and get something that looks fine. The other problem is that grading tools still don't really deal with linear light data all that well, being designed primarily for log or video encoded images.

Roll your own RRT/ODT?? Really? Unless you've got Alex Forsythe, Josh Pines, Jim Houston, and a few other people sitting next to you, I doubt it.

Regarding the linear light control systems, as far as I know among the current "major" players only Resolve (and possibly Colorfront, although I've never actually asked them) handles ACES in its native linear light form. As I recall, Baselight and a few others convert to a log ACES space to allow for better control matching and scaling. The log ACES approach is not directly endorsed by the AMPAS science council, but it's not been discouraged, either.

[Graeme Nattress]

Rolling you own isn't hard. The data linearity and primaries are specified, the ODT are standard colour space and gamma transforms. It's not some elitist thing that nobody can do.

Graeme

[Blair S. Paulsen]

Don't claim to know the intricacies of creating an ODT or all the nuances of log vs linear scales. That said, I have clearly seen different results from color pipelines that take linear values into log for manipulation using tools that seem optimized for log adjustments vs remaining linear throughout.

I look forward to full integration with ACES throughout the industry and applaud Jim, Graeme and the Red Team for their support of this potentially de-babelizing tech.

Cheers - #19

[Graeme Nattress]

Blair, for a simple example, "saturation" looks awfully different as applied to linear light as it does to log or video encoded images. Some image processing operations just don't work at all in linear light, just as some, like colour space transforms don't work when applied to non-linear data. For each and every image processing operation there's a preferred or necessary linearity of data. That said, linear light is un-ambiguously defined, so it's great for data transfer and colour space transforms. But it's not suitable for any and all general image processing including grading. So, the concept of ACES (or any other well defined colour space for that matter) in a linear light form, is very valid for data transfer with unambiguous intent. The visualization of that data is not something that is so well defined, because it's both data and human dependent, so that, to me, is right in the centre of where the "creative" needs to be, making the decisions as appropriate for the project.

Graeme

[Gabriel Scindian]

Graeme,

Thank you for the information you provided. I was working in Smoke 2013 and saw differences in color grading while testing results using R3D, EXR and DPX.

[Dr. Sassi]

So far I read always that the OpenEXR used here is "half float" only, 16bit/c, for the ACES.
(It has many stops, but a quarter of these stops are considered with a too large error amount)
In 3D/CG I never use it and I feel limited with it, I use 32bit/c float, precise with only 1% max error.

To my knowledge the half float saves out only 18 stops above the "gray-point".
This sounds enough as storage, but not really for a post-workflow, at least in "my world".

If Dragon keeps the HDRx option, this will be a limit from the start -- to stay inside 16bit/c float.
HDRx with the Dragon is a serious option for CG work, and I hope it stays alive.


Source:

http://www.openexr.com/TechnicalIntroduction.pdf

For a linear workflow the industry standard is NUKE (The Foundry), which works in 32bit/c float.