Page MenuHome

Color correction lift parameter does not work properly
Closed, ArchivedPublic

Description

Group: current SVN version
Category: Sequencer

The Lift parameter add a constant value to each composant of a pixel. This is not what is expected from a lift, this is a "value" adjustement (exepet that it can modifu channel separatly)

You can easily see in the wavelet monitor that this paramter affect just as much the highlights and the midtones than the shadows.

The value (constant input) added to the pixel composants (rgb) must be modarated by the inverse of the componant value. (I don't know if I am clear sorry)

For a float image, this should be like this:
newR = oldR + ( (1-oldR)*lift );
newG = oldG + ( (1-oldG)*lift );
newB = oldB + ( (1-oldB)*lift );

Event Timeline

Sorry, I forgot to mention that the neutral (non changing) value for the lift is 0; so you need to invert it for keeping white as neutral parameter.

But you got that already.

cia

Hi,

I find the bug (in sequence.c line 1284 for byte image and 1305 for float image). I can write a patch for it but I have some questions:

- It use a table with 256 steps to avoid computing value for each pixel so it round the result with float. Must this be corrected or is it a feature (quicker)

- For now lift go from -1 to 0 (negative) and 0 to 1 (positive) but as a lift of 1 give a white frame, a black rane is obtained with a lift of -infinite. Do I need to remap negative to 0->-infinite. (Change render result of previous file)

- Correcting the bug will also change render result of previous file. Do I have to care of this?

Thanks

xavier

patch submited:

https://projects.blender.org/tracker/index.php?func=detail&aid=18078&group_id=9&atid=127

Thanks, I've replied to the patch tracker for this.

Ton Roosendaal (ton) changed the task status from Unknown Status to Unknown Status.Apr 20 2009, 5:41 PM

This task was automatically closed as archived as part of migration, because the project or tracker this task belonged to is no longer active.