On Fri, Sep 21, 2012 at 09:31:11PM +0200, Marko Cebokli wrote:
> Yes, treating gama corrected stuff as linear is a very common misdemeanor, but
> obviously it is not such a big problem, otherwise people would already be
> running with guns after the authors of (most of the) imaging software!

Well, yes, you could argue that the errors are small. It depends a lot on
what you're doing, though, and in things like fades it can be quite
noticeable.

> Also, if you do no interpolation, but use just "nearest neighbors" this
> problem does not occur!

Then you've already given up all hopes for quality. :-) But yes, there are of
course effects like plain mirroring where it's irrelevant. Generally, if you
want to combine pixels you want linear-light processing.

> P.S. the "original sin" is usually already done in the camera, where the
> Y'CrCb values are matrixed from gama corrected RGB, so there is no salvation
> for us!

No, actually that's fine, because Y'CrCb are defined by a conversion from the
nonlinear RGB, not from linear tristimulus values. They are not supposed to
be perceptually correct quantities; the only thing they really are good for
are doing the inverse transformation to RGB. (Well, you can be sloppy and use
Y' directly as a nonlinear value of brightness, but that's an approximation.
_Then_ you are committing the “sin”, but that's not the camera's fault.)

FWIW, I'm not saying that calculation on nonlinear R'G'B' is horrible and that
you should throw out all and rewrite all Frei0r code; I think there are much
more important sins in there right now, like the linear tool that was brought
up earlier in this thread. Also, performance matters for a lot of things,
and the correct processing will inherently be slower, at least on the CPU.

/* Steinar */
--
Homepage: http://www.sesse.net/