Re: EXIF support in PNG [was: Modern compressor]
John Bowler <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAP7U39-5pNDdmuYwWD+TnTWbtjROvuWoCAkCcn_5zAGwTbKUkg@mail.gmail.com> |
On Sat, Dec 31, 2016 at 1:14 PM, Glenn Randers-Pehrson <[email protected]> wrote: > The format of a proposed eXIf chunk would be similar to that of iCCP: > > keyword (e.g., "Nikon EXIF data", 1-79 bytes of Latin-1 characters) > null separator > compression method (0 means zlib/deflate) > compressed data > EXIF already has, internally, support for manufacturer specific information (MakerNote). It makes some sense to have a keyword identification of ICCP profiles because they are *not* specific to the image, it doesn't make sense for EXIF because it *is* specific to the image. There should be only one chunk but it should be permitted before or after the IDAT (unlike ICCP). I don't like compression for the reasons I implied before; it means that someone has to decompress it which means just reading it from the unknown chunk list can't be done. It also gets PNG implementations like libpng into the business of validating the data; at least I think that is how we ended up doing format checks on ICCP data and look at what a disaster that is. What I'm saying is that it is a *complete* black box except for some reference to a spec that is not under our control. If someone ends up with a PNG with EXIF data which crashes an app (and this is certain to happen) that is the problem of the app or the EXIF library they use; nothing to do with any PNG file decoding implementation. John Bowler ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ png-mng-misc mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/png-mng-misc