Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

ACES...

Steve Shaw said:
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.
Click to expand...

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.
 
Brendan Bolles said:
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.
Click to expand...

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.
 
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?
 
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
 
Graeme Nattress said:
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.
Click to expand...

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.
 
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
 
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
 
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
 
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.
 
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.
 
Last edited:
There's a difference between working precision and storage precision. 16-bits per channel for storage offers an awful lot of precision. When you are doing math on that data, doing it in 32-bit is the defacto standard for almost every compositing/coloring/finishing system, but you don't need to store that much precision. There is no camera out there that can natively fill even a full 16-bits with meaningful data (as far as I know), so there's no sense in using that huge of a bucket (32-bits) for storage. The benefits of doing math in 32-bit are that you can preserve source precision throughout your various transformations. In other words, if you take 16-bit (or 10 or 12) log in, transform to linear in 32-bits, do a color space conversion, transform back to log, and output 16-bits, the process is effectively lossless in regards to precision. You could reverse the process and end up with the same thing you started with. But if you did your transformations in 16-bits, you could lose precision (still probably negligible when your meaningful source data is really only taking up maybe 12 of the 16 bits, but there's no reason to introduce the possibility of degradation if you dont need to).

Remember, 10-bit dpx files have been the standard for a long time. Going to 16-bits is a huge jump both in precision and in storage space. 32-bits is another exponential leap for file size, and would not be easily accepted by people paying the storage bills...
 
Eric, If you store a file with a certain amount of treatment, perhaps something similar (extreme) to a 3.0 ND filter, most formats fall short to get this data back as it was. (Especially the ".hdr/radiance" format, it show heavy banding then, which is only a 8bit/c pseudo float, but often confused as 32bit/c, and it is only 32bit/pixel. There is a lot of confusion in the world and I'm not sold on the concept "it has worked in the past", sorry). I'm not a fan for anything less than 32bit/c float, except it is raw of course. Integer bits and float bits are complete different systems, and integer with a "kind of mapping" like DPX is another story.

I think DPX, 10 bit/c integer based (there are many DPX options), had some flaws, if you look how the data is stored above LOG 2.0, not nice at all from my point of view. DPX, as I understood it, was a delivery format to e.g., Technicolor, but not to a Post house like Digital Domain, if you have 32bit/c float already.

Anyway, my point: We certainly need to make sure that the complete workflow is covered in ACES and not just camera data. If that is the point, camera only or storage only is the focus, then I'm not a fan of the ACES. This is perhaps not really a focus of REDuser either, so I try to keep it short here.



However, I got your point, and certainly in most cases 16bit/c float for camera data will be fine, I do not argue that. :o) Except if RED catches even more DR in the future ;o) ...we will see, I do not think they stop with DRAGON.

Just to get not lost in a format discussion, your point with 16 vs 32 is valid and certainly fits most cases in the camera world with no problem. Storage vs Processing needs to be differentiated as well. So, back to ACES as system :o) Thanks for your perspective to it.
 
Last edited:
Dr. Sassi said:
So far I read always that the OpenEXR used here is "half float" only, 16bit/c, for the ACES ...
In 3D/CG I never use it and I feel limited with it, I use 32bit/c float, precise with only 1% max error ...
This sounds enough as storage, but not really for a post-workflow, at least in "my world" ...
For a linear workflow the industry standard is NUKE (The Foundry), which works in 32bit/c float.
Click to expand...
+1 on Nuke and linear 32 bit(that's what i was "forced" to use after I did comparitive tests on 16bit and non-linear workflows). This is especially important for my monochrome workflow. You would think that monochrome was less sophisticated processing then color ... but with monochrome all you have is dynamic range - and if you mess that the composite doesn't work. For Puddles of Light, it's heavy vfx and also b/w ... so everything the Dr says is even more important, or the composite goes toes up.
 
Thanks Patrick. Very nice point with monochrome, especially when it is noise free. Then banding problems show up more frequently. Even if I work monochrome from time to time (stills panoramas only -- though), it was not so much in my "focus" here, but YES, you are spot on.

Yes +1 for NUKE :o)
 
I still think that ACES in its current form introduces artifacts.

Jim
 
Jannard said:
I still think that ACES in its current form introduces artifacts.

Jim
Click to expand...

I agree. It strongly depends on how the color space conversions are actually implemented and at which bit depths these are performed.

We went through all this by implementing FinalDCP color space conversions in the past. To get especially a banding free result you need to implement the underlying math at way more bits than you have for input and output, otherwise you will see unnecessary banding. One has to very carefully test the entire workflow to make sure no such artefacts are being introduced in any step.

However, the basic concept is a good idea. I just think that ACES is selling it "way to complicated". While the underlying ideas and principles are simple, the way they are named and explained seems to confuse many people and integrators. Seems like making a "myst" out of nothing. Probably a "selling point" for some. It could be sooo simple...
 
Jannard said:
I still think that ACES in its current form introduces artifacts.

Jim
Click to expand...

The current RRT has some issues in that regard, in part due to using a combination of transforms to achieve a generally agreed upon result, and in part due to the fact that the "generally agreed upon result" is and has been in a state of flux. The IDT's are straightforward and clean, and the ODT's are not really an issue either.

I think even those most deeply involved in ACES development would tell you it's still a work in progress. That doesn't make it unusable in particular situations, but it does have some quirks and it does impart a "look" of its own. I think it's also fair to say that some camera manufacturers (OK, Sony in particular) have embraced it a bit more than others and optimized their color processing to accommodate it. Others, like Red and Arri, have thus far preferred to use their own approaches because they feel it currently yields a better and more flexible result. This is usually born out in real life use. I was involved in a series this season that was shot on Sony equipment (F65) and on which we used ACES processing, which worked quite well. On the other hand, I was somewhat involved in a pilot last season that was shot on Alexa and we used ACES processing via Resolve, which was, well, somewhat limiting.
 
Yes, the IDT and ODT are just pure math. There's no real art in them, and they're both simple and accurate. It's the RRT that's problematic, and to me, that's the area where the creatives on a project should be taking control first and foremost, and it's not something should even be attempted to be "standardized".

Graeme
 
With 16bit float there are for sure problems in the "blacks" (see David Mullen ASC in the Roger Deakins thread http://www.rogerdeakins.com/forum2/viewtopic.php?f=2&t=1990&start=15 .

The beauty of RED raw, is I can do the ambient lighting for performance capture in the "blacks", then run the "normal" lights ... and when I shoot I am capturing both the ambient and vector lights in the same frame (i.e. like the Weta ambient lighting approach, but using that for 5k performance capture). Thus in one red raw frame, i am able to have "deep" blacks where i can do full tracking while also in that same r3d have the actual picture of what people will see. With 16 bit float I loose the information to do tracking in the blacks.

The smart bet that I am finding for digital cinema(digital cinema being different then relics trying to move film/tape processes to digital) is red raw in nuke, with openexr/alembic between the vfx layers. It would be nice btw to have the new red cinema format as a container option inside openexr though ;)
 
You must log in or register to reply here.
Back
Top