[Image-SIG] Writing a plugin

[Fredrik Lundh]

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

Well, I'm afraid there isn't any good support for this right now...

We've been considering adding support for PA and LA images, but I'm
not sure if I want to add a 16-bit internal format, and storing 8+1 bit
pixels in 32 bits is a bit too wasteful for my taste (but on the other
hand, that's definitely better than no support at all ;-)

But for now, the only way out is to tweak the decoder to return
such images as RGBA...  not elegant, but again, it's better than
nothing.

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

Sounds reasonable.

(there's no formal specification for packer names; guess the syntax is
something like <mode> ; <bits> <flags> where flags are in alphabetical
order.  So "P;1R" etc is correct)

>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 :)

just send patches against the lastest release (or the affected files)
to yours truly, and they'll appear in the next release.

(once Garnet [1] goes gold, there will be a final 0.3/1.0 beta.  Maybe
as early as next week.  After that, I just have to update the docs, and
PIL will go 1.0).

Cheers /F

*) http://www.pythonware.com/secretlabs/garnetsnapshot1.jpg