[Image-SIG] Writing a plugin

[Laurence Tratt]

I'm writing a new plug in decoder for PIL (I'm doing this under 0.3b2) for
a format that's specific to the platform I use (Acorn RISC OS) called
simply a "Sprite". It's a bit of an odd format (in common with most image
formats :)), but I've now managed to get most of the varieties that it can
hold working (it can contain 24, 16, 8, 4, 2 and 1 bpp images) with and
without palettes. However one thing is currently troubling me: mask data is
held away from the main image and I can't see any obvious way of getting
this to work.

PIL has some nice obvious ways of coping with transparency if the data is
held within the picture (ie for 24bpp sprites with a 8bit mask making a
32bit word) or if a colour is denoted to be the transparency (ie for gif
files), but if there is support for genuine mask data held externally to
the main image (it's actually held directly after the image), I can't find
it: it certainly doesn't seem to be documented :( Can anyone help me on
this?

Oh, and just to make things a little more interesting, any bpp image can
have a mask and although the mask data is simply On or Off, depending on
the format of individual images, individual mask "bits" can be anything up
to 8 bits long (thankfully when someone put their thinking head on this was
sorted out a few years ago, so modern images all have 1 bit masks) :)


On another note, to get support for 16, 4, 2 and 1bpp images working
correctly, I have had to add 4 raw decoders to unpack/c:

    {"P;1R", 1, unpackP1R},
    {"P;2R", 2, unpackP2R},
    {"P;4R", 4, unpackP4R},
    {"RGB;5", 16, ImagingUnpackRGB5},

RGB;5 is an obvious variation of the existing BGR;5 decoder, and the other
ones are the same as their "non" R relatives, except that everything is
stored lsb first.

I have no idea what PIL policy is on adding raw unpackers (certainly my
naming of the P decoders with the 'R' (for reversed :)) on the end is not
something I particuarly like), but these decoders aren't down to some ultra-
obscure format - it's just a byte-order difference - so that's why I
haven't put them in their own /c file.


I also have no idea what the procedure is for including any of this in the
main distribution, if that's thought appropriate eventually. Suggestions
are welcome :)


Laurie who - frighteningly - still has some more questions, but thinks the
         the others should probably wait for a little while :)