Re: DRAFT: eXIF 2017-05-28

On Thu, Jun 1, 2017 at 3:54 AM, Pavel Zlatovratskii <[email protected]> wrote:
>
>
> 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.

I meant to say "encoders" (the application that creates the eXIf chunk
in the first place).

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

We probably don't, but the eXIf chunk is designed to be simple to
encode.  As willem said, KISS (keep it simple, stupid).

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

We already proposed such a chunk, in December 2000.  That proposal
(there's a reference to it in the current proposal) understands the TIFF tags
and structure, and converts them to a human readable text format.  The
proposal never got any traction (although ImageMagick does something
similar, converting the Exif profile to a stream of tEXt chunks)..

Glenn

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