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

[Pascal Getreuer]

Hi Nicolas,

You have done a great job with the grayscale conversion, you are
careful and very thorough.  The fixed-point arithmetic instead of
floating-point is justified because it is unambiguously faster, it is
correct, and many IPOL authors will use this code in the future.

>> - 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.

The only point to worry about is that the arithmetic requires integers
that are at least 24 bits.  This can be ensured with the UNIX stdint.h
uint32_t type or unsigned __int32 on Windows.  You can get a
"uint32_t" type on either platform as

#if defined(WIN32) || defined(_WIN32) || defined(WIN64) || defined(_WIN64)
typedef unsigned __int32 uint32_t;
#else
#include <stdint.h>
#endif

Otherwise, I have no doubts about its portability.  There is no
dependency on sign representation or endianness in Nicolas' solution.
Bitwise operations are defined in the C standard just like the
arithmetic operations.  A conforming C compiler must ensure that
bitshifts behave as defined on the target hardware (e.g., the
shl/shr/sar instructions on older x86 processors can only shift by one
bit, so a shift >> 14 on a 80186 would need to use a div or a loop to
implement it).

> we would also have a correct conversion for images
> expressed in a non-sRGB color space.

Beware that PNG's gamma and color correction is controversial:

   The Sad Story of PNG Gamma “Correction”
   http://hsivonen.iki.fi/png-gamma/

The problem is that many programs write PNGs *assuming* the gamma
correction based on the hardware (the PNG spec encourages this), and
this value is often inappropriate.  So many programs, including GIMP
and MATLAB, simply ignore the corrections.  For sake of simplicity and
transparency, I think that ignoring the corrections is a reasonable
way to do it.

Best,
Pascal


On Fri, Jul 29, 2011 at 07:24, Nicolas Limare
<nicolas.limare at cmla.ens-cachan.fr> wrote:
>> 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/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk4ymIUACgkQvviFAPpCP09g3gCgpOz47wREEshf3TS6vGCeyLKE
> 9bgAnj6s0P0K/A5dPCpdMKAjZcGu0oaA
> =Hxdr
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss
>