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]> 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]> 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 - Mobile: (310) 883 4313 >> Web: www.thefoundry.co.uk >> Email: [email protected] >> >> On Mon, Jul 6, 2015 at 1:27 AM, <[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]> 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 >>>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [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 >> > > > _______________________________________________ > Nuke-users mailing list > [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
