On 2002.04.13 10:35 Marcelo E. Magallon wrote:
> >> José Fonseca <j_r_fonseca@...> writes:
> > t/255 ~= (t + (t>>8) + (t>> 15)) >> 8
First, let me explain what was my idea when proposing this. Based on Alvy
Ray's geometric series expansion of the division I wanted to make just the
less intrusive (and fastest) correction to achieve the 255x255 = 255
For t=255*255=65025, making
(t + (t>>8)) = 65279
65279 >> 8 = 254
Just a minor correction is sufficient to get it to work as
(65379 + 1) >> 8 = 65280 = 255
But adding 1 to all range could induce a very significant error when t is
small. So instead off adding 1 all the time I added the highest bit of t.
So when t is small nothing is really added.
> hmm... if you are willing to go down that route you can use:
> t/255 ~= (t + 2*(t>>8) + (t>>15)) >> 8
I don't understand the meaning of this change as it breaks with the
> which is correct 75% of the time when compared with the rounded up
> result -- it is unclear to me why would anyone want to compare against
> the truncated result, that's incorrect from a statistical point of
> view. Your version is correct 50% of the time.
> > - it doesn't gives the exact results just 4.241.987 out of 16.777.216
> > possible cases, i.e., is exact 75% of the times.
In fact is 50% too. I had a typo in my test program. (The MMX code didn't
had this typo, so everything else said still holds).
> When used for blending you mean. When compared to the rounded up
> result and using the "one multiplication, one division" version your
> solution is correct about 50% of the time. Interestingly mine is much
> worse. More important, when applied to that computation (and only to
Yes, indeed. Your is correct only 33% of the times, and and least in this
case we are blending after all. But your proposal could be very handy we
need to do this single multiply/divide in other places, such as with other
blending functions, or texture environments.
> that computation) the error is more or less +1 25% of the time and -1
> 25% of the time, with a slight bias towards -1 for brighter pixels.
> An off-by-one error wreaks havoc when blending multiple fragments:
> r(1,0) = (c1-c0)*a1/255 + c0
> r(2,1) = (c2-c1)*a2/255 + c1
> now if c1 is off by one (correct = incorrect + 1):
> r'(2,1) = (c2-c1+1)*a2/255 + c1-1
> = (c2-c1)*a2/255 + c1 + (a2-255)/255
> now, if the second fragment is basically transparent, you have an
> off-by-one error *plus* the error you are going to make in first two
> terms. I'm not sure if this has a chance of balancing out.
I don't know what's the effect of these errors adding-up after mipmapping,
multitexturing, blending, etc... but if this becomes an issue we always
have the option of safe 100% exact way, already in the code. But I doubt
that conformance test require always an error less than 1 LSB in the final
result with all possible configurations as that would only be possible to
achieve by doing all the itermediate calculations with floating point...