Re: CFD: eXIf 2017-06-10

On 9 June 2017 at 11:49, Glenn Randers-Pehrson wrote:
> CALL for DISCUSSION
> eXIf 2017-06-10
> ftp://ftp.simplesystems.org/pub/png-group/documents/eXIf/
> png-proposed-eXIf-chunk-2017-06-10.html
> Glenn Randers-Pehrson <[email protected]>
>
> also available at
> http://www.simplesystems.org/png-group/proposals/eXIf/png-proposed-eXIf-chunk-2017-06-10.html

Hi,

The 2017-06-10 edition of the draft is very good. I would like to make
a suggestion to make it better, if only a little. (I emphasize on
_suggestion_, because I would vote "yes", regardless whether my
suggested change gets accepted or not.)

I suggest moving the 2nd bullet point from the section "eXIf
Recommendations for Decoders", to a separate section called "eXIf
General Recommendations", or "eXIf Interoperability Considerations",
or something else that is neither specifically "for decoders", nor
"for encoders", nor "for editors", nor for any other specific category
of implementations.


== eXIf Interoperability Considerations ==
While the PNG specification allows the chunk size to be as large as
2^31-1 bytes, application authors should be aware that, if the Exif
profile needs to be interoperable with the JPEG format, the total
length of the eXIf chunk data may need to be adjusted to not exceed
2^16-9 bytes, so it can fit into a JPEG APP1 (Exif) segment.
==

[*] Note that I called it a "JPEG APP1 segment", because it's the
segment, not the marker, that we're talking about. The APP0, APP1,
..., APP15 markers in JPEG are like chunk headers and signatures in
PNG; but we care about the JPEG segment, which is like the PNG chunk
data.


Consider the current draft 2017-06-10.

In a specific way, the specifically-targeted use case of PNG-to-JPEG
transcoding makes it a good recommendation for expert developers, and
a bad recommendation for casual developers, which is the opposite of
how a recommendation should be. Casual developers should be the ones
to be safe following it, while the experts supposedly know already
what they're doing.

A simple PNG-to-JPEG transcoder should (1) fetch the pixels from the
PNG decoder and send them to the JPEG encoder; (2) fetch the ICCP data
(if any) from the PNG iCCP decoder and send it to the JPEG encoder;
(3) fetch the EXIF data (if any) from the PNG eXIf decoder and send it
to the JPEG encoder; (4) fetch the XMP data (if any) and ... you get
the idea. If (1a) the image height or width exceeds 64KB, then fail;
if (2a) the ICCP data size exceeds 64KB, then fail; if (3a) the EXIF
data size exceeds 64KB ... you get the idea.

A student working on a homework assignment should be doing something
like this. An expert developer, on the other hand, would (1b)
downscale the PNG image to not exceed 2^16-1 pixels per dimension, if
the user options allow it; ...; (3b) adjust the EXIF to not exceed
2^16-9 bytes, if the user options allow it...

I see the steps (1b) and (3b) perfectly normal for a transcoding
implementation as elaborate as ExifTool, but overkill for a casual
implementation.

In a more general way, both the PNG encoders and the PNG decoders
alike should consider this. It should be normal for a sophisticated
image editor to consider producing a small EXIF datastream, so that a
PNG decoder should not need to decode then re-encode the EXIF, thus
working twice as hard (and with a twice as large EXIF implementation
to match).

There are precedents to this practice in the world of multimedia. For
example, the LAME MP3 encoder has the option --strictly-enforce-ISO,
disabled by default for audio quality reasons, but to be enabled by
the user if the intended target is some old hardware player. For
another example, the baseline JPEG standard supports chroma samplings
like 4:1:1, but many JPEG encoders don't bother producing such
streams, because (among other things) many hardware JPEG decoders
don't support anything beyond 4:4:4, 4:2:2 and 4:2:0. Software
decoders can be updated, but it's different for hardware.

Speaking of the PNG-to-JPEG use case, and of hardware, there isn't
even a need to restrict the recommendation to this use case. I can
imagine hardware EXIF circuitry, limited by design to 64KB due to its
JPEG applicability, which is now retrofitted to a PNG-processing
machinery. Yes, fitting the data into a JPEG APP1 segment is still
under consideration, but there is no JPEG datastream writing anymore.
Moreover, it is unreasonable to expect the hardware PNG decoder to
take care of adjusting the EXIF chunk data for the sake of the EXIF
circuitry.

The JPEG interoperability considerations should be decided on a
case-by-case basis at the implementation level, and the standard
should make no specific recommendations in either direction.

Sincerely,
Cosmin

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