as far as I know the nuke color correction tool is only based on CDL. (I'm actually not sure we have issue w/ CDL havn't tried this one for a long time. ) But a great thing about nuke is that each of component (SMH) got it's own three-way. which give you a much higher precision in each of those space http://www.pasteall.org/pic/4620. I believe that would be easy to reproduce if each color wheel was inputs as well.
As Stu said, LGG is a tweaked formula. it does make it easy to control color correction other your image as soon as it is in non-linear. so we can do two things : - recommend to people in documentation to do the same setup that Sebastian did each time there are in CM mode. (because there wouldn't be any point to de-linearize the input for other node that this one ... I guess...) - or do the gamma operation in case of CM in the CB node. but somehow I think that's almost what did Campbell, didn't he ? Also about the nuke part, I think some of the color correction node are in the NDK (aka SDK) I totally agree about the LUT stuff, but last time I checked with Matt it wasn't plan anytime soon. I'm just talking about a work around for now. François 2010/7/20 <[email protected]> > > Date: Tue, 20 Jul 2010 15:45:25 -0300 > From: Xavier Thomas <[email protected]> > Subject: Re: [Bf-committers] Color Balance & Color wheel issue > To: bf-blender developers <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > My suggestion here is to use a more flexible color management > workflow: Have some predefined LUTs for gamma correction (sRGB, linear > (no change), log, ...) and for each image, node input or sequencer > strip we should have the ability to set the color space. So the user > can tel the image is in linear color space even if it is not and there > will be no conversion. Of course having the ability to add/customize > the LUTs and to automatically set 8bit image to sRGB and float to > linear would be even better. And even better would be to merge this > with the swscale operation that already does color-space > transformation (YcbCr to RGB with gamma correction) for most movie > files. Also the image viewer and scopes should have their own LUTs > too. > > I spoke of this once with Matt and we decided to take some time to > make a design proposal together after the feature freeze and when he > will have time. > > I remember he wasn't really happy with the 32bit float support of the > open-sources CMS but lcms2 got released soon after his tests and seems > to correct that issue. > > Also using a CMS for mostly doing gamma correction seems a little > overkill but lcms is really light and maybe could allow to use custom > color profiles in the future. > > Back on the Lift gamma gain issue I think it is better to assume that > every images/buffers in the compositor are in linear color-space and > there must be a way to use some logarithmic mapping that works well > for the UI controls. Personally I like when the numerical value input > correspond to the real mathematical value underneath, so I can set my > black/white level easily by using the color picker and copying > directly the values in the lift/gain UI controls but I suppose artists > works differently then engineer on this one. > > It also might be good to take inspiration of the grade tool in nuke > which is awesome and works in linear color-space. > > > Xavier > > 2010/7/20 Fran?ois T. <[email protected]>: > > Hi, > > > > FYI here is what I asked to Stu Maschwitz (colorista guy) on twitter : > > > > "- @5tu <http://twitter.com/5tu> is there a reason why Lift in colorista > is > > crunching pretty fast w/ linear enable in AE ? > > - @francoisgfx Yes, lift will crunch hard in linear. Colorista is > designed > > to work on gamma-encoded images." > > > > As Sebastian K?nig point out on twitter through this screenshot ( > > https://dl-web.dropbox.com/s/ex9ec02gnil4vz0/color-management-woes.jpg), > > when gamma corrected the Color Balance behave correctly. Which make since > > since Stu says L/G/G is design to work in non-linear space and that > > Sebastian operation in CM mode bring the input back to non-linear. > > > > The question is shouldn't we do gamma correction in CB node in case CM is > > active ? I'm not sure what repercussion it could have on inputs and > stuff. > > The idea would be to reproduce the setup Sebastian did directly in the > code > > in case of CM otherwise leave it as it is. > > Maybe that's what your modification does Campbell because I'm not sure > > Sebastian where using the last build, but I still don't have the same > value > > in both case (CM & not CM). > > > > > > Cheers, > > > > > > Fran?ois, > > > > > > > > 2010/7/20 <[email protected]> > > > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Mon, 19 Jul 2010 21:45:11 +0200 > >> From: Fran?ois T. <[email protected]> > >> Subject: [Bf-committers] Color Balance & Color wheel issue > >> To: [email protected] > >> Message-ID: > >> ? ? ? ?<[email protected]> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hey guys, > >> > >> I've been trying to play with Color Balance since the new changes, but I > >> believe a few things are acting weird (or at least differently than > Magic > >> Bullet Looks (MBL), and as I read it is supposed to behave more likely. > >> Also > >> a few issues with the Color wheel. > >> > >> > >> First of all the Color Wheel : > >> - it is really jerky (not smooth) > >> - the brightness sidebar is affected (doesn't do that in MBL) > >> - brightness only go up to 2 (I believe MBL is 10) > >> - cubic color selection is something good, but since the second > >> modification > >> to it, it does feel less natural > >> - releasing the color wheel do not move the mouse to the new position, > >> which > >> make fine tuning from this release point very hard > >> > >> but I must say the finest selection with SHIFT is awesome :) > >> > >> > >> for the Color Balance part, I don't quite understand what as been > change? I > >> did some test before with the exact same value on both side (AE MBL & > >> Blender's Color Balance) and I had the exact same result. As far as I > was > >> setting both with the same Color space environment (linear or > non-linear). > >> I didn't push the test as far as before, but it doesn't feel the same, I > >> can't quite understand what it is yet but it's feeling funny. Am I the > only > >> one having this sensation ? > >> > >> > >> cheers > >> > >> > >> > >> -- > >> ____________________ > >> Fran?ois Tarlier > >> www.francois-tarlier.com > >> www.linkedin.com/in/francoistarlier > >> > >> > >> > > > > > > -- > > ____________________ > > Fran?ois Tarlier > > www.francois-tarlier.com > > www.linkedin.com/in/francoistarlier > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > ------------------------------ > > Message: 7 > Date: Tue, 20 Jul 2010 22:26:45 +0200 > From: Damien Plisson <[email protected]> > Subject: Re: [Bf-committers] Blender 2.53 beta AHOY! > To: bf-blender developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=iso-8859-1 > > All three OSX builds are on the ftp server. > Builds were made with svn # 30554 > > Damien > > Le 20 juil. 2010 ? 20:19, Ton Roosendaal a ?crit : > > > Hi all, > > > > Svn is updated, the release code has been upped to 253. So we can get > > the compile machines running! > > > > I'd like to ask everyone to stop committing in trunk until we have > > confirmation from the release builders that things are OK for them. > > Only crucial fixes should go to svn now. Please use #blendercoders IRC > > for urgent feedback. > > > > While writing this, I already get two amendments in. Daniel Salazar > > found sculpt issues, Andrea Weikert likes to fix two small but > > important path issues. > > > > Updates will be following here... > > > > -Ton- > > > > BTW: The filenames for the builds can be like blender-2.53-beta-OS- > > blah.zip. > > > > ------------------------------------------------------------------------ > > Ton Roosendaal Blender Foundation [email protected] www.blender.org > > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > ------------------------------ > > Message: 8 > Date: Tue, 20 Jul 2010 17:39:06 -0300 > From: Diego B <[email protected]> > Subject: Re: [Bf-committers] Blender 2.53 beta AHOY! > To: bf-blender developers <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Thanks, I already move the files to the release\Blender2.50alpha folder. > > On Tue, Jul 20, 2010 at 5:26 PM, Damien Plisson <[email protected]> > wrote: > > All three OSX builds are on the ftp server. > > Builds were made with svn # 30554 > > > > Damien > > > > Le 20 juil. 2010 ? 20:19, Ton Roosendaal a ?crit : > > > >> Hi all, > >> > >> Svn is updated, the release code has been upped to 253. So we can get > >> the compile machines running! > >> > >> I'd like to ask everyone to stop committing in trunk until we have > >> confirmation from the release builders that things are OK for them. > >> Only crucial fixes should go to svn now. Please use #blendercoders IRC > >> for urgent feedback. > >> > >> While writing this, I already get two amendments in. Daniel Salazar > >> found sculpt issues, Andrea Weikert likes to fix two small but > >> important path issues. > >> > >> Updates will be following here... > >> > >> -Ton- > >> > >> BTW: The filenames for the builds can be like blender-2.53-beta-OS- > >> blah.zip. > >> > >> ------------------------------------------------------------------------ > >> Ton Roosendaal ?Blender Foundation ? [email protected] ? ?www.blender.org > >> Blender Institute ? Entrepotdok 57A ?1018AD Amsterdam ? The Netherlands > >> > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > ------------------------------ > > Message: 9 > Date: Tue, 20 Jul 2010 14:54:04 -0700 > From: Dalai Felinto <[email protected]> > Subject: Re: [Bf-committers] Blender 2.53 beta AHOY! > To: bf-blender developers <[email protected]> > Cc: Andrzej Ambro? <[email protected]> > Message-ID: > > <[email protected]<aanlktikefwdncjtn9jj3y9h5vh%2b950jpyfkb3%[email protected]> > > > Content-Type: text/plain; charset=ISO-8859-1 > > Out of curiosity, are we using the most recent created icons by > Andrzej (jendrzych) ? I didn't see this being updated in svn, but I > may have skipped some commits. > > Cheers, > -- > Dalai > 2010/7/20 Diego B <[email protected]>: > > Thanks, I already move the files to the release\Blender2.50alpha folder. > > > > On Tue, Jul 20, 2010 at 5:26 PM, Damien Plisson <[email protected]> > wrote: > >> All three OSX builds are on the ftp server. > >> Builds were made with svn # 30554 > >> > >> Damien > >> > >> Le 20 juil. 2010 ? 20:19, Ton Roosendaal a ?crit : > >> > >>> Hi all, > >>> > >>> Svn is updated, the release code has been upped to 253. So we can get > >>> the compile machines running! > >>> > >>> I'd like to ask everyone to stop committing in trunk until we have > >>> confirmation from the release builders that things are OK for them. > >>> Only crucial fixes should go to svn now. Please use #blendercoders IRC > >>> for urgent feedback. > >>> > >>> While writing this, I already get two amendments in. Daniel Salazar > >>> found sculpt issues, Andrea Weikert likes to fix two small but > >>> important path issues. > >>> > >>> Updates will be following here... > >>> > >>> -Ton- > >>> > >>> BTW: The filenames for the builds can be like blender-2.53-beta-OS- > >>> blah.zip. > >>> > >>> > ------------------------------------------------------------------------ > >>> Ton Roosendaal ?Blender Foundation ? [email protected] ? ? > www.blender.org > >>> Blender Institute ? Entrepotdok 57A ?1018AD Amsterdam ? The Netherlands > >>> > >>> _______________________________________________ > >>> Bf-committers mailing list > >>> [email protected] > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >> > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > ------------------------------ > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > > > End of Bf-committers Digest, Vol 72, Issue 31 > ********************************************* > -- ____________________ François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
