Re: CFD: eXIf 2017-05-31
Cosmin Truta <[email protected]> Thu, 8 Jun 2017 13:54:56 -0400
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAAoVtZw8z-XqX+KofqyKG5omTvBQW_18cH+40re0co+GeTnVpQ@mail.gmail.com> |
Phil wrote: > In general, the encoder knows nothing about what the EXIF will be used for. It is the decoder that knows this. The encoder should know where the information is coming from (eg. JPEG or TIFF image), but it may not know the ultimate destination, so I see why it should be its responsibility for limiting the data size. It is for that reason that the *encoder* is recommended not to write EXIF chunks larger than 64KB, in general. One cannot know if the encoded PNG is to be later converted to JPEG, or not. Conversely, if it's a specific PNG-encoding application with a specific applicability, that just happens to know that its encoded PNGs won't need to be later converted to JPEG (or its user does, and the application gives the user that choice), then that application may conscientiously choose not to follow that recommendation. Glenn wrote: > Strictly speaking (which we always do here), it's about image editors > that decode a PNG and write a JPEG. Not exclusively. It can be about command-line tools also. And can be about something else-to-PNG (e.g. Raw-to-PNG) converter that may choose to embed a thumbnail and a preview image (thus exceeding the 64KB limit), or to embed a thumbnail only (staying within the 64KB limit). > The PNG decoder is free to read an eXIf chunk that's over 64k, but the > editor then must decide > what to do about it (e.g., removing the thumbnail). The thumbnail's existence has never been an issue in the JPEG world, and shouldn't be an issue in the PNG world, either. The total size is still well under 64KB with the thumbnail included. I'm thinking about other applicability domains. In JPEG, I found that the preview image is outside of the EXIF chunk, which is good because it keeps the size under 64KB (which is a must), but it's bad because the pointer to the preview image is outside the EXIF chunk. So to the PNG image, that would be a dangling, invalid pointer. Therefore, the PNG encoder may choose: is it going to be a typical small standard-sized EXIF with small standard-sized thumbnail? Or is it going to be larger-than-standard EXIF with either a larger-than-standard thumbnail or a correctly-embedded, with correctly-linked internal preview image? This is to be decided at encoding time, in the PNG-encoding application, which may be (but does not need to be) an image editor. The recommendation is well targeted at all editors that don't know what's going to happen to the encoded images, and, being a recommendation (not a requirement) may be superseded in the presence of specific domain knowledge. Sincerely, Cosmin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot