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?
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? Gary Jaeger / 650.728.7957 direct / 415.518.1419 mobile http://corestudio.com <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/ > <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/ > <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 >> <mailto: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 >> <mailto: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 <tel:650.728.7957> direct / 415.518.1419 >> <tel:415.518.1419> mobile >> http://corestudio.com <http://corestudio.com/> >> >>> On Oct 26, 2016, at 7:07 AM, Stepan Z <motionarti...@gmail.com >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>>> <mailto:Nuke-users@support.thefoundry.co.uk>, >>>>> http://forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> Nuke-users@support.thefoundry.co.uk >>>> <mailto:Nuke-users@support.thefoundry.co.uk>, >>>> http://forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users>_______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk >>> <mailto:Nuke-users@support.thefoundry.co.uk>, >>> http://forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk >> <mailto:Nuke-users@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk >> <mailto:Nuke-users@support.thefoundry.co.uk>, >> https://protect-us.mimecast.com/s/arGYBbiNp60UG?domain=forums.thefoundry.co.uk >> <http://forums.thefoundry.co.uk/> >> https://protect-us.mimecast.com/s/27lmBXIbrzlTx?domain=support.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 > <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, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
