Re: Endless gamma in eXIf 2017-0119

I suggest three things.

1: make the chunk unsafe-to-copy,
2. remove the Security Considerations paragraph from
the eXIf proposal (but keep the other part of Security considerations
about uncontrolled expansion in the zXIf proposal, and
3. include the following three paragraphs:

The eXIf chunk contains metadata concerning the original image data.
This data may not apply or may no longer apply to the PNG image data.
To avoid potential conflicts between data in the eXIf chunk and
in other PNG chunks, it is declared that only those Exif tags that
contain historical information such as data about the camera,
picture-taking conditions, and geographical location, and that do
not affect subsequent image processing have any meaning.
Such tags are listed in the Exif Specification (CIPA DC-008, Exchangeable
image file format for digital still cameras) Annex E, Paragraph 3,
with the notation "should be copied unchanged".

Encoders may write all known Exif tags in the eXIf chunk; however,
any other tags which might be present in the eXIf chunk shall be ignored
by decoders, and tags containing information relevant only to the
original JPEG or TIFF encoding shall be ignored by decoders.

If a thumbnail image (or multiple thumbnail images) is present,
there is no expectation that such thumbnails have been updated if
the main image was changed, or that they have not been updated.

Glenn


On Tue, Feb 7, 2017 at 8:14 PM, John Bowler <
[email protected]> wrote:

> On Tue, Feb 7, 2017 at 10:38 AM, Glenn Randers-Pehrson
> <[email protected]> wrote:
> > It's not sufficient because our copy-safe mechanism does
> > not adequatly handle potential conflicts among ancillary
> > chunks, such a gAMA and eXIf in this situation.
>
> Yes it does!   Read the rules for PNG editors carefully.  They don't
> say it is legal to write a PNG with the wrong metadata, even if you
> include the right metadata as well and it would be contrary to common
> sense to suggest that that was the intention.  We had to made an
> explicit exception to common sense to allow eXIf to introduce
> incorrect metadata and the result is intractable.
>
> A editor that conforms to those rules with eXIF (unsafe) *must* either
> update the relevant tags in EXIF, delete the relevant tags or delete
> the whole chunk.  There is no other possible interpretation; it's
> exactly the same as if an editor edits a PNG with an iCCP chunk.
>
> The only argument against unsafe-to-copy was Cosmin's assertion that
> the chunk has to be safe-to-copy because the textual metadata is too
> valuable.  Everyone else who expressed an opinion effectively argued
> strongly against the safe-to-copy semantics.  (Remember, that is why
> you put the line in the "security" section; the thumbnail argument.)
>
> I never regarded Cosmin's argument as compelling but none of the
> anti-thumbnailers argued against it.
>
> I accept Adam's reasons but I don't think adding more words that no
> one will take any notice of helps.  The default has to be to delete
> the chunk; something that understands it can easily maintain it; exiv2
> is a complete, adequate, library implementation and so is exiftool.
>
> 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
>

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