Anders Brander ([EMAIL PROTECTED]) wrote:
> I have an idea. Some pseudo code to explain:
> more_magic()
> {
> float luma_curve[65536];
> ...
> output = tranform_rgb_as_usual(input);
>
> luma = cumpute_luma(output); /* Maybe cumpute_luma(input); */
>
> output.r *= luma_curve[luma];
> output.g *= luma_curve[luma];
> output.b *= luma_curve[luma];
> ...
> }
>
> - removes hue-shifting.
> - makes curve a lot more predictable.
> (- extremely easy to implement with our current SSE-based render code)
I played with the C renderer and modifying more like:
more_magic()
{
float curve[65536];
...
output = tranform_rgb_as_usual(input);
luma = cumpute_luma(output); /* I tried input aswell */
output.r += rfactor*(luma_curve[luma] - luma);
output.g += gfactor*(luma_curve[luma] - luma);
output.b += bfactor*(luma_curve[luma] - luma);
...
}
The idea was to distribute on the RGB triple the correponding luma
difference for each component.
Results:
It doesn't work well at all.
I tried some variants like really computing YPbPr (not YCbCr as we don't
work on the correct range and don't want to use some 8bit/channel
standard) and then computing back the RGB triple from a modified luma
and untouched PrPb channels... didn't work well too. There was still
some Hue shift and/or some temperature shift.
Any progress on your side ? I don't find any good paper on that simple
image processing problem.
--
Edouard Gomez
_______________________________________________
Rawstudio-dev mailing list
[email protected]
http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
