PNG DataType alpha channel bug...

[broadblues]

well it's not quite a screen copy as that would not have the alpha but instead it's promoting the image to 32bit before displaying / saving.

So the original doesn't display properly.

Fron dicussion with Oliver on the BZ it appears that it's the application at fault not the datatype. Indeed I fixed the third test app up and it works fine now.

The OS4 Picture.datatype provides the tag PDTA_PromoteMask to upgrade the mask to an alpha channel when extracting 32bit data. The application needs to check the value of bmh_Masking (mine was originally only testing for mskHasAlpha and in the case the returned value is mskHasTransparentColor).

[xenic]

well it's not quite a screen copy as that would not have the alpha but instead it's promoting the image to 32bit before displaying / saving.

I dowloaded the image both ways and loaded them into ImageFX. The images appear to be slightly different in size. Both images load with an alpha channel. One picture has 256 colors and the alpha channel is just a white silhouette of the color image with no alpha blending. The other image has 13526 colors and has a proper alpha channel with alpha blending. Strange.

[broadblues]

Okay, it's clear what going on wrt to the two images differeing the original is palettemapped with single colour transparency, the version displayed inline is a scaled copy processed at 32bits (probably by the forum software) , this meaninsg the alpha channel contains smoothing and so is now grey scale.

Only the original 8bit image is relavent for this dicussion.

[Tuxedo]

Okay, it's clear what going on wrt to the two images differeing the original is palettemapped with single colour transparency, the version displayed inline is a scaled copy processed at 32bits (probably by the forum software) , this meaninsg the alpha channel contains smoothing and so is now grey scale.

Only the original 8bit image is relavent for this dicussion.

Sorry I'm a bit confused...so we have some sort of problem in the OS4 datatypes or "simply" have to check another tag?

[broadblues]

@Tuxedo
There is no problem in the OS4 datatype.

You need the tag PDTA_PromoteMask to make the datatype promote the transparency mask to an alpha channel whe the image has a single colour transprency

Code: Select all

/* If a CLUT (8-bit) picture with a transparent color needs to be
 * "promoted" to truecolor format for layout or scaling purposes,
 * setting this to TRUE allows the picture's transparency mask to
 * be converted as well and carried over to the truecolor data as
 * valid alpha information (BOOL). (V53)
 */
#define PDTA_PromoteMask      (DTA_Dummy + 225)

[Tuxedo]

@broadblues

Ok,
thank you.
Now it's all ok!

[softwarefailure]

@broadblues:

Check out the PNG specification. The image provided by Tuxedo does not contain a monochrome single-color mask but an alpha value for every entry in the provided palette.

4.2.1.1. tRNS Transparency

The tRNS chunk specifies that the image uses simple transparency: either alpha values associated with palette entries (for indexed-color images) or a single transparent color (for grayscale and truecolor images). Although simple transparency is not as elegant as the full alpha channel, it requires less storage space and is sufficient for many common cases.

For color type 3 (indexed color), the tRNS chunk contains a series of one-byte alpha values, corresponding to entries in the PLTE chunk:

Alpha for palette index 0: 1 byte
Alpha for palette index 1: 1 byte
...etc...
Each entry indicates that pixels of the corresponding palette index must be treated as having the specified alpha value. Alpha values have the same interpretation as in an 8-bit full alpha channel: 0 is fully transparent, 255 is fully opaque, regardless of image bit depth. The tRNS chunk must not contain more alpha values than there are palette entries, but tRNS can contain fewer values than there are palette entries. In this case, the alpha value for all remaining palette entries is assumed to be 255. In the common case in which only palette index 0 need be made transparent, only a one-byte tRNS chunk is needed.

See: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html

Thus, OS4's png.datatype should handle this without requesting PDTA_PromoteMask because it isn't a single-color monochrome mask but an alpha channel with individual transparency settings for every palette entry. PDTA_PromoteMask doesn't really make sense here.

[broadblues]

I pointed that out to Oliver in the BZ and he responded that although there was a tRNS chunk there was in fact only one transparent colour, so the datatype treats this special case as a single colour mask.

Reading the file in a hex editor there does seem to be a lot FF followed by a 00 in that chunck,

The datatype does in fact return bmh_Masking == mskHasTransparentColor so the alpa data is not ignored. The software just needs to check for more than mskHasAlpha.

At least two of my projects also make this ommission and have now been corrected ...

[softwarefailure]

Well, ok, still, this behaviour doesn't really make that much sense to me because it's somewhat lacking consistency because then you can get either mskHasAlpha or mskHasTransparentColor for tRNS PNG images depending on the actual chunk layout. It's also not consistent with the behaviour concerning 32-bit ARGB PNG images. They could effectively also only use 256 colors with a monochrome transparency mask. Still, everybody would consider it a stupid idea to map this down to a mskHasTransparentColor image so 32-bit ARGBs are always returned as alpha channeled images and the datatype doesn't interpret/analyze the actual image and transparency data either. But with indexed images it seems to do it. To me, this is somewhat inconsistent.

[zzd10h]

@Broadblues

Thank you very much, now it works too under FastView