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 _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
