Re: CFD: eXIf 2017-05-31

Beyond the importance of the _informative_ statement "EXIF chunks no
larger than 2^16-1 bytes are desirable, for easy interchange with the
JPEG format", there is the even more important _normative_ statement
"EXIF chunks no larger than 2^31-1 bytes are valid".

Therefore, this should have remained where it was as of 2017-05-31,
in the normative section.

If the old paragraph from 2017-05-31 cannot be restored (with or
without the word "should" instead of "must") , I propose the following
formulation.

Remove:
- While the PNG specification allows the chunk size to be as large as
- 2^31-1 bytes, encoders should be aware that, if the Exif profile is
- converted to JPEG, the total length of the Exif data (the sum of the
- lengths of the Exif attributes IFD, the GPS IFD, the thumbnail IFD,
- and the TIFF header) must not exceed 64 kbytes, because it must fit
- into a JPEG APP1 marker.

Add:
+ There are no size constraints upon the eXIf chunk size beyond those
+ imposed by the PNG specification, i.e. maximum 2^31-1 bytes. However,
+ applications may optionally impose a size constraint of maximum
+ 2^16-1 bytes, for easy interchange with the JPEG format.

In my proposal above, "applications" can mean PNG encoders that may opt
not to write larger eXIf chunks, or PNG decoders that may opt not to
read them, or both. I don't consider it necessary to reiterate that it
is about the TIFF header, and EXIF attributes IFD, and GPS IFD, and
thumbnail, and whatever else. It's neither normative (considering the
fact that the text is in the normative section), nor is it our job to
describe what should go inside a JPEG container.

Phil Harvey wrote:

> If you can't agree, then maybe the wording can be changed to avoid
> mentioning either the encoder or decoder.

Thank you, Phil, I highly appreciate you saying that.

Let us all take a step back and realize that we were about to start
another argument, for the wrong reason.

There is no right or wrong answer on whether this responsibility
belongs to the PNG encoder, or to the PNG decoder. (Actually, there
is a right answer: the responsibility belongs to the _JPEG_ encoder.)

Imagine a 10 gigapixel PNG image, containing a 1 megabyte EXIF chunk
with a 10 megapixel preview. This should be entirely possible for
the PNG format to handle. In this example, neither the image, nor
the EXIF chunk can be encoded to JPEG, because of JPEG format limits.
It would be ridiculous to argue on whether the responsibility of
reconciling the image size with the JPEG format should generally belong
to the PNG encoder (which produced the 10 gigapixel image), or to the
PNG decoder (which consumes the same 10 gigapixel image). It should be
established on a case-by-case basis at the implementation level.

It would be just as ridiculous to have the same argument, but on the
topic of the 1 megabyte EXIF chunk instead of the 10 gigapixel image.

JPEG encoders may very well receive very large images (and very large
EXIF chunks) from various sources, be it a PNG-to-JPEG converter,
or a TIFF-to-JPEG or WebP-to-JPEG converter, or an image stitching
process, or anything else possible. All of these JPEG encoders have
the same responsibilities with regard to the JPEG format limitation.

In conclusion, it should not be a "recommendation for PNG decoders"
under the consideration that a PNG-to-JPEG converter is a PNG decoder.
Instead, it should be a "requirement for JPEG encoders", given that a
PNG-to-JPEG converter is a JPEG encoder just as much as it is a PNG
decoder. The same logic applies to a TIFF-to-JPEG or a WebP-to-JPEG
converter. But more importantly, it should be an issue outside of
the scope of the PNG specification.

We should stop disagreeing ASAP on this issue, and restore the clock
towards the soon-to-come CFV.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot