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

[Anders Brander]

Hi Edouard!

First off, sorry it took so long to answer - but I _really_ needed a
vacation after the 1.0-rush :)

On Tue, 2008-04-22 at 00:31 +0200, Edouard Gomez wrote:
> 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.

Thanks for being persistent. This is a thing we have to deal with.

> 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.

I agree 100%.

> 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.

This is exactly what the user would expect.

>  - Independent Red, Blue, Green curves for cross processing
>    or any other "after effect".

I'm not sure this is needed...

> 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)

This is pretty much the pixel flow, except you forgot a few:

step 1.3: apply magic adobe coefficients if no color profile selected
step 1.7: white balance multipliers

There's some spatial transformations after step 1, but that's not really
relevant for this discussion.

> 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.

Or multiply the curve with gamma before applying to linear data? That
would give the same result?

> 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.

You you sure of this? I believe (thou I can't exactly wrap my head
around it), that we could alter the curve to behave like it was applied
post-gamma.

> 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 ?

I think we should try to have a deeper discussion about the
pixel/color-flow in Rawstudio. We have several problems as of now.

A) All tranformations happens in "undefined" camera color space.
B) Curve is broken.
C) We have no Y-channel.
D) Color management is basicly broken.
- and probably more.

I see one common solution to A, B, C and D - transform everything to Lab
(XYZ, YCbCr or whatever) before doing any processing. I would really
like to hear comments about this?

> 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

I believe we're correct in doing it pre-gamma.

/abrander