Short: IFF-EXIF/IPTC/XMP/ICCP Extensions & META Author: info@ar-kleinert.de Uploader: info ar-kleinert de Type: docs/misc Version: 1.6 (15.07.2012) Replaces: docs/misc/IFF-metadata.lha Architecture: generic Previously, the IFF file format supported the following image meta data chunks: ID_NAME // Name ID_AUTH // Author ID_ANNO // Annotation ID_Copy // Copyright by means of separate chunks for each. Corresponding chunk ID definitions are widely known. Now the following - as a consequent logical extension of the previously mentioned definitions - are introduced by SView5 and SView5-Library: ID_EXIF // EXIF Image Meta Data ('EXIF') ID_IPTC // IPTC Image Meta Data ('IPTC') ID_XMP0 // XMP Image Meta Data ('XMP0') ID_XMP1 // XMP Image Meta Data ('XMP1') ID_ICCP // ICC Profile Data ('ICCP') ID_ICCN // ICC Profile Name ('ICCN') ID_GEOT // GeoTIFF Meta Data ('GEOT') ID_GEOF // GeoTIFF Meta Data Flags ('GEOF') by means of adding an additional chunk for each. Furthermore ID_META // indicates metadata-only file ('META') Valid content for these chunks is as follows: 1. EXIF: - same payload as for APP1 JPEG EXIF markers (*) - basically 6 bytes header followed by an encapsulated TIFF container - size limit 64K (inherent), i.e. 65535-4 bytes 2. IPTC: - same payload as for APP13 JPEG PS3 marker, but ONLY allowed PS3 resource block is IPTC (404) - spanning multiple APP13 markers with PS meta data therefore is forbidden (**) - PS3 header is optional (check first 13 bytes and skip first 26 bytes if not present) - size limit 64K (inherent), i.e. 65505 or 65531 bytes 3. XMP: Two flavours are possible. They only differ in their origination, which reflects on their maximum size. flavour 0: - same payload as for APP1 JPEG XMP markers (*) - see http://xml.coverpages.org/XMP-Embedding.pdf - when saving into JPEG, just add the header - only pure XML without header is stored - size limit 64K (inherent), i.e. 65502 bytes flavour 1: - same payload as for 'tXMP' PNG chunk or for 'iTXt' chunk with content type "XML:com.adobe.xmp" - see http://xml.coverpages.org/XMP-Embedding.pdf - no significant size limit - use this only if you need more than the 64K supported by JPEG - only pure XML without header is stored - size limit 2-4 GB (*) may co-exist in JPEG files (**) other PS data should be kept in additional APP13 markers; still a pure APP13 IPTC block could occur more than once The reasons for enforcing the JPEG-style format are as follows: - lowest common denominator - self-contained (no offsets pointing outside) - chunks can easily be moved 1:1 between JPEG and IFF files - direct parsing support available via libexif, libiptcdata and different XMP/XML toolkits - direct creation support available via the same mentioned libraries - handy size, reasonable limit (64K) The reason for also allowing PNG-style XMP: - XMP is going to replace EXIF and IPTC fully sooner or later - putting XML-encoded binary data or longer textual descriptions into XML tags will easily bloaten the content across the 64K border - future file formats will not be as limited as JPEG with its APP marker size Similar as with JPEG it is perfectly legal to have more than one EXIF, IPTC and XMP0 chunk per file (XMP1 may occur only once) but it is also legal that applications only parse the first chunk of a given type (parsing metadata is optional anyway). 4. ICC (ICCP & ICCN) A standard ICC profile is just embedded as-is into a "ICCP" chunk. Optionally, its name may be embedded into a second chunk ("ICCN"). Note, that for files which do not contain an ICC profile there is the option to utilize the new GAMA (Gamma) and CHRM (Chromacities) or "SRGB" (sRGB Rendering Intent) chunks. These are defined just as for PNG. Details are in Aminet:docs/misc/ILBM64.zip 5. GeoTIFF (GEOT & GEOF) GeoTIFF is a TIFF-based standard for geospatial metadata. The actual TIFF data should be 'degenerate' (similar to EXIF) in such a way that no real image data is contained therein, but only meta tags. If an image is contained, it should be merely a placeholder (e.g. 1x1 pixel). When being contained as metadata within a JPEG2000 file there is a specific UUID defined for that purpose and even further restrictions are applicable (please refer to the respective standard draft by Michael P. Gerlek). Purpose of the GEOT chunk is to carry the pure GeoTIFF file content as raw data (either starting with 'II' or 'MM'). Purpose of the GEOF chunk is to indicate the origin of the GEOT data and thus to define an possible additional constraints (e.g. only 'II' permitted for JP2 origin). GEOF content is of type chunk ID (4 bytes, ASCII) with currently the following IDs being defined: 'JFIF' (for any JPEG origin) => 64k restriction applicable 'JP2K' (for any JPEG2000 flavour) => respective UUID restrictions applicable 'PNG ' (for PNG) => no known restrictions 'TIFF' (for any TIFF source) => no known restrictions 'GEOT' (for a self-contained GeoTIFF source) => no known restrictions 'RGFX' (for any TIFF/GeoTIFF compliant source not having any other GEOF type carried within the RGFX file) => no known restrictions xxxx (other IFF file source; same as RGFX) => no known restrictions ' ' (unknown source) => no known restrictions When encountering an unknown GEOF content it is safe to assume it to be equal to ' ' and save that way again during a file conversion. 6. IFF-META If you just want to save the metadata and nothing else, it is recommended to put the forementioned chunks into a FORM using ID_META as type.