Re: EXIF support in PNG

John Bowler <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAP7U398WiQr5L2QWBZhc6Mg2gnKhWBaH5GF2h4MTw-dNXMhuHA@mail.gmail.com>
>    When present, the eXIf chunk contains Exif metadata that is compatible
>    with specifications issued by CIPA, "Exchangeable image file format for
>    digital still cameras" [CIPA DC-008-2016] or its successors.

http://www.cipa.jp/std/documents/e/DC-008-Translation-2016-E.pdf

> See  https://www.media.mit.edu/pia/Research/deepview/exif.html

That document, unfortunately, has many broken links.  ISO 12234 (the
XMP standard; https://www.iso.org/obp/ui/#iso:std:iso:12234:-3:ed-1:v1:en)
used this reference (for the 2012 version):

[6] CIPA DC-010-2012, Exif 2.3 Metadata for XMP. Available at:
http://www.cipa.jp/std/documents/e/DC-010-2012_E.pdf

So I think the the text above with the link I gave in the reference is
sufficient.  It does contain pretty much everthing in the
media.mit.edu document in section 4.7 (which covers the JPEG
encoding).

>
>    The eXIf chunk contains an Exif profile in a raw format:
>          Data: length bytes where "length" is determined
>                by the chunk "length" field, containing a
>                raw Exif profile.
Should be:

* The eXIf chunk contains an Exif profile in the format specified in
"4.7.2 Interoperability Structure of APP1 in Compressed Data" of [CIPA
DC-008-2016] except that the JPEG APP1 marker and length (the first
four bytes) are not included.

*     Data: length bytes where "length" is determined by the chunk
"length" field and starting with the "Exif ID code" described in
4.7.2(C).

* The encoder shall set byte 5 (described as 'padding') to 0 however
the decoder shall not check or interpret the byte in any way.

It would be reasonable to drop the JPEG tag; it is only required in
JPEG because the APP1 marker is used for many purposes and the PNG
chunk ID duplicates the information.  It makes little difference to
the decoder because the library code I have examined does not expect
it; it it is there the decoder has to skip it.

The definition should be with respect to the JPEG encoding because
this separates out the non-applicable FlashPix Exif "extended" data,
which is stored in an APP2 marker segment.

[* * *]
>
>   eXIf Security considerations
>
>    It is proposed to add the following two clauses to Section 7 (Security
>    Considerations) of the "Extensions to the PNG 1.2 Specification,
>    Version 1.4.0" document:
>
>    The eXIf chunk may contain data such as image resolution and dimensions
>    that are redundant with existing PNG chunks. Applications must be
>    prepared to handle such redundant and perhaps conflicting information.

Should be:

* 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.
Where conflicting information is present in other chunks in the stream
that data shall be assumed to be correct unless it can be determined
to be incorrect.  Information relevant only to the original JPEG or
TIFF encoding shall be ignored.

>    The eXIf chunk may contain a "thumbnail" or a "preview" of the image.
>    If portions of the image have been redacted or otherwise edited, authors
>    may be surprised to learn that they have leaked private information by
>    publishing an unredacted image.

That applies to any meta-data.  Any person or software which attempts
to anonymise a PNG stream must remove all chunks unless absolutely
certain they are clean.

Something as apparently innocent as an author name or copyright string
can be an even more serious security breach than a face in a picture!
Likewise GPS information.

Suggesting that the thumbnail is the only issue is misleading, and
suggesting that EXIF data is any different to any other metadata is
also misleading; there may be an XMP chunk in there, or a zTXt "Raw
profile type iptc" comment!

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.