You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of issues which have come up where different decoders handle error conditions differently. For example, #96 and #29.
We should discuss whether to specify some degree of error handling behavior and what it should be.
For example, an error while parsing a critical chunk might block decoding the image. This should then be treated as an error with the whole image. However, an error while parsing a tEXt chunk can perhaps be ignored and the image can still be decoded and displayed.
This could get tricky, though. One of the tEXt chunk keywords is "Warning" for cases where the user might want to be warned about the nature of the image before viewing it. For example, maybe the image contains violence. If we ignore an erroring tEXt chunk as part of the spec, an image viewer might forgo warning the user before displaying that image.
Or perhaps there is an error in an iCCP chunk. A picture of an apple will still clearly be an apple even if the colors aren't perfectly correct. Should that be displayed? Should the spec dictate correct behavior at all, here?
The text was updated successfully, but these errors were encountered:
We could lean on the existing critical chunk & ancillary chunk divide to determine if an error in this chunk should prevent the entire image from being displayed. For example, an error in an ancillary chunk could perhaps be ignored. After all, that is part of the definition of ancillary chunks: "Ancillary chunks may be ignored by a decoder."
But we could also create a new divide for the different forms of error conditions. Maybe we will have more then 2 error handling conditions and thus a 2-way divide is insufficient.
In the Aug 8th, 2022 meeting we agreed that PNG encoders & decoders are already highly motivated to behave in a way the user wants. Any wording we add to the spec will likely provide zero additional motivation.
There were no objections to adding a note to encourage minimizing error severity (Is this really an error? Is a warning more appropriate?) and error surface area (Should we error the whole image or just this chunk?). But again, the note might not be useful.
Instead, we agreed the most useful path forward is to add offending images to a standard test set. This assists PNG encoder & decoder writers with the motivation they already have.
There are a number of issues which have come up where different decoders handle error conditions differently. For example, #96 and #29.
We should discuss whether to specify some degree of error handling behavior and what it should be.
For example, an error while parsing a critical chunk might block decoding the image. This should then be treated as an error with the whole image. However, an error while parsing a tEXt chunk can perhaps be ignored and the image can still be decoded and displayed.
This could get tricky, though. One of the tEXt chunk keywords is "Warning" for cases where the user might want to be warned about the nature of the image before viewing it. For example, maybe the image contains violence. If we ignore an erroring tEXt chunk as part of the spec, an image viewer might forgo warning the user before displaying that image.
Or perhaps there is an error in an iCCP chunk. A picture of an apple will still clearly be an apple even if the colors aren't perfectly correct. Should that be displayed? Should the spec dictate correct behavior at all, here?
The text was updated successfully, but these errors were encountered: