[Bf-committers] Color Balance & Color wheel issue

Wed Jul 21 01:15:04 CEST 2010

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 <bf-committers-request at blender.org>

>
> Date: Tue, 20 Jul 2010 15:45:25 -0300
> From: Xavier Thomas <xavier.thomas.1980 at gmail.com>
> Subject: Re: [Bf-committers] Color Balance & Color wheel issue
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
>        <AANLkTinyJldNJfPo8ozEm3GcdG1TgMkeoV80g3IAExhb at mail.gmail.com>
> 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. <francoistarlier at gmail.com>:
> > 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 <bf-committers-request at blender.org>
> >
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Mon, 19 Jul 2010 21:45:11 +0200
> >> From: Fran?ois T. <francoistarlier at gmail.com>
> >> Subject: [Bf-committers] Color Balance & Color wheel issue
> >> To: bf-committers at blender.org
> >> Message-ID:
> >> ? ? ? ?<AANLkTinh1beokGXTZjkiQgYMYSRKJUuDdkS0_nAbAs_w at mail.gmail.com>
> >> 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
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 20 Jul 2010 22:26:45 +0200
> From: Damien Plisson <damien.plisson at yahoo.fr>
> Subject: Re: [Bf-committers] Blender 2.53 beta AHOY!
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID: <A16EC1C9-684D-439A-AD11-B9E062A4AFF2 at yahoo.fr>
> 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   ton at blender.org    www.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 20 Jul 2010 17:39:06 -0300
> From: Diego B <bdiego at gmail.com>
> Subject: Re: [Bf-committers] Blender 2.53 beta AHOY!
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
>        <AANLkTincbeTsiSa_TN41Da8GSeHY1ZblEWX6cvJ6VgXM at mail.gmail.com>
> 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 <damien.plisson at yahoo.fr>
> 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 ? ton at blender.org ? ?www.blender.org
> >> Blender Institute ? Entrepotdok 57A ?1018AD Amsterdam ? The Netherlands
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 20 Jul 2010 14:54:04 -0700
> From: Dalai Felinto <dfelinto at gmail.com>
> Subject: Re: [Bf-committers] Blender 2.53 beta AHOY!
> To: bf-blender developers <bf-committers at blender.org>
> Cc: Andrzej Ambro? <andrzej.ambroz at gmail.com>
> Message-ID:
>        <AANLkTikEfwDNcJTn9jj3Y9h5Vh+950JpyFKb3+qTjusf at mail.gmail.com<AANLkTikEfwDNcJTn9jj3Y9h5Vh%2B950JpyFKb3%2BqTjusf at mail.gmail.com>
> >
> 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 <bdiego at gmail.com>:
> > Thanks, I already move the files to the release\Blender2.50alpha folder.
> >
> > On Tue, Jul 20, 2010 at 5:26 PM, Damien Plisson <damien.plisson at yahoo.fr>
> 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 ? ton at blender.org ? ?
> www.blender.org
> >>> Blender Institute ? Entrepotdok 57A ?1018AD Amsterdam ? The Netherlands
> >>>
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
> ------------------------------
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> 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