Re: EXIF support in PNG [was: Modern compressor]

On Sat, Dec 31, 2016 at 5:49 PM, John Bowler <
[email protected]> wrote:

> 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).
>

I didn't intend for the keyword to be a camera identifier, I just picked it
as a n example of
something I might write in the keyword field, and it's probably what I
would put in the
keyword field, so pngcheck would easily tell me about it.  It's just there
for symmetry with
other PNG chunks; we know how to read a keyword (it's just text) but we
don't necessarily
know how to read the blob that follows the keyword.


> 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.
>

I am certainly *not* suggesting that we read the EXIF chunk (although
ImageMagick does parse out the "orientation" and "resolution" fields (the
latter causes trouble because it is redundant with the pHYs chunk and the
text/density chunk that people throw in).

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
>

Yes, that is what I proposed, to be conveyed by the "compressed data" part
of the chunk.


> 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.
>
>
>

------------------------------------------------------------------------------
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