VOTE YES: eXIf 2017-0119

YES
eXIf 2017-0119
ftp://ftp.simplesystems.org/pub/png-group/documents
png-proposed-eXIf-chunk-2017-0119.html
Greg Roelofs <[email protected]>

While I acknowledge that some of the more recent discussion has brought up
fair points (and, given the likely failure of this vote, I'll vote for its
successor), I'm entirely fine with this proposal as is.  As I noted in my
last vote, I agree with Willem and Rei that the group has become excessively
concerned with minutiae.  Such concern is absolutely appropriate for the
initial spec itself and for major revisions (e.g., an improved compression
engine)--which need precision in order to be implemented correctly and to deal
with backward-compatibility issues--but ancillary chunks do not meet that bar,
particularly when they involve what amounts to a foreign chunk that's been
passed around between other image formats for more than a decade.

That said, I do like John's proposed wording (in the separate discussion thread
today) that encoders may include the whole EXIF chunk as is, and decoders must
ignore the tags that don't make sense (unless explicitly instructed otherwise
by a user, perhaps).  That's simple and pragmatic.

While I'm on the subject of pragmatism, I'll point out (again) that the approval
of fRAC in the PNG specification without _being_ specified was asinine, as
particularly evidenced by the fact that the supposed group of experts to whom
definition of the chunk was entrusted still haven't done so 20 years later--
and, for all I know, they may no longer even exist as a group.  (Certainly
there are none of them still participating in the mailing lists.)  If those
with, ahem, a surpassing fondness for clean, ultra-precise specs want to do
something truly useful, issue a CFD to get rid of that thing. ;-)

I've also seen data suggesting there are lossless compression algorithms with
considerably better performance than not just deflate but also LZMA (xz).
I have not validated such claims on filtered image data, and I don't think
anyone knows what the potential patent risks of some of these algorithms are,
but the possibility of a second compression engine would also be a worthy topic
for spec-related discussion.

Greg

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