Re: DRAFT: eXIF 2017-05-28

On 29 May 2017 at 20:07, Glenn Randers-Pehrson wrote:
> 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.

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

> 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

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