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 - is introduced
 by 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')

 by means of adding an additional chunk for each.

 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).

 Note: 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.

 PERMSSN    UID  GID    PACKED    SIZE  RATIO METHOD CRC     STAMP          NAME
---------- ----------- ------- ------- ------ ---------- ------------ -------------
[generic]                 1616    3489  46.3% -lh5- ce11 Mar  9 13:55 IFF-metadata.readme
---------- ----------- ------- ------- ------ ---------- ------------ -------------
 Total         1 file     1616    3489  46.3%            Mar  9 20:56