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...

And when "it gets there", the link between the original intent and post is still a rather nebulous one. Not an issue for me, since I am happy to spend untold amounts of time excavating my own images. However, for the pro post houses and industry at large... Will Raw gain in popularity ???
 
exactly, graeme.

i think most of us are on the same page about this... so, not sure where the tension was coming from. maybe there's some politics or vested interests i'm unaware of...
 
Neutrality

Neutrality

When designing workflows one of the first questions is what is the "hero deliverable". Once established, that target influences a plethora of choices made along the way both creative and technical. In theory, the ACES benchmark color space makes it practical to create a "neutral" master that can be processed optimally for each target deliverable.

Any specific attributes of the various transforms that impart a "signature" look is not only a potential issue in achieving a specific creative intent on a given project, but also kills one of the core benefits of the whole program.

Cheers - #19
 
When you record an image onto film negative, the recordation is not neutral.

When you print that negative onto a release stock, that recordation is not neutral,
nor is the resulting optical presentation.

However, it is very beneficial to have a Digital Intermediate (ACES etc.) that is neutral for all the obvious reasons.

I assume that ACES is not neutral because they wish to emulate a film look which has never been neutral in the first place.

Also, If you have a neutral Intermediate starting point you can go almost anywhere you like esthetically,
but if you start with a look you cannot necessarily get back to neutral or achieve the esthetic you desire.

So in the end, NEUTRAL will be King.
 
Right and it's important to emphasize that Neutral doesn't mean you can't get back to a chosen aesthetic. A LUT can bring you from Linear Neutral to RedGamma3 for instance. If you had Alexa footage in linear and red footage in linear you could push both to RED's aesthetic or Alexa's aesthetic depending on your preference. I can see how this might be threatening to camera manufacturers as they lose a bit of their magic sauce. How happy would Arri be if RED perfectly cloned Alexa's color and gamma? How happy would Kodak be if RED released a perfect Vision 3 emulation. Right now you can do that when you start from a predictable start "REDLogFilm/REDColor3 3500k -> Kodak 5217 LUT". But with ACES that'll free up software developers to simply write "ACES -> Kodak 5217 LUT" and then every camera will be automatically supported.

So even if you don't want "neutral" to be your grading starting point a common neutral reference point is still useful since it'll be far easier to choose any starting point. Like shooting RED cameras but Alexa's color? RED -> ACES -> ALEXA LUT -> Grade. It will be great once the hardware evolves a bit and the standard matures to buy a camera based on empirical quality not subjective look.
 
Blair S. Paulsen said:
In theory, the ACES benchmark color space makes it practical to create a "neutral" master that can be processed optimally for each target deliverable.
Click to expand...

That is indeed the theory. The problem is that there's no ACES display, only various real world displays with some "translation". No display can show all the colours and range that you can store in an ACES file, hence the rendering needs to do the best job it can. So yes, issues here are indeed troublesome...

Graeme
 
Martin, "neutral" is vital for oh-so-many reasons. The lack of neutrality creeps in when you try to render this wide gamut / range space to a real-world display. Creative decisions are made in that process that currently dictate quite a strong rendering intent.

Gavin, you clearly seem to see some of the many issues. The IDT concept does just as you describe - maps all cameras to a standard colour space and linearity. This is the best bit of ACES - a wide gamut, wide range defined colour space! This issues all seem to be on the "and how do I grade / display" such an image side of things.

Graeme
 
If it's of any help we have added ACES support to the latest version of LightSpace, so you can generate LUTs for each step in the ACES workflow - for use in any creative system.This helps understand what is happening, and how the image is effected.

But, I agree with Jim - ACES is actually not ideal for any grading workflow - it's better suited to VFX operations.
 
Steve - I don't see how it can be better for VFX if it's not suitable for grading as VFX need grading too. Linear Light EXR is great for VFX and with a standard log mapping, good for grading too. I guess you could always transform the primaries of an ACES EXR back to whatever you're grading in, and put the log back on, but then what are you using from ACES workflow other than linear light EXR?

Graeme
 
steve... for the same reasons it's not ready for coloring, it's not ready for vfx. there's really not much difference between compositing and color grading

a workflow that handles both exactly the same way is bound for success. not saying you can't do r3d's and exr's just for vfx - but that clearly adds a level of complication and you just need to know what you're doing. it can be a really good option in that case - but it's not for everyone/thing.
 
Steve Shaw said:
But, I agree with Jim - ACES is actually not ideal for any grading workflow - it's better suited to VFX operations.
Click to expand...

If you apply gain in Log gamma vs linear gamma you'll indeed get two radically different results. But that's just because the *software* generally expects log input. You could in a couple minutes rewrite your gain operator to apply a "Lin to Log" -> Gain -> "Log to Lin" operator. Presto your gain will work exactly the same. This is how Nuke works with transparency. It used to be that you had to put an "Unpremultiply Alpha" node before grading anything with a transparency, but if you just check the "Unpremultiply" it'll do that all internally. Whether you apply a color operator in linear space or Log space should vary from operator to operator. I personally think the photoshop curves tool works best in log space. But I think linear gain is best. Now application developers can either expose that to the user or decide for them but they'll at least *know* that the operations are being "correctly" applied to the image. Nuke for example now has Linear Merge and sRGB Merge. Both produce very different results but all within the context of a 32 bit application that assumes everything is linear.

How you get files into your grading or compositing application is completely independent of how that application manipulates the color. At straightface everything goes to linear gamma. When we send back plates it should look exactly the same as how it was sent to us + manipulation. But it's the wild west out there. We'll get a LOG film scan from the production company. We'll work with the footage and then as the last step convert it back to LOG for sending to a post house who will then call up and ask "Why is the footage so low contrast?" at which point we'll try and explain to them that it's LOG. If everything is in a universal gamma/colorspace then we don't have to tell them what the image is, it should just open in their application exactly as we saved it out. That's not just good for VFX that's good for everybody. You get an ACES file from production, you apply your VFX, you send out an ACES to grading who maybe converts it to LOG for the grade but then de-LOGs it for sending as ACES to the theaters and as ACES to the film-out company and as ACES to the DVD mastering company and everybody when they open the footage should see the same image. You don't have to have a human being necessarily following the footage ensuring everybody is opening it correctly.
 
I totally agree, Gavin, and I think it would be good to have a reliable standard. However, the deeper problem is education. Given, some of this stuff is extremely complex. The guys smart enough to actually understand it tend to be hard to communicate with and are easily frustrated by their comparatively high intelligence levels. As you mentioned... most applications have hidden this stuff deep in the preferences or hide it all together and require elaborate workarounds. There are plenty of people in the post industry that have never even thought about colorspace, gamma, etc etc. I'm not saying everyone should be burdened with such stuff - I tend to think it's nice to get on with it and be creative - I'd much rather not worry about that stuff whatsoever. That's why a well-developed standard is a great idea.
 
Ian Vertovec said:
Hey Bruce,

We do things very much the same as yourself. REDlogfilm DPX with P3 primaries mostly.
Click to expand...


Hi Ian ,
when you say """DPX with P3 Primaries """ what do you mean ?
that you process DPX (from R3D ) applying a P3 Colorspace matrix ?how?

i thought that the primaries of a DPX fro an R3D depends on what color matrix (red color 1-2-3) is chosen..

thanks
g
 
Gavin Greenwalt said:
Whether you apply a color operator in linear space or Log space should vary from operator to operator. I personally think the photoshop curves tool works best in log space. But I think linear gain is best. Now application developers can either expose that to the user or decide for them but they'll at least *know* that the operations are being "correctly" applied to the image.
Click to expand...
I know of a major A-list colorist on the West side who routinely does all his color-correction with linear controls. And we're talking $100 million+ budget films.

All of it can work, provided the projector display LUTs are accurate, and you can absolutely guarantee the film-out (and/or the conversion to XYZ colorspace for DCP). Josh Pines of Technicolor had some interesting things to say about ACES a year or so ago:

http://www.fxguide.com/featured/the-art-of-digital-color/
 
Gabriele Turchi said:
Hi Ian ,
when you say """DPX with P3 Primaries """ what do you mean ?
that you process DPX (from R3D ) applying a P3 Colorspace matrix ?how?

i thought that the primaries of a DPX fro an R3D depends on what color matrix (red color 1-2-3) is chosen..

thanks
g
Click to expand...

We use the RED SDK to debayer everything as RLF and RC2 or RC3. Then the files are then converted to a dci white point, in logspace.
 
Ian Vertovec said:
We use the RED SDK to debayer everything as RLF and RC2 or RC3. Then the files are then converted to a dci white point, in logspace.
Click to expand...

thanks ian ,
beofore ingenst in pablo ?

do you mind if i ask how you apply that conversion (i guess you have a transformation Lut ) , but also : what i sthe advantage of having DPX with P3 primaries (considering that the R3D has been deabyered using red color 2/3 matrix ...)

thanks

g
 
I've been thinking about this, and I still think the problem really has to lie with how images are being converted to/from ACES, not with the ACES standard itself. Just because ACES stores images a certain way shouldn't impact your ability to create any image you want. So let me ask: how are people creating ACES images and how are they viewing them? And where does it all go wrong?

For example, I exported an EXR sequence from REDCINE-X with the "Use ACES" box checked. When I open one of these files in After Effects, it looks very de-saturated. This is not surprising because the file doesn't include the standard EXR color information (like it probably should) to tell AE it's using the ACES primaries, so AE assumes the sRGB primaries. If I assign an ACES ICC profile to the footage, it looks saturated again.

Of course, in this case After Effects is just converting back to sRGB and then showing the pixels on screen and not doing any of the ACES RRT stuff which would further alter the appearance. If you were going to do the RRT at the end, then in REDCINE-X you would want to apply an inverse-RRT so that you get the same image when you view the ACES as when you initially graded it. I'm told this inverse-RRT should be available at some point if it isn't now. It's definitely not present in REDCINE-X.
 
Ian Vertovec said:
We use the RED SDK to debayer everything as RLF and RC2 or RC3. Then the files are then converted to a dci white point, in logspace.
Click to expand...

very sorry if i ask again , but i am interested on this topic about converting images to P3 primaries before the DI
so :

thanks ian ,
beofore ingenst in pablo ?

do you mind if i ask how you apply that conversion (i guess you have a transformation Lut ) , but also : what i the advantage of having DPX with P3 primaries (considering that the R3D has been deabyered using red color 2/3 matrix ...) vs using "simple" DPX RLF RC3 from RCX ?

thanks a lot

g
 
A very quick comment here...

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.

Just be aware when looking at rendered workflows, rather than non-destructive ones.
 
You must log in or register to reply here.
Back
Top