Provided by: libimage-exiftool-perl_12.76+dfsg-1_all bug

NAME

       Image::ExifTool::MIE - Read/write MIE meta information

SYNOPSIS

       This module is used by Image::ExifTool

DESCRIPTION

       This module contains routines required by Image::ExifTool to read and write information in MIE files.

WHAT IS MIE?

       MIE stands for "Meta Information Encapsulation".  The MIE format is an extensible, dedicated meta
       information format which supports storage of binary as well as textual meta information.  MIE can be used
       to encapsulate meta information from many sources and bundle it together with any type of file.

   Features
       Below is very subjective score card comparing the features of a number of common file and meta
       information formats, and comparing them to MIE.  The following features are rated for each format with a
       score of 0 to 10:

         1) Extensible (can incorporate user-defined information).
         2) Meaningful tag ID's (hint to meaning of unknown information).
         3) Sequential read/write ability (streamable).
         4) Hierarchical information structure.
         5) Easy to implement reader/writer/editor.
         6) Order of information well defined.
         7) Large data lengths supported: >64kB (+5) and >4GB (+5).
         8) Localized text strings.
         9) Multiple documents in a single file.
        10) Compact format doesn't squander disk space or bandwidth.
        11) Compressed meta information supported.
        12) Relocatable data elements (ie. no fixed offsets).
        13) Binary meta information (+7) with variable byte order (+3).
        14) Mandatory tags not required (an unnecessary complication).
        15) Append information to end of file without editing.

                                 Feature number                   Total
            Format  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15   Score
            ------ ---------------------------------------------  -----
            MIE    10 10 10 10 10 10 10 10 10 10 10 10 10 10 10    150
            PDF    10 10  0 10  0  0 10  0 10 10 10  0  7 10 10     97
            PNG    10 10 10  0  8  0  5 10  0 10 10 10  0 10  0     93
            XMP    10 10 10 10  2  0 10 10 10  0  0 10  0 10  0     92
            AIFF    0  5 10 10 10  0  5  0  0 10  0 10  7 10  0     77
            RIFF    0  5 10 10 10  0  5  0  0 10  0 10  7 10  0     77
            JPEG   10  0 10  0 10  0  0  0  0 10  0 10  7 10  0     67
            EPS    10 10 10  0  0  0 10  0 10  0  0  5  0 10  0     65
            CIFF    0  0  0 10 10  0  5  0  0 10  0 10 10 10  0     65
            TIFF    0  0  0 10  5 10  5  0 10 10  0  0 10  0  0     60
            EXIF    0  0  0 10  5 10  0  0  0 10  0  0 10  0  0     45
            IPTC    0  0 10  0  8  0  0  0  0 10  0 10  7  0  0     45

       By design, MIE ranks highest by a significant margin.  Other formats with reasonable scores are PDF, PNG
       and XMP, but each has significant weak points.  What may be surprising is that TIFF, EXIF and IPTC rank
       so low.

       As well as scoring high in all these features, the MIE format has the unique ability to encapsulate any
       other type of file, and provides a non-invasive method of adding meta information to a file.  The meta
       information is logically separated from the original file data, which is extremely important because meta
       information is routinely lost when files are edited.

       Also, the MIE format supports multiple files by simple concatenation, enabling all kinds of wonderful
       features such as linear databases, edit histories or non-intrusive file updates.  This ability can also
       be leveraged to allow MIE-format trailers to be added to some other file types.

MIE 1.1 FORMAT SPECIFICATION (2007-01-21)

   File Structure
       A MIE file consists of a series of MIE elements.  A MIE element may contain either data or a group of MIE
       elements, providing a hierarchical format for storing data.  Each MIE element is identified by a human-
       readable tag name, and may store data from zero to 2^64-1 bytes in length.

   File Signature
       The first element in the MIE file must be an uncompressed MIE group element with a tag name of "0MIE".
       This restriction allows the first 8 bytes of a MIE file to be used to identify a MIE format file.  The
       following table lists the two possible initial byte sequences for a MIE-format file (the first for big-
       endian, and the second for little-endian byte ordering):

           Byte Number:      0    1    2    3    4    5    6    7

           C Characters:     ~ \x10 \x04    ?    0    M    I    E
               or            ~ \x18 \x04    ?    0    M    I    E

           Hexadecimal:     7e   10   04    ?   30   4d   49   45
               or           7e   18   04    ?   30   4d   49   45

           Decimal:        126   16    4    ?   48   77   73   69
               or          126   24    4    ?   48   77   73   69

       Note that byte 1 may have one of the two possible values (0x10 or 0x18), and byte 3 may have any value
       (0x00 to 0xff).

   Element Structure
           1 byte  SyncByte = 0x7e (decimal 126, character '~')
           1 byte  FormatCode (see below)
           1 byte  TagLength (T)
           1 byte  DataLength (gives D if DataLength < 253)
           T bytes TagName (T given by TagLength)
           2 bytes DataLength2 [exists only if DataLength == 255 (0xff)]
           4 bytes DataLength4 [exists only if DataLength == 254 (0xfe)]
           8 bytes DataLength8 [exists only if DataLength == 253 (0xfd)]
           D bytes DataBlock (D given by DataLength)

       The minimum element length is 4 bytes (for a group terminator).  The maximum DataBlock size is 2^64-1
       bytes.  TagLength and DataLength are unsigned integers, and the byte ordering for multi-byte DataLength
       fields is specified by the containing MIE group element.  The SyncByte is byte aligned, so no padding is
       added to align on an N-byte boundary.

       FormatCode

       The format code is a bitmask that defines the format of the data:

           7654 3210
           ++++ ----  FormatType
           ---- +---  TypeModifier
           ---- -+--  Compressed
           ---- --++  FormatSize

       FormatType (bitmask 0xf0):
               0x00 - other (or unknown) data
               0x10 - MIE group
               0x20 - text string
               0x30 - list of null-separated text strings
               0x40 - integer
               0x50 - rational
               0x60 - fixed point
               0x70 - floating point
               0x80 - free space

       TypeModifier (bitmask 0x08):
           Modifies the meaning of certain FormatTypes (0x00-0x60):

               0x08 - other data sensitive to MIE group byte order
               0x18 - MIE group with little-endian byte ordering
               0x28 - UTF encoded text string
               0x38 - UTF encoded text string list
               0x48 - signed integer
               0x58 - signed rational (denominator is always unsigned)
               0x68 - signed fixed-point

       Compressed (bitmask 0x04):
           If  this  bit  is  set,  the data block is compressed using Zlib deflate.  An entire MIE group may be
           compressed, with the exception of file-level groups.

       FormatSize (bitmask 0x03):
           Gives the byte size of each data element:

               0x00 - 8 bits  (1 byte)
               0x01 - 16 bits (2 bytes)
               0x02 - 32 bits (4 bytes)
               0x03 - 64 bits (8 bytes)

           The number of bytes in a single value for this format is given by 2**FormatSize (or 1 << FormatSize).
           The number of values is the data length divided by this number of bytes.  It is an error if the  data
           length is not an even multiple of the format size in bytes.

       The following is a list of all currently defined MIE FormatCode values for uncompressed data (add 0x04 to
       each value for compressed data):

           0x00 - other data (insensitive to MIE group byte order) (1)
           0x01 - other 16-bit data (may be byte swapped)
           0x02 - other 32-bit data (may be byte swapped)
           0x03 - other 64-bit data (may be byte swapped)
           0x08 - other data (sensitive to MIE group byte order) (1)
           0x10 - MIE group with big-endian values (1)
           0x18 - MIE group with little-endian values (1)
           0x20 - ASCII (ISO 8859-1) string (2,3)
           0x28 - UTF-8 string (2,3,4)
           0x29 - UTF-16 string (2,3,4)
           0x2a - UTF-32 string (2,3,4)
           0x30 - ASCII (ISO 8859-1) string list (3,5)
           0x38 - UTF-8 string list (3,4,5)
           0x39 - UTF-16 string list (3,4,5)
           0x3a - UTF-32 string list (3,4,5)
           0x40 - unsigned 8-bit integer
           0x41 - unsigned 16-bit integer
           0x42 - unsigned 32-bit integer
           0x43 - unsigned 64-bit integer (6)
           0x48 - signed 8-bit integer
           0x49 - signed 16-bit integer
           0x4a - signed 32-bit integer
           0x4b - signed 64-bit integer (6)
           0x52 - unsigned 32-bit rational (16-bit numerator then denominator) (7)
           0x53 - unsigned 64-bit rational (32-bit numerator then denominator) (7)
           0x5a - signed 32-bit rational (denominator is unsigned) (7)
           0x5b - signed 64-bit rational (denominator is unsigned) (7)
           0x61 - unsigned 16-bit fixed-point (high 8 bits is integer part) (8)
           0x62 - unsigned 32-bit fixed-point (high 16 bits is integer part) (8)
           0x69 - signed 16-bit fixed-point (high 8 bits is signed integer) (8)
           0x6a - signed 32-bit fixed-point (high 16 bits is signed integer) (8)
           0x72 - 32-bit IEEE float (not recommended for portability reasons)
           0x73 - 64-bit IEEE double (not recommended for portability reasons) (6)
           0x80 - free space (value data does not contain useful information)

       Notes:

       1.  The byte ordering specified by the MIE group TypeModifier applies to the MIE group element as well as
           all  elements  within the group.  Data for all FormatCodes except 0x08 (other data, sensitive to byte
           order) may be transferred between  MIE  groups  with  different  byte  order  by  byte  swapping  the
           uncompressed  data  according to the specified data format.  The following list illustrates the byte-
           swapping pattern, based on FormatSize, for all format types except rational (FormatType 0x50).

                 FormatSize              Change in Byte Sequence
               --------------      -----------------------------------
               0x00 (8 bits)       0 1 2 3 4 5 6 7 --> 0 1 2 3 4 5 6 7 (no change)
               0x01 (16 bits)      0 1 2 3 4 5 6 7 --> 1 0 3 2 5 4 7 6
               0x02 (32 bits)      0 1 2 3 4 5 6 7 --> 3 2 1 0 7 6 5 4
               0x03 (64 bits)      0 1 2 3 4 5 6 7 --> 7 6 5 4 3 2 1 0

           Rational values consist of two integers, so they are swapped  as  the  next  lower  FormatSize.   For
           example,  a  32-bit  rational (FormatSize 0x02, and FormatCode 0x52 or 0x5a) is swapped as two 16-bit
           values (ie. as if it had FormatSize 0x01).

       2.  The TagName of a string element may have an 6-character suffix to indicate a  specific  locale.  (eg.
           "Title-en_US", or "Keywords-de_DE").

       3.  Text  strings  are  not  normally  null  terminated, however they may be padded with one or more null
           characters to the end of the data block to allow  strings  to  be  edited  within  fixed-length  data
           blocks.  Newlines in the text are indicated by a single LF (0x0a) character.

       4.  UTF  strings  must  not  begin  with  a  byte order mark (BOM) since the byte order and byte size are
           specified by the MIE format.  If a BOM is found, it should be treated as  a  zero-width  non-breaking
           space.

       5.  A  list  of  text  strings separated by null characters.  These lists must not be null padded or null
           terminated, since this would be interpreted as additional zero-length strings.  For ASCII  and  UTF-8
           strings,  the  null  character  is a single zero (0x00) byte.  For UTF-16 or UTF-32 strings, the null
           character is 2 or 4 zero bytes respectively.

       6.  64-bit integers and doubles are subject to the specified byte ordering  for  both  32-bit  words  and
           bytes  within these words.  For instance, the high order byte is always the first byte if big-endian,
           and the eighth byte if little-endian.  This means that some swapping is always  necessary  for  these
           values on systems where the byte order differs from the word order (eg. some ARM systems), regardless
           of the endian-ness of the stored values.

       7.  Rational values are treated as two separate integers.  The numerator always comes first regardless of
           the byte ordering.  In a signed rational value, only the numerator is signed.  The denominator of all
           rational  values  is unsigned (eg. a signed 64-bit rational of 0x80000000/0x80000000 evaluates to -1,
           not +1).

       8.  32-bit fixed point values are converted to floating point by treating them as an integer and dividing
           by an appropriate value.  eg)

               16-bit fixed value = 16-bit integer value / 256.0
               32-bit fixed value = 32-bit integer value / 65536.0

       TagLength

       Gives the length of the TagName string.  Any value between 0 and 255 is valid, but the TagLength of 0  is
       valid only for the MIE group terminator.

       DataLength

       DataLength  is  an unsigned byte that gives the number of bytes in the data block.  A value between 0 and
       252 gives the data length directly, and numbers from 253 to 255  are  reserved  for  extended  DataLength
       codes.   Codes  of  255,  254  and  253  indicate  that the element contains an additional 2, 4 or 8 byte
       unsigned integer representing the data length.

           0-252      - length of data block
           255 (0xff) - use DataLength2
           254 (0xfe) - use DataLength4
           253 (0xfd) - use DataLength8

       A DataLength of zero is valid for any element except a compressed MIE group.  A zero  DataLength  for  an
       uncompressed  MIE  group  indicates  that the group length is unknown.  For other elements, a zero length
       indicates there is no associated data.  A terminator element must have a DataLength of 0, 6  or  10,  and
       may not use an extended DataLength.

       TagName

       The  TagName  string  is  0  to 255 bytes long, and is composed of the ASCII characters A-Z, a-z, 0-9 and
       underline ('_').  Also, a dash ('-') is used to separate the language/country code in the  TagName  of  a
       localized  text  string, and a units string (possibly containing other ASCII characters) may be appear in
       brackets at the end of the TagName.  The TagName string is NOT null terminated.  A MIE element with a tag
       string of zero length is reserved for the group terminator.

       MIE elements are sorted alphabetically by TagName within each group.  Multiple  elements  with  the  same
       TagName are allowed, even within the same group.

       TagNames  should  be meaningful.  Case is significant.  Words should be lowercase with an uppercase first
       character, and acronyms should be all upper case.  The underline ("_") is provided to allow separation of
       two acronyms or two numbers, but it shouldn't be used  unless  necessary.   No  separation  is  necessary
       between an acronym and a word (eg. "ISOSetting").

       All  TagNames should start with an uppercase letter.  An exception to this rule allows tags to begin with
       a digit (0-9) if they must come before other tags in the sort order, or a lowercase letter (a-z) if  they
       must  come  after.   For  instance,  the  '0Type' element begins with a digit so it comes before, and the
       'data' element begins with a lowercase letter so that it comes after meta information tags  in  the  main
       "0MIE" group.

       Tag  names  for  localized  text strings have an 6-character suffix with the following format:  The first
       character is a dash ('-'), followed by a  2-character  lower  case  ISO  639-1  language  code,  then  an
       underline  ('_'),  and  ending  with  a  2-character  upper  case  ISO 3166-1 alpha 2 country code.  (eg.
       "-en_US", "-en_GB", "-de_DE" or "-fr_FR".  Note that "GB", and not "UK" is the code  for  Great  Britain,
       although  "UK"  should be recognized for compatibility reasons.)  The suffix is included when sorting the
       tags alphabetically, so the default locale (with no tag-name suffix) always comes first.  If the  country
       is unknown or not applicable, a country code of "XX" should be used.

       Tags with numerical values may allow units of measurement to be specified.  The units string is stored in
       brackets  at  the end of the tag name, and is composed of zero or more ASCII characters in the range 0x21
       to   0x7d,   excluding   the   bracket   characters   0x28   and   0x29.    (eg.   "Resolution(/cm)"   or
       "SpecificHeat(J/kg.K)".)   See Image::ExifTool::MIEUnits for details. Unit strings are not localized, and
       may not be used in combination with localized text strings.

       Sets of tags which would require a common prefix should be added in  a  separate  MIE  group  instead  of
       adding the prefix to all tag names.  For example, instead of these TagName's:

           ExternalFlashType
           ExternalFlashSerialNumber
           ExternalFlashFired

       one would instead designate a separate "ExternalFlash" MIE group to contain the following elements:

           Type
           SerialNumber
           Fired

       DataLength2/4/8

       These  extended  DataLength fields exist only if DataLength is 255, 254 or 253, and are respectively 2, 4
       or 8 byte unsigned integers giving the data block length.  One of these values must be used if  the  data
       block is larger than 252 bytes, but they may be used if desired for smaller blocks too (although this may
       add a few unnecessary bytes to the MIE element).

       DataBlock

       The  data  value  for the MIE element.  The format of the data is given by the FormatCode.  For MIE group
       elements, the data includes all contained elements and the group terminator.

   MIE groups
       All MIE data elements must be contained within a group.  A group begins with a  MIE  group  element,  and
       ends with a group terminator.  Groups may be nested in a hierarchy to arbitrary depth.

       A  MIE  group  element  is identified by a format code of 0x10 (big endian byte ordering) or 0x18 (little
       endian).  The group terminator is distinguished by a zero TagLength (it is the only  element  allowed  to
       have a zero TagLength), and has a FormatCode of 0x00.

       The  MIE  group  element  is  permitted to have a zero DataLength only if the data is uncompressed.  This
       special value indicates that the group length is unknown (otherwise the minimum value for  DataLength  is
       4,  corresponding  the  the  minimum  group  size  which  includes  a terminator of at least 4 bytes). If
       DataLength is zero, all elements in the group must be parsed until the group  terminator  is  found.   If
       non-zero,  DataLength includes the length of all elements contained within the group, including the group
       terminator.  Use of a non-zero DataLength is encouraged because  it  allows  readers  quickly  skip  over
       entire  MIE  groups.   For  compressed  groups  DataLength  must  be  non-zero,  and is the length of the
       compressed group data (which includes the compressed group terminator).

       Group Terminator

       The group terminator has a FormatCode and TagLength of zero.  The terminator DataLength must be 0,  6  or
       10 bytes, and extended DataLength codes may not be used.  With a zero DataLength, the byte sequence for a
       terminator  is  "7e  00  00  00"  (hex).   With  a DataLength of 6 or 10 bytes, the terminator data block
       contains information about the length  and  byte  ordering  of  the  preceding  group.   This  additional
       information  is  recommended  for  file-level  groups,  and  is  used in multi-document MIE files and MIE
       trailers to allow the file to be scanned backwards from the end.  (This may also allow some documents  to
       be  recovered if part of the file is corrupted.)  The structure of this optional terminator data block is
       as follows:

           4 or 8 bytes  GroupLength (unsigned integer)
           1 byte        ByteOrder (0x10 or 0x18, same as MIE group)
           1 byte        GroupLengthSize (0x04 or 0x08)

       The ByteOrder and GroupLengthSize values give the byte ordering and size of the GroupLength integer.  The
       GroupLength value is the total length of the entire MIE group ending with this terminator, including  the
       opening MIE group element and the terminator itself.

       File-level MIE groups

       File-level MIE groups may NOT be compressed.

       All elements in a MIE file are contained within a special group with a TagName of "0MIE".  The purpose of
       the  "OMIE"  group  is  to  provide  a  unique  signature  at  the  start of the file, and to encapsulate
       information allowing files to be easily combined.  The "0MIE" group must be  terminated  like  any  other
       group,  but  it  is recommended that the terminator of a file-level group include the optional data block
       (defined above) to provide information about the group length and byte order.

       It is valid to have more than one "0MIE" group at the file level, allowing multiple documents in a single
       MIE file.  Furthermore, the MIE  structure  enables  multi-document  files  to  be  generated  by  simply
       concatenating two or more MIE files.

   Scanning Backwards through a MIE File
       The steps below give an algorithm to quickly locate the last document in a MIE file:

       1.  Read  the  last  10 bytes of the file.  (Note that a valid MIE file may be as short as 12 bytes long,
           but a file this length contains only an an empty MIE group.)

       2.  If the last byte of the file is zero, then it is not possible to scan backward through the  file,  so
           the file must be scanned from the beginning.  Otherwise, proceed to the next step.

       3.  If the last byte is 4 or 8, the terminator contains information about the byte ordering and length of
           the group.  Otherwise, stop here because this isn't a valid MIE file.

       4.  The  next-to-last  byte  must  be either 0x10 indicating big-endian byte ordering or 0x18 for little-
           endian ordering, otherwise this isn't a valid MIE file.

       5.  The value of the preceding 4 or 8 bytes gives  the  length  of  the  complete  file-level  MIE  group
           (GroupLength).   This  length  includes both the leading MIE group element and the terminator element
           itself.  The value is an unsigned integer with a byte length given in step 3), and a byte order  from
           step  4).   From  the current file position (at the end of the data read in step 1), seek backward by
           this number of bytes to find the start of the MIE group element for this document.

       This algorithm may be repeated again beginning at this point in  the  file  to  locate  the  next-to-last
       document, etc.

       The  table  below  lists  all  5 valid patterns for the last 14 bytes of a file-level MIE group, with all
       numbers in hex.  The comments indicate the length and byte ordering of GroupLength (xx) if available:

         ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 7e 00 00 00  - (no GroupLength)
         ?? ?? ?? ?? 7e 00 00 06 xx xx xx xx 10 04  - 4 bytes, big endian
         ?? ?? ?? ?? 7e 00 00 06 xx xx xx xx 18 04  - 4 bytes, little endian
         7e 00 00 0a xx xx xx xx xx xx xx xx 10 08  - 8 bytes, big endian
         7e 00 00 0a xx xx xx xx xx xx xx xx 18 08  - 8 bytes, little endian

   Trailer Signature
       The MIE format may be used for trailer information appended to other types of files.  When this is  done,
       a signature must appear at the end of the main MIE group to uniquely identify the MIE format trailer.  To
       achieve  this,  a "zmie" trailer signature is written as the last element in the main "0MIE" group.  This
       element has a FormatCode of 0, a TagLength of 4, a DataLength of 0, and a TagName of "zmie".   With  this
       signature,  the  hex  byte  sequence "7e 00 04 00 7a 6d 69 65" appears immediately before the final group
       terminator, and the last 22 bytes of the trailer correspond to one of the following 4 patterns (where the
       trailer length is given by "xx", as above):

         ?? ?? ?? ?? 7e 00 04 00 7a 6d 69 65 7e 00 00 06 xx xx xx xx 10 04
         ?? ?? ?? ?? 7e 00 04 00 7a 6d 69 65 7e 00 00 06 xx xx xx xx 18 04
         7e 00 04 00 7a 6d 69 65 7e 00 00 0a xx xx xx xx xx xx xx xx 10 08
         7e 00 04 00 7a 6d 69 65 7e 00 00 0a xx xx xx xx xx xx xx xx 18 08

       Note that the zero-DataLength terminator may not be used here because the trailer length  must  be  known
       for seeking backwards from the end of the file.

       Multiple trailers may be appended to the same file using this technique.

   MIE Data Values
       MIE  data  values  for a given tag are usually not restricted to a specific FormatCode.  Any value may be
       represented in any appropriate format, including numbers represented in string (ASCII or UTF) form.

       It is preferred that closely related values with the same format are written to a single tag  instead  of
       using  multiple tags.  This improves localization of like values and decreases MIE element overhead.  For
       instance, instead of separate ImageWidth and ImageHeight tags, a single ImageSize tag is defined.

       Tags which may take on a discrete set of values should have meaningful values if possible.  This improves
       the extensibility of the format and allows a more reasonable interpretation of unrecognized values.

       Numerical Representation

       Integer and floating point numbers may be represented in binary or string form.  In string form, integers
       are a series of digits with an optional  leading  sign  (eg.  "[+|-]DDDDDD"),  and  multiple  values  are
       separated  by  a  single  space character (eg. "23 128 -32").  Floating point numbers are similar but may
       also  contain  a  decimal  point  and/or  a  signed  exponent  with  a   leading   'e'   character   (eg.
       "[+|-]DD[.DDDDDD][e(+|-)EEE]").   The  string  "inf"  is  used  to  represent infinity.  One advantage of
       numerical strings is that they can have an arbitrarily high precision  because  the  possible  number  of
       significant digits is virtually unlimited.

       Note  that numerical values may have associated units of measurement which are specified in the "TagName"
       string.

       Date/Time Format

       All MIE dates are strings in the form "YYYY:mm:dd HH:MM:SS.ss+HH:MM".  The fractional seconds (".ss") are
       optional, and if included may contain any number of significant digits (unlike all other fields which are
       a fixed number of digits and must be padded with leading zeros if necessary).  The timezone ("+HH:MM"  or
       "-HH:MM") is recommended but not required.  If not given, the local system timezone is assumed.

   MIME Type
       The  basic MIME type for a MIE file is "application/x-mie", however the specific MIME type depends on the
       type of subfile, and is obtained by adding "x-mie-" to the MIME type of the subfile.  For example, with a
       subfile of type "image/jpeg", the MIE file MIME type is "image/x-mie-jpeg".  But note that  the  "x-"  is
       not  duplicated  if  the  subfile  MIME  type  already  starts  with  "x-".   So a subfile with MIME type
       "image/x-raw" is contained within a MIE file of type "image/x-mie-raw", not "image/x-mie-x-raw".  In  the
       case  of multiple documents in a MIE file, the MIME type is taken from the first document.  Regardless of
       the subfile type, all MIE-format files should have a filename extension of ".MIE".

   Levels of Support
       Basic MIE reader/writer applications may choose not to provide support for some advanced features of  the
       MIE format.  Features which may not be supported by all software are:

       Compression
           Software not supporting compression must ignore compressed elements and groups, but should be able to
           process the remaining information.

       Large data lengths
           Some software may limit the maximum size of a MIE group or element.  Historically, a limit of 2GB may
           be  imposed  by  some  systems.  However, 8-byte data lengths should be supported by all applications
           provided the value doesn't exceed the system limit.  (eg. For systems with a 2GB limit,  8-byte  data
           lengths  should  be  supported if the upper 17 bits are all zero.)  If a data length above the system
           limit is encountered, it may be necessary for the application to stop processing if it can  not  seek
           to the next element in the file.

EXAMPLES

       This section gives examples for working with MIE information using ExifTool.

   Encapsulating Information with Data in a MIE File
       The following command encapsulates any file recognized by ExifTool inside a MIE file, and initializes MIE
       tags from information within the file:

           exiftool -o new.mie -tagsfromfile FILE '-mie:all<all' \
               '-subfilename<filename' '-subfiletype<filetype' \
               '-subfilemimetype<mimetype' '-subfiledata<=FILE'

       where "FILE" is the name of the file.

       For unrecognized files, this command may be used:

           exiftool -o new.mie -subfilename=FILE -subfiletype=TYPE \
               -subfilemimetype=MIME '-subfiledata<=FILE'

       where "TYPE" and "MIME" represent the source file type and MIME type respectively.

   Adding a MIE Trailer to a File
       The  MIE  format  may  also  be  used to store information in a trailer appended to another type of file.
       Beware that trailers may not be compatible with all file formats, but JPEG and TIFF are two formats where
       additional trailer information doesn't create any problems for normal parsing of  the  file.   Also  note
       that  this  technique  has  the  disadvantage  that  trailer  information is commonly lost if the file is
       subsequently edited by other software.

       Creating a MIE trailer with ExifTool is a two-step process since ExifTool can't currently be used to  add
       a  MIE  trailer  directly.  The example below illustrates the steps for adding a MIE trailer with a small
       preview image ("small.jpg") to a destination JPEG image ("dst.jpg").

       Step 1) Create a MIE file with a TrailerSignature containing the desired information:

           exiftool -o new.mie -trailersignature=1 -tagsfromfile small.jpg \
               '-previewimagetype<filetype' '-previewimagesize<imagesize' \
               '-previewimagename<filename' '-previewimage<=small.jpg'

       Step 2) Append the MIE information to another file.  In Unix, this can be done with the 'cat' command:

           cat new.mie >> dst.jpg

       Once added, ExifTool may be used to edit or delete a MIE trailer in a JPEG or TIFF image.

   Multiple MIE Documents in a Single File
       The MIE specification allows multiple MIE documents (or trailers) to exist in a single file.  A file like
       this may be created by simply concatenating MIE documents.  ExifTool may be used to access information in
       a specific document by adding a copy number to the MIE group name.  For example:

           # write the Author tag in the second MIE document
           exiftool -mie2:author=phil test.mie

           # delete the first MIE document from a file
           exiftool -mie1:all= test.mie

   Units of Measurement
       Some MIE tags allow values to be specified in different units of measurement.  In  the  MIE  file  format
       these  units are combined with the tag name, but when using ExifTool they are specified in brackets after
       the value:

           exiftool -mie:gpsaltitude='7500(ft)' test.mie

       If no units are provided, the default units are written.

   Localized Text
       Localized text values are accessed by adding a language/country code to the tag name.  For example:

           exiftool -comment-en_us='this is a comment' test.mie

REVISIONS

         2010-04-05 - Fixed "Format Size" Note 7 to give the correct number of bits
                      in the example rational value
         2007-01-21 - Specified LF character (0x0a) for text newline sequence
         2007-01-19 - Specified ISO 8859-1 character set for extended ASCII codes
         2007-01-01 - Improved wording of Step 5 for scanning backwards in MIE file
         2006-12-30 - Added EXAMPLES section and note about UTF BOM
         2006-12-20 - MIE 1.1:  Changed meaning of TypeModifier bit (0x08) for
                      unknown data (FormatType 0x00), and documented byte swapping
         2006-12-14 - MIE 1.0:  Added Data Values and Numerical Representations
                      sections, and added ability to specify units in tag names
         2006-11-09 - Added Levels of Support section
         2006-11-03 - Added Trailer Signature
         2005-11-18 - Original specification created

AUTHOR

       Copyright 2003-2024, Phil Harvey (philharvey66 at gmail.com)

       This library is free software; you can redistribute it and/or modify it under  the  same  terms  as  Perl
       itself.   The  MIE  format  itself  is  also  copyright  Phil Harvey, and is covered by the same free-use
       license.

REFERENCES

       <https://exiftool.org/MIE1.1-20070121.pdf>

SEE ALSO

       "MIE Tags" in Image::ExifTool::TagNames, Image::ExifTool::MIEUnits, Image::ExifTool(3pm)

perl v5.38.2                                       2024-02-03                          Image::ExifTool::MIE(3pm)