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