On Fri, Jul 3, 2015 at 10:04 PM, <[email protected]> wrote:
Hey guys,
I am trying to wrap my head around ACES.
I'm sure you're not the only one. I have heard that before... Here's
the basic idea:
First off, for anyone who hasn't thought much about color management
in general, why does it matter?
When you work with color in the computer it's just numbers, so we need
a way to define what color, in some absolute way, [1.0, 0.0, 0.0]
means.
What do you need to turn a [1.0, 0.0, 0.0] from Nuke into to see the
same color projected by a DCI compliant monitor as you see on your
workstation monitor? Or if you've got an sRGB JPEG and a REDcolor clip
does the value [1.0, 0.0, 0.0] mean the same color in the scene? (No!)
A colorspace specification like sRGB, rec709, AdobeRGB, and ACES
defines that. Which in turn makes it possible to transform color
values between one space and another.
There are two key parts to a colorspace: the colorimetry -- the
primaries & white point that specify the hue/shade intended by a color
value -- and the transfer function (or encoding), which specifies how
the increase/decrease of values is encoded -- log, some gamma, etc.
When you read an image into Nuke you might have noticed that the
(so-called) colorspace knob only defines the encoding. As a result,
there's sort of a built-in assumption that you are working in the same
colorimetry as your input images (and that they are all the same) and
all you need to specify is the transfer function to make them linear.
That was true (ish) when everything came from a film scanner and went
back out to a film printer. (err... well, let's not get into that.)
And we hack around it with Colorspace nodes.
Luckily, by the nature of digital capture devices, their colorimetry
is known (even if only to the manufacturer) so a translation to well
known spaces can also be defined. Then as a practical matter we just
need to pick a working space to transform different sources into for
processing and back out of for display/delivery.
In the past we knew what the "from" was based on file type, headers,
etc. (hopefully) but there was no well-defined standard "to" (though
it's essentially de facto been sRGB/rec709).
Enter ACES.
So, from what I understand ACES gives us on hand more gamut and on
the other hand it is a way to bring footage together from different
sources more easily.
That sounds good, right?! Ok, but I never used that kind of
workflow, and it does not seem to be that trivial.
I think you'll be surprised. Conceptually it actually isn't really
much more than what happens now in Nuke.
By default when you read an image in it goes through a process to
linearize it. When you write it out it goes through another process to
log or gamma it. If you're working in ACES that process just involves
more math to change the colorimetry in addition to the encoding. For
you as a user it's just more manual because of outdated assumptions
built into the Read/Write, and there are some gotchas to watch out
for.
Since the Read & Write only do a 1D LUT for colorspace, you need to
use OCIO nodes to do the input and output colorspace transform
instead. Which means setting the Read/Write colorspace knobs to
linear. But if you do this and you're converting to/from log with
OCIOColorSpace or OCIOLogConvert then the Write can't autodetect that
you're writing log and set the dpx headers correctly, so you need to
set the transfer knob manually.
In the Project Settings' OCIO tab, pick the ACES config and set the
viewer LUTs to use OCIO luts so you get the ACES conversion to
rec709/sRGB for display on screen.
Congratulations, you're working in ACES.
The scenario:
I've got R3D files which I push through hiero to generate openEXRs.
Problem I've got is I do not see an option to set the exrs for ACES,
like in REDCINE where I can specify that in the export settings. Ok,
comparing those two (redcine aces exr vs hiero exrs) the difference
is visible, most prominent the reds seem more pushed or saturated in
a non-aces exr.
If you've selected ACES for your OCIO config, then your inputs are
converting to ACES on read and the colorimetry of the output EXRs will
be ACES since there's no conversion when writing to EXR.
Now my questions:
When I process them as aces, I also need a display LUT so that I see
the right output, right? Is this provided with the OCIO Aces Config?
Have to take a look at that.
Yes.
What do I do with CG content? Do I apply a LUT in Maya, or even to
the render itself? Or do I treat it as usual and just transform the
color into ACES space? To what do I render? ACES or nonACES plate?
Do I treat CG simply as scene referred light?
You'll need to convert your textures from whatever space they're in
now to ACES, either by converting the files or setting something on
your texture reads, like you'd do to linearize them. I don't know
about others, but MODO supports OCIO so you can pick the ACES config
and then just make sure your texture inputs have the right colorspace
set. And of course view through the ACES sRGB or rec709 LUT so the
image gets translated properly for your display. Essentially the same
as in Nuke.
How do I export in Nuke exrs in aces? Simply set to linear and
everything is fine, or more magic sauce?
That should be it. One possible hitch -- I think the EXR writer
doesn't know that you're in ACES so won't write the metadata about
ACES. (Anybody know if that's still the case?) The files are EXRs just
fine of course but anyone else relying on that metadata to identify
them as ACES won't find it. Maybe someone's got a ModifyMetadata node
they could share that puts the right stuff in, to chain in before the
Write?
Hope this helped!
I am a bit confused, and any (non-technical as possible)
explanation, tip, link, whatever is highly appreciated.
Thanks in advance,
Igor
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
[1]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
[2]
Links:
------
[1] http://forums.thefoundry.co.uk/
[2] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
