I wouldn't consider it a bug. Color Balance makes no assumptions more than that it receives LINEAR to work on. Every other node assumes the same, so there's no problem here. Conversion to sRBG inside the algorithm can be treated as one of the operations this node performs. If we don't call this "conversion to sRGB", but "primary adjustment" or whatever else - we don't anymore perceive it as a bug, don't you think?
Getting back to "Color Correction" node: It's really fine with me that this node behaves as it does. If it's left this way we would only have to change names of the operations. "Gain" should be called "Slope" and "Lift" should be called "offset". Then everybody who knows those terms simply don't get unexpected results. Regards Bartek Skorupa www.bartekskorupa.com On 14 sty 2013, at 04:00, Troy Sobotka <[email protected]> wrote: > On Sun, Jan 13, 2013 at 3:57 PM, François T. <[email protected]> > wrote: >> but you have to know that Color Balance does a >> sRGB conversion internally. I don't think it would be good to do the same >> in CC > > This is unfortunate. I suspect this should be reported as a bug now > that we have a proper color management system in place for transforms > and expose the transfer curve. > > All nodes should make zero assumptions of the color space and transfer curves. > > With respect, > TJS > _______________________________________________ > 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
