[AD] Possible problem with dithering 24-bit bitmaps containing bright pink

[Laurence Withers <lwithers@xxxxxxxxxx>]

Hi,

Somebody on SourceForge has discovered what I believe to be a bug in the
dithering routines. For the discussion thus far, please visit (sorry,
should be all one line) :

  http://sourceforge.net/tracker/?func=detail&atid=105665&aid=232260&gro
up_id=5665

Basically, when converting from a 24-bit bitmap containing bright pink
(RGB of 255,0,255) to an 8-bit bitmap (the example was in the grabber),
then a slightly off-pink color (in the bitmap I tested, this was
242,0,242) is added to the resulting palette and most of the pink in the
bitmap becomes this color.

If you want to test this for yourself, find a 24-bit bitmap with
255,0,255 pink (or simply fill some areas in an existing picture), and
read it into the grabber with `Read bitmap'. Create a palette object and
go to `Grab'. Then save the palette out and look at it in your favourite
paint program. You should see a slightly off-pink color. If you convert
the bitmap down to 8-bit, the pink areas in the bitmap are this off-pink
color.

The question is: what should we do? The options I see are:

 * don't do anything
    - bitmaps using bright pink for transparency (which is Allegro's
      behaviour when using masked_blit() and the sprite routines) are
      converted completely incorrectly.
    + bitmaps not using bright pink for transparency are converted
      correctly.
    + we don't have to do any work :-)

 * change the `dither_blit()' routine in src/blit.c (I think this is
   the culprit)
    - bitmaps using bright pink as a color to be displayed are now
      converted incorrectly.
    - dithering would be slowed due to additional tests.
    + transparency is restored.

   This can be achieved by ensuring that color 0 in the resulting 
   optimised palette is always 255,0,255; and by ensuring that any
   255,0,255 pixels in the original bitmap are always converted to
   color 0; and that adjacent pixels are not affected by any pixels
   of 255,0,255.

 * add a new routine, which can be used at the user's discretion
    - increased complexity in API, since we have to provide some
      mechanism of choosing between them.
    + best of both worlds; behaviour is correct.

Anyway, please let me know what you think. Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature