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]> 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 > www.bjorkvisuals.com > > 2015-07-07 8:05 GMT+02:00 Matt Plec <[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]> 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]> >>> 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 >>> >> >> >> _______________________________________________ >> 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 > -- 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 The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
