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 list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
