Feature #467
Interface to access (Exif) metadata in binary form
0%
Description
The Exif data in a Jpeg image is in an "Exif APP1 segment". This is convenient because it contains all Exif data in a small block of memory (up to 64kB).
Various applications need an interface in Exiv2 to access such a binary Exif representation. Currently this interface is provided by ExifData::load / ExifData::copy (and similarly by IptcData::load / IptcData::copy for IPTC)
Issues with this current implementation:
1) It is specific to Jpeg.
2) It is in the wrong class (see bug #405), ExifData and IptcData shouldn't do parsing/writing of data from/to specific formats
3) There are a few slightly different valid requirements with regards to the beginning of this data block, e.g.:
a) start with the APP1 signature (see bug #465)
b) start with the Exif string (libjpeg)
c) start with the TIFF header (current implementation)
Related issues
History
Updated by Andreas Huggel over 13 years ago
With the introduction of the new TIFF parser, the ExifData::load / ExifData::copy methods moved to ExifParser::decode and ExifParser::encode.
There is still a need to access the binary representation of the Exif data (starting with the TIFF header) of images in JPEG and other formats which have a similar Exif data block.
Updated by Robin Mills about 5 years ago
- Target version changed from 1.0 to 0.28
I'm moving this issue to v0.27. The image->printStructure() interface provides this interface for ICC profiles and I'm confident we can add a kpsPrintStructure enumerator to export binary information to a stream. In v0.26, the user can use $ exiv2 -pX foo.xxx and $ exiv2 -pC foo.xxx to extract XMP and ICC Profiles from an image. I believe it's straightforward to extend this to implement options such as -pE which would create a TIFF from the Exif metadata in an image.