[png-mng-misc] DRAFT: eXIF 2017-05-28

[Glenn Randers-Pehrson]

png-proposed-eXIF-chunk-2017-05-28.html
DRAFT
eXIF 2017-05-28
http://www.simplesystems.org/png-group/proposals/eXIF
png-proposed-eXIF-chunk-2017-05-28.html
Glenn Randers-Pehrson

This draft differs from the 2017-03-12 draft only in that
the chunk is copy-unsafe (eXIF instead of eXIf).
It competes with and does not supercede the 03-12
draft, which is still active although discussion has
lapsed.

There was at least one person who voted
against eXIf but stated an intention to vote for eXIF.

Is there any hope of finishing this thing?

Glenn

[Cosmin Truta]

Post by Glenn Randers-Pehrson
png-proposed-eXIF-chunk-2017-05-28.html
[snip]

Thank you, Glenn, for coming back with this proposal. I am very happy
about it, I really am.

But please do not make it unsafe to copy.

It is already mentioned in the draft (correctly so) that "the data
should be considered to be of historical value only". This is what one
"no" voter requested to be mentioned for a safe-to-copy chunk, and we
complied accordingly.

Post by Glenn Randers-Pehrson
There was at least one person who voted
against eXIf but stated an intention to vote for eXIF.

Among the "no" votes, one was "qualified no against eXIf" (which I
mentioned in my above paragraph), and one other "unqualified no
against eXIf". So we could (and did) comply to the first one, and we
cannot comply to the second one. We can only hope that the new draft
will make sense for all the past "no" voters.

Post by Glenn Randers-Pehrson
Is there any hope of finishing this thing?

I sure hope so. But I also hope that we can finish this thing and make
it in a form that is going to fly.

As someone who wrote a TIFF/EXIF implementation, however crude, can
attest, an unsafe-to-copy eXIF that ought to be updated when the image
gets updated, is out of the reach of any simple tools, and very
possibly out of the reach of many of the sophisticated ones also.
Those implementations will either choose to grow their implementations
to abnormal sizes in order to handle the hard (and sometimes
impossibly hard) eXIF updates, or choose to discard that eXIF
altogether.

And then the data, which we already stated to be of historical value,
will become data of no value.

I want to build this specification in a way that it passes the final
vote, I really do, but I also want to build it in a way that it flies
(as opposed to a way that goes splat). I reiterate: I would vote "yes"
for any proposal, compressed or uncompressed, with simple headers or
with complicated headers, with ordering constraints or without
ordering constraints, etc. But I would vote "no" for an unsafe-to-copy
proposal, in any form.

Wanna crop an image (e.g. in the way in which pnmcut works)? Or
rotate, or flip horizontally, vertically, etc.? Simple, right? Well,
however simple that may be, forget about updating an unsafe-to-copy
eXIF, for the sake of correctness, because you would have to (#1)
decode the MakerNotes, (#2) recalculate the correct positions, (#3)
re-encode the MakerNotes. Each of these three steps are difficult,
step (#2) is HORRIBLY difficult, and I presume that no implementors
will bother.

If for the most simple image editing operations, an unsafe-to-copy
eXIF would be lost, what would one expect for anything more than that?
I'd rather take a shot at discussing with the "unqualified no against
safe-to-copy" voters, if they're interested in discussing and finding
out why we're doing what we're doing. And if they're not
participating, we did our best to explain why we're doing what we're
doing, and it's only so much that we can do. We should not specify
something that can't actually be implemented for the sole reason to
get more votes.

In conclusion, please revert back to the 2017-03-12 draft, which was
*perfect* from my point of view, and let us keep our fingers crossed.

Sincerely,
Cosmin

[Cosmin Truta]

Post by Cosmin Truta
Wanna crop an image (e.g. in the way in which pnmcut works)? Or
rotate, or flip horizontally, vertically, etc.? Simple, right? Well,
however simple that may be, forget about updating an unsafe-to-copy
eXIF, for the sake of correctness, because you would have to (#1)
decode the MakerNotes, (#2) recalculate the correct positions, (#3)
re-encode the MakerNotes. Each of these three steps are difficult,
step (#2) is HORRIBLY difficult, and I presume that no implementors
will bother.

Oops it's late at night. The paragraph I wrote is not self-contained.
I forgot to mention that step (#2), the one I referred to as "HORRIBLY
difficult", is like that because recalculating the correct positions
of the focus points in the newly-cropped/rotated/flipped image (to
make the whole thing correct for the sake of unsafe-to-copy-ness) is
that horribly difficult. Never mind arbitrary rotations (which make it
that much harder), or lens distortion operations (which make the whole
thing absolutely impossible).

Sincerely,
Cosmin

[Glenn Randers-Pehrson]

Just to be clear, I too greatly prefer eXIf (safe-to-copy) over
eXIF (unsafe-to-copy) because it does a better job of preserving
valuable historical information. Approval of eXIf wouldn't
require applications such as pngcrush/optipng to do anything
new, while eXIF would require them to issue a new version
to handle eXIF as if it were safe-to-copy when it's not
making changes that would render that information
incorrect.

If you like, you may consider the eXIF proposal to be a
strawman designed to resurrect the discussion of eXIf,
which is still an active proposal despite discussion
having lapsed.

Glenn

[Cosmin Truta]

Post by Glenn Randers-Pehrson
Just to be clear, I too greatly prefer eXIf (safe-to-copy) over
eXIF (unsafe-to-copy) because it does a better job of preserving
valuable historical information. Approval of eXIf wouldn't
require applications such as pngcrush/optipng to do anything
new, while eXIF would require them to issue a new version
to handle eXIF as if it were safe-to-copy when it's not
making changes that would render that information
incorrect.

Ok, Glenn, thank you very much for it, but if that's the case, let us
just resurrect eXIf. I don't know what else needs to be added to the
2017-03-12, because everything that needs to be explained is already
explained, correctly, and fully.

If you consider that to be still (possibly) insufficient to the past
"no" voters from whom we haven't heard yet since the past vote, I will
add a more extensive explanation, in form of an article, with test
images. We can link to it from the CFD/CFV, say, as an "additional
information" link. I made past claims about various things, but I will
add actual data to my PNG tech site. (Not now: I'm heading to work,
but I'll get back to it, later this evening or tomorrow evening.)

Post by Glenn Randers-Pehrson
If you like, you may consider the eXIF proposal to be a
strawman designed to resurrect the discussion of eXIf,
which is still an active proposal despite discussion
having lapsed.

I am thrilled to hear that you consider eXIf a still-active proposal,
and I am hoping that, in the not too distant future, we will advance
it to the formal CFD+CFV stages.

TTYL
Cosmin

[Pavel Zlatovratskii]

Ok. After all reviews I choose to prefer safe-to-copy too.

But I think that purely historical safe-to-copy eXIf should be
explicitly forbidden to use any other way, while current eXIF draft
allows it to use EXIF data as property of current image itself.

This includes any kinds of PNG-to-JPEG (or PNG-to-TIFF or PNG-to-WebP)
conversions. And for current eXIF proposal recommendations about fitting
into APP1 looks like suggestions of direct using eXIF chunk as APP1.
Actual eXIF may be used for direct APP1 in some cases, but historical
eXIf never should be used this way.

So no simple PNG-to-EXIF conversion will be allowed for eXIf (I still
doubt that such conversion could be simple enough for eXIF). And vice
versa: no simple EXIF-to-PNG conversion with eXIf as any valuable data
that could be applied to image must be copied to appropriate PNG chunks
(incl. resolution, gamma, change date, software etc..).

Also some values of EXIF are unsafe-to-copy and have no appropriate PNG
chunk: orientation, subject area/location. Not sure about digital zoom
and camera elevation.

Post by Glenn Randers-Pehrson
Just to be clear, I too greatly prefer eXIf (safe-to-copy) over
eXIF (unsafe-to-copy) because it does a better job of preserving
valuable historical information. Approval of eXIf wouldn't
require applications such as pngcrush/optipng to do anything
new, while eXIF would require them to issue a new version
to handle eXIF as if it were safe-to-copy when it's not
making changes that would render that information
incorrect.
If you like, you may consider the eXIF proposal to be a
strawman designed to resurrect the discussion of eXIf,
which is still an active proposal despite discussion
having lapsed.
Glenn
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

[Glenn Randers-Pehrson]

But I think that purely historical safe-to-copy eXIf should be explicitly
forbidden to use any other way, while current eXIF draft allows it to use
EXIF data as property of current image itself.
This includes any kinds of PNG-to-JPEG (or PNG-to-TIFF or PNG-to-WebP)
conversions. And for current eXIF proposal recommendations about fitting
into APP1 looks like suggestions of direct using eXIF chunk as APP1. Actual
eXIF may be used for direct APP1 in some cases, but historical eXIf never
should be used this way.

About simple conversions to/from APP1, we might want to admit the
possiblility that the 6-byte Exif00 might be present (see the most recent
zXIf proposal, which has among the "Recommendations for Decoders"
section that Exif00 might be present, is harmless, and should be skipped/
ignored).

So no simple PNG-to-EXIF conversion will be allowed for eXIf (I still doubt
that such conversion could be simple enough for eXIF).

If the image data has been changed. It is safe to do that when the image
has not changed. I would expect all of the Exif profile to survive a simple
JPEG -> PNG -> JPEG round trip, although it would not bother me if
the JPEG-specific data were to be lost.

And vice versa: no
simple EXIF-to-PNG conversion with eXIf as any valuable data that could be
applied to image must be copied to appropriate PNG chunks (incl. resolution,
gamma, change date, software etc..).
Also some values of EXIF are unsafe-to-copy and have no appropriate PNG
chunk: orientation, subject area/location. Not sure about digital zoom and
camera elevation.

In fact I've added a private "orNT" chunk to ImageMagick/GraphicsMagick
to store image->orientation. I haven't tried to address subject area/location.

Glenn

[Pavel Zlatovratskii]

Post by Glenn Randers-Pehrson

So no simple PNG-to-EXIF conversion will be allowed for eXIf (I still doubt
that such conversion could be simple enough for eXIF).

If the image data has been changed. It is safe to do that when the image
has not changed. I would expect all of the Exif profile to survive a simple
JPEG -> PNG -> JPEG round trip, although it would not bother me if
the JPEG-specific data were to be lost.

In most practical cases you simply don't know if image has been changed
or not.

It is one simple way in PNG: if chunk is unsafe to copy. But it is
subject of discussion: how to make EXIF chunk safe to copy.

[Glenn Randers-Pehrson]

Post by Glenn Randers-Pehrson

So no simple PNG-to-EXIF conversion will be allowed for eXIf (I still doubt
that such conversion could be simple enough for eXIF).

If the image data has been changed. It is safe to do that when the image
has not changed. I would expect all of the Exif profile to survive a simple
JPEG -> PNG -> JPEG round trip, although it would not bother me if
the JPEG-specific data were to be lost.

In most practical cases you simply don't know if image has been changed or
not.
It is one simple way in PNG: if chunk is unsafe to copy. But it is subject
of discussion: how to make EXIF chunk safe to copy.

Yes, we all know that. The problem here is that Exif contains valuable
safe-to-copy information and worthless unsafe-to-copy information, and
we want to preserve the former. We could do that be defining an eXIf
chunk that only contains the safe-to-copy fields, but that involves
decoders having to understand the Exif profile enough to be able
to separate the good from the bad.

I think the explanations in the current eXIf draft are sufficient.

Glenn

[Pavel Zlatovratskii]

Post by Glenn Randers-Pehrson
We could do that be defining an eXIf
chunk that only contains the safe-to-copy fields, but that involves
decoders having to understand the Exif profile enough to be able
to separate the good from the bad.

That was and idea I was talking about from the very beginning: why do we
ever need decoder that's not able to parse data? Even for PNG-to-JPEG...
direct use of eXIf chunk is not thing I support. It looks like
PNG-to-PNG recompression when no ancillary chunks are recognised, but
instead all data between critical chunks copied as-is, like completely
ignore all unsafe-to-copy properties.

To keep metadata correct we must parse them. Or on every processing,
handling their safe/unsafe-to-copy state (eXIF way), or by discarding
all data that could be broken on reading (eXIf way). Never parse EXIF
and believe that it still applicable for image(or even correct)... I
think it's simply too reckless.

[Glenn Randers-Pehrson]

Post by Pavel Zlatovratskii

Post by Glenn Randers-Pehrson
We could do that be defining an eXIf
chunk that only contains the safe-to-copy fields, but that involves
decoders having to understand the Exif profile enough to be able
to separate the good from the bad.

I meant to say "encoders" (the application that creates the eXIf chunk
in the first place).

Post by Pavel Zlatovratskii
That was and idea I was talking about from the very beginning: why do we
ever need decoder that's not able to parse data?

We probably don't, but the eXIf chunk is designed to be simple to
encode. As willem said, KISS (keep it simple, stupid).

Post by Pavel Zlatovratskii
Even for PNG-to-JPEG...
direct use of eXIf chunk is not thing I support. It looks like PNG-to-PNG
recompression when no ancillary chunks are recognised, but instead all data
between critical chunks copied as-is, like completely ignore all
unsafe-to-copy properties.
To keep metadata correct we must parse them. Or on every processing,
handling their safe/unsafe-to-copy state (eXIF way), or by discarding all
data that could be broken on reading (eXIf way). Never parse EXIF and
believe that it still applicable for image(or even correct)... I think it's
simply too reckless.

We already proposed such a chunk, in December 2000. That proposal
(there's a reference to it in the current proposal) understands the TIFF tags
and structure, and converts them to a human readable text format. The
proposal never got any traction (although ImageMagick does something
similar, converting the Exif profile to a stream of tEXt chunks)..

Glenn

[Pavel Zlatovratskii]

eXIf chunk is designed to be simple toencode. As willem said, KISS
(keep it simple, stupid).

Ok. I agree with eXIf chunk written as direct copy of EXIF data. However
I disagree that anyone could rely on such 'raw' data.
I think encoder should be able to parse EXIF if it want to keep
unsafe-to-copy metadata, but it may not parse by cost of loosing
unsafe-to-copy data(as any decoder should discard this data).

I don't think it is possible to keep unsafe-to-copy data within
safe-to-copy chunk and rely on them.

[Cosmin Truta]

I don't think it is possible to keep unsafe-to-copy data within safe-to-copy
chunk and rely on them.

You are correct. This is why we stated: "unless a decoder has
independent knowledge of the validity of the Exif data, the data
should be considered to be of historical value only".

Sincerely,
Cosmin

[Phil Harvey]

I hope we can come to an agreement here because I think this chunk would be very useful.

I prefer safe-to-copy eXIf as well.

I would vote yes for this proposal if I were eligible, but I just joined the group in February. I would even support eXIF, but this would cause problems when trying to preserve potentially useful historical metadata.

- Phil

[Phil Harvey]

Thanks Glenn,

The new draft looks good.

Post by Glenn Randers-Pehrson
About simple conversions to/from APP1, we might want to admit the
possiblility that the 6-byte Exif00 might be present

I don't think this is necessary since the draft specifically states the chunk should begin with "II" or "MM". However, as a test I have implemented this check and it doesn't add much of an extra burden to the decoder, so I don't feel too strongly about this.

- Phil

[Glenn Randers-Pehrson]

Allowing Exif00 to be present but ignorable would have made
the ImageMagick/GraphicsMagick implemation a little
simpler, because those bytes are included in the "image->profile"
for Exif in IM/GM. But skipping them (and restoring them when
recreating image->profile) isn't really a big deal.

Post by Phil Harvey
Thanks Glenn,
The new draft looks good.

Post by Glenn Randers-Pehrson
About simple conversions to/from APP1, we might want to admit the
possiblility that the 6-byte Exif00 might be present

I don't think this is necessary since the draft specifically states the chunk should begin with "II" or "MM". However, as a test I have implemented this check and it doesn't add much of an extra burden to the decoder, so I don't feel too strongly about this.
- Phil
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/png-mng-misc