Re: DRAFT: eXIF 2017-05-28
Pavel Zlatovratskii <[email protected]> Thu, 1 Jun 2017 10:54:56 +0300
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Organization | TB.Budget |
| Message-ID | <[email protected]> |
31.05.2017 23:35, Glenn Randers-Pehrson пишет: > > We could do that be defining an eXIf > chunk that only contains the safe-to-copy fields, but that involves > decoders having to understand the Exif profile enough to be able > to separate the good from the bad. > That was and idea I was talking about from the very beginning: why do we ever need decoder that's not able to parse data? Even for PNG-to-JPEG... direct use of eXIf chunk is not thing I support. It looks like PNG-to-PNG recompression when no ancillary chunks are recognised, but instead all data between critical chunks copied as-is, like completely ignore all unsafe-to-copy properties. To keep metadata correct we must parse them. Or on every processing, handling their safe/unsafe-to-copy state (eXIF way), or by discarding all data that could be broken on reading (eXIf way). Never parse EXIF and believe that it still applicable for image(or even correct)... I think it's simply too reckless. -- Have a nice DOS. Pavel Zlatovratskii [email protected]; [email protected] ------------------------------------------------------------------------------ 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