Localization issue in PNG or EXIF? [Was: EXIF support in PNG]

"On Fri, Jan 13, 2017 at 11:11 AM, Glenn Randers-Pehrson
<[email protected]> wrote:
> The report about the large resolution number in EXIF was on the ImageMagick
> "issues" at github:

[reported output of exiftool]:

> Resolution Unit                 : inches
> X Resolution                    : 28,346
> Y Resolution                    : 28,346
> Resolution Unit                 : Centimeter

This is nothing to do with PNG or EXIF; that stuff is coming from the
XMP.   My exiftool (10.38) doesn't even print those values, probably
because the XMP is invalid (does not match the DTD); see below.

The corresponding values in PNG are stored as 4 byte binary values (no
text involved).  Neither are they stored as text in EXIF.  Here is the
(entire) output of pngdumpmeta --exif for the file in the bug report,
the left is the 'key', the stuff in brackets is the type of the data
followed by the count and the last field (after the :) is the actual
value:

MSB first, 9 entries:
  Exif.Image.XResolution(Rational[1]): 71/1
  Exif.Image.YResolution(Rational[1]): 71/1
  Exif.Image.ResolutionUnit(Short[1]): 2
  Exif.Image.Software(Ascii[12]): GIMP 2.8.16
  Exif.Image.ExifTag(Long[1]): 102
  Exif.Photo.ExifVersion(Undefined[4]): 48 50 49 48
  Exif.Photo.UserComment(Undefined[42]): charset="Unicode" Created with GIMP
  Exif.Photo.FlashpixVersion(Undefined[4]): 48 49 48 48
  Exif.Photo.ColorSpace(Short[1]): 65535

I checked the output of 9 different digital cameras; the resolution is
always stored as a rational.

The problem here is the XMP, which "convert" does not even convert
correctly when it writes the PNG.  Here is the output of jpegtopng
(this is correct).  Again I give it in its entirety (as output by
pngdumpmeta --xmp); non-ASCII has been converted to <U+> notation
(just the BOM in this case).

<?xpacket begin='<U+FEFF>' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

 <rdf:Description xmlns:exif='http://ns.adobe.com/exif/1.0/'>
  <exif:XResolution>28,346</exif:XResolution>
  <exif:YResolution>28,346</exif:YResolution>
  <exif:ResolutionUnit>Centimeter</exif:ResolutionUnit>
  <exif:Software>paint.net 4.0.9</exif:Software>
  <exif:ExifVersion>Exif Version 2.1</exif:ExifVersion>
  <exif:UserComment>Unsupported UNICODE string</exif:UserComment>
  <exif:FlashPixVersion>FlashPix Version 1.0</exif:FlashPixVersion>
  <exif:ColorSpace>Uncalibrated</exif:ColorSpace>
 </rdf:Description>

</rdf:RDF>
</x:xmpmeta>
<?xpacket end='r'?>

File formats should not use localized values and XML does not use them
either.  Anyway, 71DPI is 27.952DPcm; the number above is actually
72DPI!

BTW "Unsupported UNICODE string" is exactly what is there; if you want
you can load the original JPEG into the text editor of your choice and
you will see exactly what is above except that the BOM may come out
weird.

The bug is in whatever put the "," into the number and whatever then
treated it as a valid number.  See here:

http://books.xmlschemata.org/relaxng/ch19-77057.html

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi