Jasper van de Gronde wrote:
In any case, there is no good reason to multiply the coefficients by 255, just use 256 (or some other, higher, power of 2), that way the divide can be done with a single shift (and that should definitely be somewhat faster).
Maybe I'm gonna say something obvious for you, if so forgive me. When you do integer math there is a difference between multiplying by 255 or 256 and it's in what is '1'. '1' can be 255 (for example if you are speaking about R, G, and B coordinates) so you can make all the calculations up to 0xffffffff (or in general 2^(n+8)-1) then finally with x>>n you get directly your 8 bits result. But if you consider 2^(n+8) as being '1' you finally have to do x/(2^n+8)*(2^(8)-1), that is you need a multiplication that could be avoided because implicit in all preceeding calculations. And of course, the division cannot be done first (as would be in the expression I wrote) without using a cast to float (provided x is an integer). Also, having (2^n)-1 as '1' saves 1 bit that would be 1 only when followed by 0s and otherwise could be used to increase the precision.
I understand that having 2^n as '1' is conceptually easier, but when quantities limited to n bits are involved, usually 2^n-1 is '1' and then it's better to use their natural limit as normalizer.
Regards. Luca