well you could try with the free version just to see if it works. Randy S. Little http://www.rslittle.com/ http://www.imdb.com/name/nm2325729/
On Thu, Mar 6, 2014 at 4:41 PM, Frank Rueter <[email protected]> wrote: > I had tried that but that doesn't even get close. I'm guessing if Resolve > was set up with ACES it might be a promising, but since the colourist > doesn't want to go there, I can't even try to do the "right" thing. > > > > On 3/7/14, 10:15 AM, Alex Fry wrote: > > I'd be inclined to try aces-->slog using an OCIOcolorspace node as a > starting point. > > On 7 Mar 2014, at 8:01 am, Frank Rueter <[email protected]> wrote: > > Since I cannot get Resolve to match the ACES linear files from > RawViewer to the original mxf files (and the colourist refuses to set up > Resolve with ACES), my workflow now seems to become the following (not that > I am a fan, but it might have to do): > > -export a bunch of frames from the film (including a test chart) from > Resolve as log dpx > -export the same frames as ACES linear from RawViewer > -in Nuke, create a sequence for each (AppendClip or Switch node with > expression) > -use those two clips as inputs to the MatcGrade > -set a key frames on each frame, analyze and export a 3d lut. > > The resulting lut is applied to the output in Nuke just before rendering > log dpx files for final grading in Resolve. > This way I'm getting very close to making the VFX plates match the > original mxf raw files. It's not perfect, but probably good enough in my > case. > > Needless to say that I'd prefer a less empirical way, but this seems to be > the only workable solution so far. > > > Cheers and thanks again for all your help Alex! > frank > > > On 3/7/14, 6:22 AM, Alex Fry wrote: > > They would just be updating/improving their IDT. > > I've tried the current one, and it work's fundamentally as expected. > But like any sort of calibration exercise, you can always get closer to > the target with more time. > > > On Fri, Mar 7, 2014 at 4:05 AM, Randy Little <[email protected]>wrote: > >> I just saw that at NAB Sony is releasing an update to there ACES >> implementation as well as s-log3 for the f65. So Maybe they had something >> that wasn't quit right with their ACES implementation? >> >> Randy S. Little >> http://www.rslittle.com/ >> http://www.imdb.com/name/nm2325729/ >> >> >> >> >> On Thu, Mar 6, 2014 at 11:51 AM, Alex Fry <[email protected]> wrote: >> >>> The ACES values are scene linear. >>> >>> The difference with scene linear files you would have previously been >>> working with, is that whilst they would have been scene linear in their >>> intensity, but their primaries are effectively display referred (either >>> Rec709 primaries or P3). Because their gamut and whitepoint already match >>> your display device a simple 1D transform will give you a viewable result. >>> >>> ACES stores values using the much wider primaries shown below, they >>> are wide enough that they cover all of the visible colours in the horseshoe >>> of the spectral locus. >>> When you look at the Yxy diagram below, you have to remember that big >>> Y/brightness (the intensity of the pixel) is collapsed into the Z axis, so >>> you have to imagine it coming out of the screen towards you. >>> >>> The scene linear files you would have used in the past can only >>> represent colour within the green or blue triangles, ACES can represent >>> colours across the entire spectral locus (plus some imaginary colours >>> outside the horseshoe but within the ACES triangle). But the total sum >>> brightness, and its linearity relative to light levels in the scene remain >>> the same. >>> >>> I was under the impression that one of the main points of ACES is to >>>> use the linear light state as the common ground for all colour qworkflows >>> >>> >>> It is. >>> And part of that is divorcing the primaries from either the input device >>> or output device. >>> >>> [image: Inline image 1] >>> >>> >>> On Thu, Mar 6, 2014 at 10:19 AM, Frank Rueter <[email protected]>wrote: >>> >>>> Thanks. >>>> >>>> Using OCIO and RRT (sRGB) yields the expected result. I guess my >>>> confusion was/is with the fact that ACES linear does not produce the result >>>> I expected from scene referred linear data, and I was under the impression >>>> that one of the main points of ACES is to use the linear light state as the >>>> common ground for all colour qworkflows, as it should represent the light >>>> data captured on set irrelevant of input output signals. >>>> >>>> In other words, I would a have expected ACES linear to be a lot closer >>>> to the linear light images I have been working with over the years. >>>> >>>> It may just be a case of un-learning things to be able to understand >>>> this fully. >>>> >>>> Cheers, >>>> frank >>>> >>>> >>>> On 3/6/14, 8:17 AM, hxpro wrote: >>>> >>>>> >>>>> >>>>> On 03/03/2014 19:52, Frank Rueter wrote: >>>>> >>>>>> Actually, scratch that, ACES linear followed by rec709>linear in Nuke >>>>>> doesn't look like anything I see in RawViewer in terms of saturation. >>>>>> The gamma looks reasonable though. >>>>>> >>>>>> Any more hints? >>>>>> >>>>> >>>>> ACES uses very saturated primaries (in chromaticity terms), this means >>>>> that just performing a 1D colour space conversion will result in >>>>> desaturated looking images. You need to use something like the RRT+ODT to >>>>> convert to something 'filmic', or at least you need to map from the ACES >>>>> primaries into the rec709 primaries somehow. You'd need to be careful >>>>> doing >>>>> so due to gamut missmatches, which is where a lot of the challenges are. >>>>> >>>>> Kevin >>>>> >>>>> ---------- >>>>> This email and any attachments to it are confidential and are intended >>>>> solely for the use of the individual to whom it is addressed. Any >>>>> views or >>>>> opinions expressed are solely those of the author and do not >>>>> necessarily >>>>> represent those of Cinesite VFX Ltd. If you are not the intended >>>>> recipient >>>>> of this email, you must neither take any action based upon its >>>>> contents, >>>>> nor copy or show it to anyone. Please contact the sender if you believe >>>>> you have received this email in error. >>>>> Warning: The recipient should check this email and any attachments for >>>>> the >>>>> presence of viruses. Cinesite VFX Ltd accepts no liability for any >>>>> damage >>>>> caused by any virus transmitted via this email. >>>>> >>>>> Cinesite VFX Ltd. Registered Office: Medius House, 2 Sheraton Street, >>>>> London W1F 8BH. Company registration # 08492749 >>>>> ---------- >>>>> _______________________________________________ >>>>> 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 >> > > > > _______________________________________________ > Nuke-users mailing [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 [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
