Why expand an 8-bit image to 32-bit RGBA unnecessarily, when it is quick and easy to test for this... For an application, it should not need to know or be concerned about how the PNG tRNS chunk works. What happens if you read an 8-bit ILBM or GIF image that may set mskHasTransparentColor also? You need to handle mskHasTransparentColor generally, not just for PNG images, so it shouldn't matter what png.datatype is doing internally. Picture datatype subclasses are consistent in that they try to return the decoded image in as close to the original pixel format as possible. They do not expand (or indeed reduce) images unnecessarily - after all, picture.datatype is there to handle that for applications when they need it.softwarefailure wrote: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.
Also, legacy applications need to be considered - not just old OS3 apps, but OS4 apps not updated since the OS gained alpha support. When I originally added full RGBA output support to png.datatype, it did expand all 8-bit images with tRNS to RGBA, which I do recall did "break" several applications in that icons in their toolbars were no longer rendered correctly (no transparency, with purple backgrounds instead, etc). Hence, this behaviour was changed.
