I have yet to work on shows that use ACEScg, but I have worked on
shows that 'tried' to use the 'original' ACES, and it was a pain. The
problem is that, at the end of the day, the delivery colorspace is
always a more narrow gamut, and you are constantly fighting and QCing
to avoid going into negatives, getting strange color artifacts, and
weird saturation values. ACEScg, given its more constricted gamut,
should bridge the gap much better, while still achieving the goals
that ACES sets out to achieve. In my opinion ACEScg should definitely
be the default over full ACES in nuke, given that ACES wasn't really
designed for compositing/grading workflows, and ACEScg and cc are
proposed with those tasks in mind.
On Tue, Jul 7, 2015 at 2:21 AM, Jack Binks <[email protected]
<mailto:[email protected]>> wrote:
This relates to a discussion ongoing with the ACES guys as to the
choice of default working space for an OCIO ACES 1.0 config -
whether ACEScg or original ACES. If anyone feels strongly on the
matter, particularly if you think original, drop me a line with
reasoning.
Cheers
Jack
On 7 July 2015 at 08:35, Simon Björk <[email protected]
<mailto:[email protected]>> wrote:
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 <tel:%2B46%20%280%2970-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]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
--
Jack Binks, Product Manager
The Foundry Visionmongers
5 Golden Square, London, W1F 9HT, UK
Tel: +44 (0)20 7479 4350
Web: www.thefoundry.co.uk <http://www.thefoundry.co.uk/>
The Foundry Visionmongers Ltd.
Registered in England and Wales No: 4642027
_______________________________________________
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], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
