#include <exif.hpp>
Static Public Member Functions | |
ByteOrder | decode (ExifData &exifData, const byte *pData, uint32_t size) |
Decode metadata from a buffer pData of length size with binary Exif data to the provided metadata container. | |
WriteMethod | encode (Blob &blob, const byte *pData, uint32_t size, ByteOrder byteOrder, const ExifData &exifData) |
| |
void | encode (Blob &blob, ByteOrder byteOrder, const ExifData &exifData) |
Encode metadata from the provided metadata to Exif format. |
|
Decode metadata from a buffer pData of length size with binary Exif data to the provided metadata container. The buffer must start with a TIFF header. Return byte order in which the data is encoded.
|
|
Encode metadata from the provided metadata to Exif format. Encode Exif metadata from the ExifData container to binary Exif format in the blob, encoded in byteOrder. This simpler encode method uses "intrusive" writing, i.e., it builds the binary representation of the metadata from scratch. It does not attempt "non-intrusive", i.e., in-place updating. It's better to use the other encode() method, if the metadata is already available in binary format, in order to allow for "non-intrusive" updating of the existing binary representation. This is just an inline wrapper for ExifParser::encode(blob, 0, 0, byteOrder, exifData).
|
|
The original binary Exif data in the memory block pData, size is parsed and updated in-place if possible ("non-intrusive" writing). If that is not possible (e.g., if new tags were added), the entire Exif structure is re-written to the blob ("intrusive" writing). The return value indicates which write method was used. If it is Encode is a lossy operation. It attempts to fit the Exif data into a binary block suitable as the payload of a JPEG APP1 Exif segment, which can be at most 65527 bytes large. Encode omits IFD0 tags that are "not recorded" in compressed images according to the Exif 2.2 specification. It also doesn't write tags in groups which do not occur in JPEG images. If the resulting binary block is larger than allowed, it further deletes specific large preview tags and unknown tags. The operation succeeds even if the end result is still larger than the allowed size. Application should therefore always check the size of the blob.
|