Re: Endless gamma in eXIf 2017-0119
John Bowler <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAP7U39-4DjXWcFabJDVftws+Pp5dhoDH77AqJO_LQ8KsE6yj3Q@mail.gmail.com> |
On Mon, Feb 6, 2017 at 6:44 PM, Willem van Schaik <[email protected]> wrote: > > And also, if we would make the chunk "unsafe to copy" what does prevent > an application developer to still copy the chunk? In the end, these are > just "suggestions". Well... the issue as I understand it is that in a completely conformant workflow the data in the eXIf chunk might end up such that the rendering of the PNG will be incorrect. Personally I think that such a workflow is unlikely and that, anyway, the issue is moot. This is because the ISO-PNG specification is such that any PNG with metadata which affects the rendering of the image has two completely valid conformant renderings; one where the metadata is used and one where it is not. I suspect this is why browsers which used to support gamma processing have stopped doing so; the standard permits two renderings, so why spend CPU time producing the more difficult one? So I don't think any simple PNG decoder will ever use the image-related EXIF chunk data and the "security" section of the eXIf proposal is, I believe, more than sufficient to stop them (why would they make their life more difficult?) -- John Bowler <[email protected]> +1 (541) 450-9885 PO BOX 3151 KERBY OR 97531-3151 USA ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot