# [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

```