Re: CFD: zXIF 2017-0207

On Tue, Feb 7, 2017 at 8:56 PM, Glenn Randers-Pehrson <[email protected]> wrote:
> This paragraph, admittedly, is not as clear as I'd like.

That is the challenge; clearly stating exactly what tags are permitted
and when they are permitted.
>
>     Encoders may write all known Exif tags in the zXIF chunk;

Ok, there are two issues here; what encoders do and what decoders do.
I agree it is possible to shift all the work to the decoder (which is
the gist of what you are suggesting) and that this is perhaps the
simplest thing.  I just want to be sure this is what people want ;-)

So, I think an encoder should not write a *new* tag which is clearly
inapplicable.  The issue is not about encoders writing garbage; that
does not need to be permitted.  The issue is, rather, whether encoders
are permitted to *copy* garbage.  The above sentence apparently allows
an encoder to write anything and, unfortunately, that would trump all
the restrictions in the PNG spec itself (expressed and implied).

Is it even reasonable to allow an encoder to copy a tag that is no
longer applicable?  Devils' advocate (or maybe this is Angels'
advocate):  If I'm converting JPEG to PNG do I really have to be
permitted to copy stuff that is entirely JPEG specific?  Has software
engineering reached a point where an ISO standard explicitly permits
garbage in the file format?

If it *is* reasonable to permit this at all the wording only needs to
be such that it can only be exploited by a really dumb transcoder, and
then probably only in the JPEG case.  (Remember the TIFF format
includes RAW and that cannot be encoded in PNG without a critical
chunk; we do not want to open the door any wider for that than ISO-PNG
already permits.)

However, the decoder rules that follow make this moot since the
decoder becomes the guardian:

>however,
>     any other tags which might be present in the zXIF chunk shall be
>     ignored by decoders,

It took me three reads of that to work out what it is saying; encoders
may write unknown tags, decoders must discard unknown tags.  Ok, but
is that what you meant to say?  It says that a decoder must discard
anything it doesn't understand (which is fine) *and* that it may only
understand tags in CIPA 2016 (Pavel's correction).  I don't think that
was intended.

>and tags containing information relevant only
>     to the original JPEG or TIFF encoding shall be ignored by decoders.

Again I have to ask if you really mean that.  The word "ignored" has a
clear meaning in English; it precludes any action based on the thing
being ignored and in this case that means the decoder cannot either
copy the tag or reveal the information to the application or user.

So what happens is that a JPEG or TIFF decoder can write stuff into a
PNG that any reader of that PNG is explicitly disallowed from even
seeing.

That does work, and it is easier to both implement and specify that
what I was going to try to do.  I'm also fine with it; I just want to
be sure you really meant it!  A PNG decoder (absent a critical chunk)
SHALL not decode tags which only apply to JPEG or TIFF.

Well, in fact, the rule should be that a PNG decoder shall only decode
image-related tags that apply directly to the (PNG) format of the
image data.  It must skip anything else.

Further a PNG editor must only preserve chunks that it recognizes and
are applicable.  (The editor is a decoder followed by an encoder, so
it must enforce the decoder rules).

This is simple; regardless of my arguments about the encoder part a
decoder is responsible for checking the EXIF chunk and may only use or
retain tags that it understands and knows to be applicable.

I admit it's quite a neat approach; a decoder knows what it
understands so the need to identify the safe/unsafe nature of EXIF
tags disappears.

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

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