The specification says "...samples are packed into bytes with the leftmost sample in the high-order bits of a byte followed by the other samples for the scanline.". This was not followed which lead to images using greyscale and indexed colours with pixel width smaller than full byte to have the order of pixels reversed within the byte reversed. Thanks to Samium Gromoff for the report and test case.
tRNS method sets (TRANSPARENCY *PNG-STATE*) to some raw data representation depending on colour-type. Then it adds so (TRANSPARENCY *PNG-STATE*) will become a 2D-array before *png-state* is finished. The latter part (adding the postprocessor) was inside an incorrect WHEN form, requiring (COLOUR-TYPE *PNG-STATE*) to be 0 or 2. First, our COLOUR-TYPE is a keyword, not a byte (thus 0 and 2 correspond to :greyscale and :truecolor, respectively). Second, build-transparency-map is prepared to handle :indexed-colour images as well, and there are images where it's useful. Third, preceding ECASE will fail for any colour-type except :greyscale, :truecolor and :indexed-colour. Therefore it seems that no additional checks are needed here at all, and that's the assumption behind this patch.
…(?) in SBCL-1.0.29.
…vector on subsequences for ten time speed gain for truecolor images.
…index from chunk data.