[IPOL discuss] RGB->gray conversion and speed comparison

[Nicolas Limare]

> Moreover, using the round function of the math library with floating point
> data types has some advantages:
> - The result is quite exact when performed before the integer
>   truncation.

The exactness "before rounding" is useless, we only use the results
after rounding. The integer code provides the same results as the
float code for 99.916% of the RGB triplets.

> - The code is easy to understand.

I agree.

> - The code is portable. There's no reason why the bit shift operations
> used to divide/multiply could be applicable in all architectures.

I agree this may not be portable. But the rgb_to_gray operation in
libpng is implemented with bit shifts too, so if io_png is not usable
on a machine, neither is libpng and then worrying about io_png
portability is irrelevant. And if we consider machines where this bit
shifting is wrong, we may also have to consider machines without a
floating-point unit and *very slow* emulated float operations.

> - Errors in the implementation can be easily noticed. If coded with bin
> shift operations, no one would have ever found the bug Nicolas sent to the
> libPNG mailing list today.

libpng *is* coded with bit shift operations, and I noticed the bug.

> - No speed-up is critical in the conversion, because it's done just once.
> Saving a few CPU clocks in this step is irrelevant.

I agree.

I mainly made these benchmarks to understand why the conversion was
implemented with integers and bit shifts in libpng, and the answer is
clear, it is faster. And it makes sense to try to achieve the best
performance in the reference library. But we don't have the same needs
for io_png.

My long-term plan is to have the "correct and fast integer code with
bit shifts and rounding" integrated into libpng, then use the libpng
functions in io_png. Then no obscure code would be exposed in io_png,
the code would hopefully be tested and maintained by other people on
other platforms, and we would also have a correct conversion for
images expressed in a non-sRGB color space. Meanwhile, I would put a
mixed integer/floating-point code in io_png and mention the integer/shift
version as an alternative. What do you think of this plan?

-- 
Nicolas LIMARE - CMLA - ENS Cachan    http://www.cmla.ens-cachan.fr/~limare/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20110729/6c82eeba/attachment.pgp>