Why does Exiv2 write to ImageIFD?
Added by Mikayel Egibyan over 5 years ago
Hi,
When writing a meta information into a PNG file, it appears that Exiv2 adds to "Raw profile type exif" -> encoded exif data into the PNG textual information(1). Why is it done? Is there a way not to do that?
Thanks,
Mikayel
Replies (2)
RE: Why does Exiv2 write to ImageIFD? - Added by Robin Mills over 5 years ago
I believe the exif data is conventionally stored in an tEXt chunk, although I don't know if this is part of a standard. Here's a discussion: http://stackoverflow.com/questions/9542359/does-png-contain-exif-data-like-jpg
Apparently imagemagic use the tEXt chunk and exiv2 implements that. I have taken my favourite test file http://clanmills.com/Stonehenge.jpg and exported it to PNG on the Mac using Preview.app. The metadata has been written as XMP in an iTXt chunk.
You can dump the structure of a PNG with $ exiv2 -pS or -pR path. For Example:
736 rmills@rmillsmbp:~/clanmills $ exiv2 -pR ~/gnu/exiv2/trunk/test/data/imagemagick.png
STRUCTURE OF PNG FILE: /Users/rmills/gnu/exiv2/trunk/test/data/imagemagick.png
address | index | chunk_type | length | data
8 | 0 | IHDR | 13 | ...@........
33 | 1 | iCCP | 1404 | icc..x...i8.......af\...w_3...+
1449 | 2 | sBIT | 3 | ...
1464 | 3 | zTXt | 87 | Software..x...A.. ......B....}.N
Software: digiKam 0.9.0-svn ( libpng version 1.2.8 - December 3, 2004 (header) )
1563 | 4 | tEXt | 24482 | Raw profile type exif..exif. 1
STRUCTURE OF TIFF FILE (MM): MemIo
address | tag | type | count | offset | value
10 | 0x0100 ImageWidth | SLONG | 1 | 320 | 320
22 | 0x0101 ImageLength | SLONG | 1 | 211 | 211
34 | 0x010f Make | ASCII | 18 | 146 | NIKON CORPORATION
46 | 0x0110 Model | ASCII | 10 | 164 | NIKON D70
58 | 0x0112 Orientation | SHORT | 1 | 65536 | 1
70 | 0x011a XResolution | RATIONAL | 1 | 174 | 174/0
82 | 0x011b YResolution | RATIONAL | 1 | 182 | 182/0
94 | 0x0128 ResolutionUnit | SHORT | 1 | 131072 | 2
106 | 0x0131 Software | ASCII | 18 | 190 | digiKam-0.9.0-svn
118 | 0x0132 DateTime | ASCII | 20 | 208 | 2006:02:04 16:09:30
130 | 0x8769 ExifTag | LONG | 1 | 228 | 228
STRUCTURE OF TIFF FILE (MM): MemIo
address | tag | type | count | offset | value
230 | 0x829a ExposureTime | RATIONAL | 1 | 546 | 546/0
242 | 0x829d FNumber | RATIONAL | 1 | 554 | 554/0
254 | 0x8822 ExposureProgram | SHORT | 1 | 262144 | 4
266 | 0x8827 ISOSpeedRatings | SHORT | 1 | 13107200 | 200
278 | 0x9003 DateTimeOriginal | ASCII | 20 | 562 | 2006:02:04 16:09:30
290 | 0x9004 DateTimeDigitized | ASCII | 20 | 582 | 2006:02:04 16:09:30
302 | 0x9201 ShutterSpeedValue | RATIONAL | 1 | 602 | 602/0
314 | 0x9202 ApertureValue | RATIONAL | 1 | 610 | 610/0
326 | 0x9204 ExposureBiasValue | RATIONAL | 1 | 618 | 618/0
338 | 0x9205 MaxApertureValue | RATIONAL | 1 | 626 | 626/0
350 | 0x9208 LightSource | SHORT | 1 | 0 | 0
362 | 0x9209 Flash | SHORT | 1 | 0 | 0
374 | 0x920a FocalLength | RATIONAL | 1 | 634 | 634/0
386 | 0x927c MakerNote | UNDEFINED | 6989 | 642 | ...
398 | 0xa002 PixelXDimension | SLONG | 1 | 320 | 320
410 | 0xa003 PixelYDimension | SLONG | 1 | 211 | 211
422 | 0xa217 SensingMethod | BYTE | 1 | 33554432 |
434 | 0xa301 SceneType | BYTE | 1 | 16777216 |
446 | 0xa402 ExposureMode | SHORT | 1 | 0 | 0
458 | 0xa403 WhiteBalance | SHORT | 1 | 0 | 0
470 | 0xa405 FocalLengthIn35mmFilm | SHORT | 1 | 4915200 | 75
482 | 0xa406 SceneCaptureType | SHORT | 1 | 0 | 0
494 | 0xa408 Contrast | SHORT | 1 | 0 | 0
506 | 0xa409 Saturation | SHORT | 1 | 0 | 0
518 | 0xa40a Sharpness | SHORT | 1 | 0 | 0
530 | 0xa40c SubjectDistanceRange | SHORT | 1 | 0 | 0
END MemIo
7633 | 0x0103 Compression | SHORT | 1 | 393216 | 6
7645 | 0x0201 JPEGInterchangeFormat | LONG | 1 | 7673 | 7673
7657 | 0x0202 JPEGInterchangeFormatLeng | LONG | 1 | 4376 | 4376
END MemIo
26057 | 5 | tEXt | 471 | Raw profile type iptc..iptc.
26540 | 6 | IDAT | 8192 | x...Y.$Wv&v.{.{l.T.......[w.=m$G
34744 | 7 | IDAT | 8192 | .4X.y.AR...4....:Ue..U.|1..:..D.
42948 | 8 | IDAT | 8192 | 'g.!... ...n...s..Jdz.........6.
51152 | 9 | IDAT | 8192 | ........k....CY/75I..u;.. .z...}
59356 | 10 | IDAT | 8192 | .f>..]....UKqD2s.(.q....=x.l.\V.
67560 | 11 | IDAT | 8192 | .i.{!!B0...C!4.p..`D g`.........
75764 | 12 | IDAT | 8192 | .*.].4..Q..}(9...S0&.......T.9.+
83968 | 13 | IDAT | 8192 | ..k...6....g.1..}.].&.H........
92172 | 14 | IDAT | 8192 | .j..S.........z..!U.G0*.m%..09<,
100376 | 15 | IDAT | 8192 | .....t.>!.....6^.<..;..?$I..M.9
108580 | 16 | IDAT | 8192 | W.&5.5J........FW`....3.N.9Pk;.s
116784 | 17 | IDAT | 8192 | .....d.z".`...v=g-..-.c8...Z.5.x
124988 | 18 | IDAT | 8192 | .."...o<&."....1M....1&. ..5....
133192 | 19 | IDAT | 8192 | k........!..B*.....\*.(!..0.s..B
141396 | 20 | IDAT | 3346 | .Y.L@I$M.Z[.0A ...K#.t.0+.G(.jX.
144754 | 21 | IEND | 0 |
737 rmills@rmillsmbp:~/clanmills $ You can see that the 'Raw profile type exif' chunk contains an embedded TIFF structure which defines the metadata.
I'm not sure that there's anything in libexiv2 to say "read this PNG and ignore tEXt/exif chunk", however the chunk can be easily removed in a script using exiv2 -pS to locate the chunk. Then use utility dd to rewrite the file minus that chunk.
Perhaps you could explain your situation/puzzle and I'll be able to give you better assistance.
RE: Why does Exiv2 write to ImageIFD? - Added by Robin Mills over 5 years ago
I've just realised that you are talking about writing the PNG file. I believe writeMetadata() for png files will write the tEXt chunk described above.
I didn't write exiv2, so I don't know why it is done this way. The mostly likely explanation is "because it works". If you have a proposal for a different way in which to store the metadata, please let me know. It's obvious that the metadata can be represented in XMP which is also stored in a different tEXt chunk. You can delete the exif metadata in an image and "Raw profile type exif" will not be written.
I've had a look at Phil's Exiftool Documentation concerning PNG: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/PNG.html#TextualData The page says Some of the tags below are not registered as part of the PNG specification, but are included here because they are generated by other software such as ImageMagick. So our friend imagemagick seems to be the reason for this. It would also seem that we could write the Exif data into 'Raw profile type exif' or 'Raw profile type APP1' : http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html
However, you're asking the wrong question! I don't know why libexiv2 writes the data this way and I don't believe you can cause him to write it differently.
Perhaps you can explain how and why you'd like the metadata written in a different format and I'll try my best to answer.