[Rawstudio-dev] Luminance curve - explainations and plan ?

Edouard Gomez ed.gomez at free.fr
Tue Apr 22 00:31:50 CEST 2008


Hello,

First of all, congrats for 1.0.

Now i'd like to bring back a subject about the curve
as it's something that still bothers me.

The current implementation can be simply considered as a table lookup
matching R->R', G->G', B->B', all color components using the same
table.

So for grey toned pixels (where R~G~B) this results in what we are
used to, the curve modifies more or less the luminosity of the
pixels. This works quite ok for the usual S-Curves for boosting
contrast. However for more exagerated curves, this completly
alterates the colors (shift in hue).

So as i see it, the current curve is buggy, and mislead the user.

So I propose again to work on a good curve implementation:
 - Luminance curve: chnges only the luminosity of the pixels
   respecting as closely as possible what humans consider
   luminosity.
 - Independent Red, Blue, Green curves for cross processing
   or any other "after effect".
 
Now I'd like to discuss the current pixel flow so I can try
to understand the logic behind the current rawtudio's pixel
processing:
 step 1 - Substract black point and shift pixel to cover the
          entire 16bit range
 step 2 - Apply exposure/saturation/temperature/hue
          using a 4x4 matrix
 step 3 - Apply curve
 step 4 - Apply contrast
 step 5 - Apply gamma or color profile
 (step 3/4/5 are in fact all done through a common lookup table)

When i submitted my patch concerning luminance curve, i remember
it's been refused because its effect was too soft. Someone advised
me to apply curve after gamma.

I think this suggestion was done considering the fact, human eyes
perceive as linear luminosity changes, changes that follow more a
gamma curve than a pi/4 sloped line. However this approach brings
two problems:
 - for my patch to work i used to compute f = y'/y, and then do
   r' = f*r, g' = f*g, b' = f*b which are linear operations on
   linear color components, because luminance is computed from
   linear components, not gamma corrected ones. So there's some
   kind of discrepency between the pregama and postgamma
   corrections.
 - Doing it post gamma, means i cannot efficiently implement
   luminance curves because i cannot simply use the 4x4 matrix
   that is used in step 2 to do Y computation for free.

I really would like to get a clean picture of the perfect pixel
flow we want to have in Rawstudio. However i see big speed slow
downs if i implement it that way.

What's your opinion ? Could we have some description of the pixel
flow, explaining step by step each change, and why it's done in
linear color space or gamma corrected one ?

Extra bonus question, are we right concerning the resize operation
that should be performed pre gamma correction ? See 
http://www.4p8.com/eric.brasseur/gamma.html

PS: i did not discuss the RGB curves because these ones can be
    implemented at choice on pregamma or postgamma pixels. It's an
    arbitrary lookup anyway.

-- 
Edouard Gomez



More information about the Rawstudio-dev mailing list