IFF-metadata 1.6 (15.07.2012)

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.