[Bf-committers] Color Correction Node - "Lift"

Bartek Skorupa (priv) bartekskorupa at bartekskorupa.com
Mon Jan 14 16:21:10 CET 2013


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 <troy.sobotka at gmail.com> wrote:

> On Sun, Jan 13, 2013 at 3:57 PM, François T. <francoistarlier at gmail.com> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list