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
