Re: DRAFT: eXIf 2017-0210

Cosmin Truta <[email protected]> Fri, 10 Feb 2017 08:32:13 -0500
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAAoVtZwHTqdxVz=X=PaakuUvi5Ebw_v_yBs8DxAW00rtVbEoVg@mail.gmail.com>
I like it.

> There is no expectation that any thumbnails present in the Exif profile
> have been updated (or have not been updated) if the main image was changed.

This is a good clarification, to appease the people who oppose the
proposal on the grounds that EXIF data should have been
unsafe-to-copy.

Perhaps move this clarification into the section "eXIf Recommendations
for Decoders"? The "no expectation" clause applies to decoders only,
in my opinion. In addition, an EXIF-enabled encoder may very well
choose to update the thumbnails.

Sincerely,
Cosmin

On 10 February 2017 at 07:30, Glenn Randers-Pehrson <[email protected]> wrote:
> DRAFT
> eXIf 2017-0210
> http://www.simplesystems.org/png-group/proposals/eXIf/png-proposed-eXIf-chunk-2017-0210.html
> Glenn Randers-Pehrson
>
> In hopes of obtaining consensus on a proposed eXIf chunk, I present this DRAFT
> for consideration and discussion.  If and when it seems appropriate
> I'll issue an
> official CFD to start the two-week countdown to the call for vote.
>
> The guts of this proposal are:
>
> The data segment of 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, length, and the "Exif ID code" described in 4.7.2(C), i.e.,
> "Exif", NULL, padding byte, are not included.  It begins
> with either "II" or "MM", depending upon the byte order used.
>
> There are no ordering constraints upon the position of the eXIf beyond those
> imposed by the PNG specification, i.e., if present, the eXIf chunk may
> appear anywhere between the IHDR and IEND chunks except between IDAT
> chunks.
>
> The eXIf chunk contains metadata concerning the original image data.
> If the image has been edited subsequent to creation of the Exif profile,
> This data might no longer apply to the PNG image data.  It is beyond
> the scope of this specification to resolve potential conflicts between
> data in the eXIf chunk and in other PNG chunks, to include other eXIf
> chunks.  It is recommended that unless a decoder has independent knowledge
> of the validity of the Exif data, the data should be considered to be of
> historical value only.
>
> There is no expectation that any thumbnails present in the Exif profile
> have been updated (or have not been updated) if the main image was changed.
>
> Image editing applications should consider Paragraph E.3 of the Exif
> Specification (CIPA DC-008, Exchangeable image file format for digital
> still cameras), which discusses requirements for updating Exif data when
> the image is changed.  Encoders should follow those requirements, but
> decoders should not assume that it has been accomplished.
>
> ------------------------------------------------------------------------------
> 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