Re: CFD: zXIF 2017-0207

I think I meant "shall not use" when I said "shall ignore" but
I agree that it needs to be precisely defined.

The main problem with the Exif profile that I see is that
it contains several types of tags:

1.   tags containing information about the camera.  This
part is historical data that an editor shouldn't change,
and is therefore copy-safe.

2. tags containing information about the picture-taking
conditions, also historical copy-safe data.  includes GPS
info.

3.tags containing information about the scene (subject
location, etc) that must be updated when the image is cropped,
rotated, or resized.  The updating requirements are
explained in the Exif spec, Annex E3.  This is
copy-unsafe, but an application would be allowed
to update it by complying with the requirements of  E3.

4. tags containing information about the image file (strip layout,
compression method, etc.).  These don't have any
meaning when the image is converted to a new
format, but might be of historical value (e.g., was the
original image sub-sampled or not?).  These should
either be copy-unsafe or we could mandate that they
be ignored by decoders and discarded by encoders.

5. tags that replicate existing PNG chunks.  This is
troublesome, when a PNG decoder finds the same
data (or conflicting data) in PNG chunks and in the
Exif profile.  Includes image dimensions, resolution,
gamma, sRGB, etc.  This is copy-unsafe, ignorable,
but we have to allow it in the chunk for the sake of
simple encoders that simply dump an existing Exif
profile into an eXIF chunk.  We should not allow
these to serve as falllbacks when the corresponding
PNG chunks are missing.  In a PNG, no gAMA
chunk means gamma is undefined, and does not
mean fall back on the Exif data; if we were to allow
that, unspecified behavior is unavoidable, as in
the scenario Pavel described earlier.

Ideally, type 1 and 2
information would be written into a copy-safe PNG
chunk (eXIf or zXIf), type 3 stuff would go into
a copy-unsafe PNG chunk (eXIF or zXIF).  Type
4 information should probably be discarded; even
if the image gets converted back to JPEG, the
original JPEG information would be obsolete and
the encoder should write new JPEG format-related tags.
I don't think we want to define two chunks to contain
the Exif profile, so it will have to be copy-unsafe.
.

On Wed, Feb 8, 2017 at 6:20 PM, John Bowler <
[email protected]> wrote:

> 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.
>

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

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc