OK, so further looking at the clips in the Color Tool, I see: Look Name = ARRI 709.aml Look Burned In = no Target Color Space = Rec 709
So I'm guessing the DP didn't do anything special. On Fri, Oct 28, 2016 at 12:37 PM, Gary Jaeger <g...@corestudio.com> wrote: > Great, thanks Joseph. Btw, Arri Meta Extract seems to generate the .aml > files, right? Or is the command line tool doing something different? > > On Fri, Oct 28, 2016 at 12:34 PM, Joseph Goldstone <jgoldst...@arri.com> > wrote: > >> >> On Oct 28, 2016, at 12:14 PM, Gary Jaeger <g...@corestudio.com> wrote: >> >> That’s great info, thanks Joseph. I’ll ask the DP if any in camera >> grading was done. And just so I’m clear, if they *were* done we could >> extract, convert and use in nuke, correct? >> >> >> You could, though at the present time, though the extraction can be done >> with a command-line tool, the conversion from ARRI 3D LUT format to a >> Nuke-ready format requires use of a GUI tool. Not so great if your DP used >> a different in-camera grade on 2,500 effects shots. But mostly we find that >> people develop a handful of looks in pre-production (“daylight exterior”, >> “daylight interior”, “evening exterior”, “evening interior”, “flashback”) >> and then select one of that menu of a handful for all the shots in a >> sequence. Or just use one for the entire production. >> >> >> And is that where we’d load the 3D LUT into an ocio file transform >> downstream of the read but ahead of any FX work? >> >> >> I wouldn’t think that you would be using the LUT until after you’d added >> the VFX: >> >> 1. File comes in LogC. >> 2. You extract the .aml with the command-line tool and use the GUI >> tool to convert it to, say, IRIDAS .cube. >> 3. Read the LogC file in and linearize to your working space (e.g. if >> you are using ACES, linearize the LogC to ACEScg using the LogC IDT) >> 4. bring in your dinosaur from your dinosaur’s encoding space to the >> working space, and comp in working space >> 5. transform the comp from working space to LogC (inverse of (3) >> above). >> 6. apply .cube file from (2) via OCIO FileTransform to get >> displayable values. >> >> I don’t want to give you specific parameter settings since I’m using a >> prototype ACES 1.0.3 OCIO config and am using Nuke 10.0v4. I think the >> earliest Nuke 10.0 + ACES OCIO config support may have had some issues >> (though HPD is the authority on this) and anyway, researchers shouldn’t >> tell production people what to do. (And indeed you may not be working in >> ACES at all, and I’ve totally forgotten what Nuke is like pre-ACES, which >> is why 1-6 above are a bit vague.) >> >> Best— >> —joseph >> >> >> *Gary Jaeger */ 650.728.7957 direct / 415.518.1419 mobile >> http://corestudio.com >> >> On Oct 28, 2016, at 11:58 AM, Joseph Goldstone <jgoldst...@arri.com> >> wrote: >> >> The LogC is the same, and you can use a “standard LogC to Rec709 LUT” >> from the ARRI website to match the traditional ALEXA look. >> >> Perhaps that’s enough of an answer for you right now. But for those of >> you that are interested in the general question of LogC from the AMIRA… >> >> …there is a much more flexible color processing architecture built into >> the AMIRA, the ALEXA MINI and the ALEXA SXT. In the AMIRA, the user has the >> option of either extensively tweaking the standard processing, or loading >> in a 3D LUT generated in another package (say, Resolve of Baselight) and >> this 3D LUT will be carried in the .mov file as metadata. ASC CDL is also >> applied differently to LogC data for those more recent cameras — bowing to >> Hollywood tradition, on the AMIRA, MINI and SXT it’s the LogC data that >> gets modified by the ASC CDL values, not the display-ready video values (as >> is the case with older ALEXA models). >> >> There is not currently a command-line tool to extract these 3D LUTs >> directly in a form that Nuke understands. There is a command to extract the >> 3D LUT as a .aml file, and there is a GUI tool (the ARRI Color Tool) that >> can be used to convert the .aml file into a variety of 3D LUT formats that >> Nuke understands, but it’s not scriptable. >> >> To download the ARRI Color Tool, or to read more about it, you can look >> here: >> http://www.arri.com/camera/alexa/tools/arri_color_tool/ >> >> To learn more about metadata extraction (including pulling out the look >> file) you can look here: >> http://www.arri.com/camera/alexa/tools/arri_meta_extract/ >> >> I haven’t seen many features use this flexibility to date; many of them >> are grading downstream and as Michael points out, LogC is LogC wherever. >> But as you are on an AMIRA show, you should probably check to see if any >> in-camera grading was done or any custom looks were loaded. >> >> Best— >> —joseph >> >> On Oct 28, 2016, at 10:46 AM, Michael Garrett <michaeld...@gmail.com> >> wrote: >> >> Hey Gary, >> >> Amira LogC is the same isn't it? It's possible Premiere is applying a >> LogC to Rec709 LUT to roll the highlights off and get it looking >> presentable. I would imagine from what you're saying that the footage looks >> blown out in Nuke because it's not doing the additional s-curve in the >> above LUT to get a reasonable image. Check out the Arri web site to >> download a LogC to Rec709 LUT. >> >> Cheers, >> Michael >> >> On 28 October 2016 at 13:02, Gary Jaeger <g...@corestudio.com> wrote: >> >>> I have a question about LogC as well. Do we need a different LUT to work >>> with Amira LogC footage? I’m pretty sure the camera tags the clips, and for >>> instance Premiere reads that and displays the footage with that lut so the >>> editor (and client) see something reasonable i.e. not flat LogC like it is >>> looking at the raw clips. But Nuke displays the footage quite blown out. I >>> know the data is there, but is the AlexaV3LogC not the right transform? >>> >>> >>> *Gary Jaeger */ 650.728.7957 direct / 415.518.1419 mobile >>> http://corestudio.com >>> >>> On Oct 26, 2016, at 7:07 AM, Stepan Z <motionarti...@gmail.com> wrote: >>> >>> Hello i didn't think about the bitrate! Thank you Andrew! I'll read >>> about the compare node! >>> >>> All the best >>> >>> Stepan >>> >>> >>> >>> >>> On 25 Oct 2016, at 22:19, Andrew Mumford <a_mumf...@mac.com> wrote: >>> >>> Are your dpx's 10 bit ? - That would make it different for sure ! >>> >>> There's also a "hidden" but wonderful node called"Compare" that is great >>> for checking these things - gives you a visual and error based output. >>> >>> --- >>> Andrew Mumford >>> >>> >>> On Oct 25, 2016, at 09:56 AM, Stepan Z <motionarti...@gmail.com> wrote: >>> >>> Hello >>> >>> I'm using nuke studio to conform a few short edits, publish a source dpx >>> sequence and a nuke script. >>> >>> So i'm bringing in original alexa logc encoded prores files, and >>> publishing dpx sequence with logC set as the colorspace in the export >>> dialog. When i then bring over that dpx sequence back into NS and drop it >>> on top of the prores and disable all colour transforms (viewer to none >>> instead of sRGB and the per file transform to linear) perceptually the >>> files look identical. But when you sample a pixel or an area with the >>> viewer the rgb values after two decimal places seem to change when your >>> flicking between dpx and prores. >>> >>> Is this normal and is just the difference in encodings or should they be >>> exactly the same given that they come from the same file and are in the >>> same colourspace? >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, https://protect-us.mime >> cast.com/s/arGYBbiNp60UG?domain=forums.thefoundry.co.uk >> <http://forums.thefoundry.co.uk/> >> https://protect-us.mimecast.com/s/27lmBXIbrzlTx?domain=suppo >> rt.thefoundry.co.uk >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> >> >> ------------------------------ >> This email has been scanned for email related threats and delivered >> safely by Mimecast. >> For more information please visit http://www.mimecast.com >> ------------------------------ >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, https://protect-us.mimecast.co >> m/s/K2R4BwcEbNOc1?domain=forums.thefoundry.co.uk >> <http://forums.thefoundry.co.uk/> >> https://protect-us.mimecast.com/s/enY4BbCGbV7ik?domain=suppo >> rt.thefoundry.co.uk >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> >> >> ------------------------------ >> This email has been scanned for email related threats and delivered >> safely by Mimecast. >> For more information please visit http://www.mimecast.com >> ------------------------------ >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > > -- > Gary Jaeger // Core Studio > 249 Princeton Avenue > Half Moon Bay, CA 94019 > 650.728.7957 (direct) • 650.728.7060 (main) > http://corestudio.com > -- Gary Jaeger // Core Studio 249 Princeton Avenue Half Moon Bay, CA 94019 650.728.7957 (direct) • 650.728.7060 (main) http://corestudio.com
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
