BUILD-TRANSPARENCY-MAP not called for images with tRNS #3

Merged
merged 1 commit into from Jan 18, 2012

Projects

None yet

2 participants

@akovalenko
Contributor

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.

@akovalenko akovalenko Really invoke build-transparency-map when a tRNS chunk is present.
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.
e3d258b
@Ramarren Ramarren merged commit e3d258b into Ramarren:master Jan 18, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment