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