Handling unknown chunks in png editors - tRNS chunk - AniPNG/ANG status
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
Handling unknown chunks in png editors - tRNS chunk - AniPNG/ANG status
by Bugzilla from walch.martin@web.de
::
Rate this Message:
The PNG specifiactions describe in "7.1. Behavior of PNG editors" how to treat
unknown chunks in png editors, which basically comes down to - give up on critical chunks - ancillary safe-to-copy chunks must stay on their relative position to IDAT - ancillary unsafe-to-copy chunks must stay on their relative position to critical chunks Furthermore it says that no critical chunk may be modified when preserving unsafe-to-copy chunks. How strict is this? For example: a png file has two IDAT chunks and an unknown unsafe-to-copy chunk bLOB. Is an editor allowed to concatenate the two IDAT chunks and to copy the bLOB chunk? If yes: may the IDAT data be reencoded with DEFLATE,or may even new png filters (e.g. Paeth instead of Sub) be applied? Or may even a palette png be reencoded as RGBA? --- The chunk tRNS is ancillary. I do not understand this. Why is it ancillary? Transparency is part of the image data. If transparency is not understood, a transparent png can not be successfully displayed. Also, in images of color type 4 or 6, the transparency values are part of the critical IDAT chunks. So it is possible that a decoder will display no transparency when getting a palette png with tRNS chunk, but will render a transparent image when getting exactly the same image as color type 6. --- Finally: I read about AniPNG and ang as a successor to mng ("mng 2.0"), but the website seems to be dead. What is the status of this? ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: Handling unknown chunks in png editors
by John Bowler
::
Rate this Message:
From: Martin Walch [mailto:walch.martin@...]
>Furthermore [the spec] says that no critical chunk may be >modified when preserving unsafe-to-copy chunks. How strict is this? I don't think there are any exceptions. >For example: a png file has two IDAT >chunks and an unknown unsafe-to-copy chunk bLOB. Is an editor allowed to >concatenate the two IDAT chunks and to copy the bLOB chunk? My interpretation has always been *NO*. In the case of your other transformations bLOB might be an index into the IDAT, e.g. to allow the decoder to access individual rows directly (without accessing prior rows.) Either of your transformations would break that, regardless of how the index is represented: >If yes: may the >IDAT data be reencoded with DEFLATE,or may even new png filters (e.g. Paeth >instead of Sub) be applied? I don't think we've explicitly discussed things like repacking IDAT before but I don't think even that is allowed. >Or may even a palette png be reencoded as RGBA? That definitely isn't permitted. John Bowler <jbowler@...> ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: tRNS chunk
by John Bowler
::
Rate this Message:
From: Martin Walch [mailto:walch.martin@...]
>The chunk tRNS is ancillary. I do not understand this. Why is it ancillary? Because it can be ignored by a decoder that conforms to the spec. >Transparency is part of the image data. If transparency is not understood, a >transparent png can not be successfully displayed. I think you mean *correctly* displayed. Ignoring the tRNS chunk does not cause the decoder to fail, instead it displays image data where no image data should be displayed. Section 13.16 "Alpha channel processing" says: }Ignoring the alpha channel will cause PNG images that have }been converted from an associated-alpha representation to }look wrong. (Of course, if the alpha channel is a separate }transparency mask, then ignoring alpha is a useful option: }it allows the hidden parts of the image to be recovered.) Since there is no information in the documented chunks saying how the alpha channel is being used that statement gives decoders freedom to simply ignore the alpha channel. The same applies to the alpha information in a palette image, consequently tRNS is ancillary - it can be ignored. >Also, in images of color >type 4 or 6, the transparency values are part of the critical IDAT chunks. Yes, that's always seemed a little inconsistent to me too. It's reasonable to make the transparency information a separate chunk because it efficiently encodes a common GIF case, but it results in the inconsistency that would be avoided if, for example, PNG had simply always used an RGBA palette. John Bowler <jbowler@...> ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
