VOTE NO: eXIf 2017-0119
Pavel Zlatovratskii <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <[email protected]> |
NO
eXIf 2017-0119
ftp://ftp.simplesystems.org/pub/png-group/documents
png-proposed-eXIf-chunk-2017-0119.html
Pavel Zlatovratskii <[email protected]>
At least colourspace data have special way to handle: absence of chunks
is 'output as-is'. So 'Where conflicting information is present in other
chunks in the stream that data shall be assumed to be correct unless it
can be determined to be incorrect.' is not enough.
My previous comment about 'endless gamma' was missed so I try to provide
more detailed explanation:
1) Alice and Bob have same Jpeg/EXIF file with same gamma = 2.2
2.1) Alice recode jpeg to PNG trying to achieve best compatibility so
she use both eXIf and gAMA chunks.
2.2) Bob use Willem's pngexif tool, which write only eXIf (that's not
Willem's fault! proposal have no word about this!)
3) Both PNG goes to Charles which publish them to web. Charles knows
nothing about eXIf, but he knows that some browsers and image viewers
doesn't process gAMA. So he runs 'truepng /g1'(apply and remove gamma)
on all his files.
4) Now if we give Alice's file to Bob and ask him to recode it back to
Jpeg/EXIF he ignore absence of gAMA chunk(he doesn't write it) and write
gamma-applied Jpeg with original meta.(gAMA is absent so there is no
conflict mentioned in proposal)
5) Repeat this scenario again and again and gamma will be applied again
and again.
In fact after step 3 we already have different images with same
metadata. So we need some 'meta-metadata' to find out if eXIf could be
used as source of colourspace data.
Pavel Zlatovratskii scondo-JGs/[email protected]; [email protected]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot