As ACES ("standard") does not seem to be a good working space for
compositing/rendering and more of a storage colorspace, what are people
using as a working space?
I guess ACEScg is supposed to be used for this but is anyone actually
using it? What about Rec2020?
To be honest in most situations people tend to work in the native
colorspace of the camera and convert their elements/cgrender to that
colorspace (more or less accurate). However, ACES could potentially
really shine when using multiple sources from different cameras.
-------------------------------
Simon Björk
Compositor/TD
+46 (0)70-2859503
www.bjorkvisuals.com <http://www.bjorkvisuals.com>
2015-07-07 8:05 GMT+02:00 Matt Plec <[email protected]
<mailto:[email protected]>>:
Wow, things have come a long way since I last looked. Kudos to HP
and Alex and everyone else involved.
If you're wondering what the deal is with these different spaces
(ACEScc, ACESproxy, and ACEScg) have a look under "ENCODINGS AND
METRICS" here:
http://www.oscars.org/science-technology/aces/aces-documentation
Check it out even if you're not interested in the the math. Each one
has a short plain-English introduction explaining the what and why
for that space.
On Tue, Jul 7, 2015 at 12:15 AM, Jose Fernandez de Castro
<[email protected] <mailto:[email protected]>> wrote:
ACEScg is definitely what you would want to use. Using the whole
ACES color space in Nuke causes a lot of issues, specially when
going back to more narrow color space. ACES 1.0 should include
ACEScg, I think.
On Mon, Jul 6, 2015 at 11:08 AM, Michael Garrett
<[email protected] <mailto:[email protected]>> wrote:
Any comment on using ACEScg in Nuke, and why there is no
Rec709 rrt? From reading the ACEScg white paper, it does
seem there is just a matrix that can be used. Also I notice
OCIO ColorSpace has ACES to rrt Rec709.
On 6 July 2015 at 13:55, Deke Kincaid <[email protected]
<mailto:[email protected]>> wrote:
Just a note to add to Matt's post. Do not use the ACES
or IIF included with Nuke as it is 3 years old (ACES
v0.1.1). Get the ACES 1.0 OCIO profile off the Academy
site (it links to HP's current fork of the OCIO configs
on github).
http://www.oscars.org/science-technology/sci-tech-projects/aces#field-tabbed-content-tab-1
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?)
Nuke does not support writing the
"chromaticities" metadata at the moment and you can't
simply use a modifyMetadata to add it as it's not a
simple string. Also we do not yet support the ACESClip
sidecar file at this moment either.
--
Deke Kincaid
Media & Entertainment OEM Development Manager
The Foundry
Skype: dekekincaid
Tel: (310) 399 4555 <tel:%28310%29%20399%204555> -
Mobile: (310) 883 4313
Web: www.thefoundry.co.uk <http://www.thefoundry.co.uk/>
Email: [email protected] <mailto:[email protected]>
On Mon, Jul 6, 2015 at 1:27 AM,
<[email protected]
<mailto:[email protected]>> wrote:
Hey Matt,
I have to test some of those things and will get
back to you. Or hopefully not. :)
This is just a quick Thank You for your thorough
explanation.
Greets,
Igor
Am 05.07.2015 10:05, schrieb Matt Plec:
On Fri, Jul 3, 2015 at 10:04 PM,
<[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
--
Jose Fernandez de Castro
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
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
