{ "content": [ { "type": "text", "text": "# Image::ExifTool::MIE (perldoc)\n\n## NAME\n\nImage::ExifTool::MIE - Read/write MIE meta information\n\n## SYNOPSIS\n\nThis module is used by Image::ExifTool\n\n## DESCRIPTION\n\nThis module contains routines required by Image::ExifTool to read and write information in MIE\nfiles.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION** (7 subsections)\n- **EXAMPLES** (5 subsections)\n- **REVISIONS**\n- **AUTHOR**\n- **REFERENCES**\n- **SEE ALSO**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Image::ExifTool::MIE", "section": "", "mode": "perldoc", "summary": "Image::ExifTool::MIE - Read/write MIE meta information", "synopsis": "This module is used by Image::ExifTool", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [ "This section gives examples for working with MIE information using ExifTool.", "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> dst.jpg", "Once added, ExifTool may be used to edit or delete a MIE trailer in a JPEG or TIFF image.", "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", "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 values are accessed by adding a language/country code to the tag name. For", "example:", "exiftool -comment-enus='this is a comment' test.mie" ], "see_also": [ { "name": "ExifTool", "section": "3pm", "url": "https://www.chedong.com/phpMan.php/man/ExifTool/3pm/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 9, "subsections": [ { "name": "Features", "lines": 50 }, { "name": "File Structure", "lines": 4 }, { "name": "File Signature", "lines": 19 }, { "name": "Element Structure", "lines": 284 }, { "name": "Scanning Backwards through a MIE File", "lines": 34 }, { "name": "Trailer Signature", "lines": 62 }, { "name": "Levels of Support", "lines": 15 } ] }, { "name": "EXAMPLES", "lines": 2, "subsections": [ { "name": "Encapsulating Information with Data in a MIE File", "lines": 16 }, { "name": "Adding a MIE Trailer to a File", "lines": 23 }, { "name": "Multiple MIE Documents in a Single File", "lines": 11 }, { "name": "Units of Measurement", "lines": 8 }, { "name": "Localized Text", "lines": 5 } ] }, { "name": "REVISIONS", "lines": 14, "subsections": [] }, { "name": "AUTHOR", "lines": 6, "subsections": [] }, { "name": "REFERENCES", "lines": 2, "subsections": [] }, { "name": "SEE ALSO", "lines": 2, "subsections": [] } ], "sections": { "NAME": { "content": "Image::ExifTool::MIE - Read/write MIE meta information\n", "subsections": [] }, "SYNOPSIS": { "content": "This module is used by Image::ExifTool\n", "subsections": [] }, "DESCRIPTION": { "content": "This module contains routines required by Image::ExifTool to read and write information in MIE\nfiles.\n\nWHAT IS MIE?\nMIE stands for \"Meta Information Encapsulation\". The MIE format is an extensible, dedicated meta\ninformation format which supports storage of binary as well as textual meta information. MIE can\nbe used to encapsulate meta information from many sources and bundle it together with any type\nof file.\n", "subsections": [ { "name": "Features", "content": "Below is very subjective score card comparing the features of a number of common file and meta\ninformation formats, and comparing them to MIE. The following features are rated for each format\nwith a score of 0 to 10:\n\n1) Extensible (can incorporate user-defined information).\n2) Meaningful tag ID's (hint to meaning of unknown information).\n3) Sequential read/write ability (streamable).\n4) Hierarchical information structure.\n5) Easy to implement reader/writer/editor.\n6) Order of information well defined.\n7) Large data lengths supported: >64kB (+5) and >4GB (+5).\n8) Localized text strings.\n9) Multiple documents in a single file.\n10) Compact format doesn't squander disk space or bandwidth.\n11) Compressed meta information supported.\n12) Relocatable data elements (ie. no fixed offsets).\n13) Binary meta information (+7) with variable byte order (+3).\n14) Mandatory tags not required (an unnecessary complication).\n15) Append information to end of file without editing.\n\nFeature number Total\nFormat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Score\n------ --------------------------------------------- -----\nMIE 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 150\nPDF 10 10 0 10 0 0 10 0 10 10 10 0 7 10 10 97\nPNG 10 10 10 0 8 0 5 10 0 10 10 10 0 10 0 93\nXMP 10 10 10 10 2 0 10 10 10 0 0 10 0 10 0 92\nAIFF 0 5 10 10 10 0 5 0 0 10 0 10 7 10 0 77\nRIFF 0 5 10 10 10 0 5 0 0 10 0 10 7 10 0 77\nJPEG 10 0 10 0 10 0 0 0 0 10 0 10 7 10 0 67\nEPS 10 10 10 0 0 0 10 0 10 0 0 5 0 10 0 65\nCIFF 0 0 0 10 10 0 5 0 0 10 0 10 10 10 0 65\nTIFF 0 0 0 10 5 10 5 0 10 10 0 0 10 0 0 60\nEXIF 0 0 0 10 5 10 0 0 0 10 0 0 10 0 0 45\nIPTC 0 0 10 0 8 0 0 0 0 10 0 10 7 0 0 45\n\nBy design, MIE ranks highest by a significant margin. Other formats with reasonable scores are\nPDF, PNG and XMP, but each has significant weak points. What may be surprising is that TIFF,\nEXIF and IPTC rank so low.\n\nAs well as scoring high in all these features, the MIE format has the unique ability to\nencapsulate any other type of file, and provides a non-invasive method of adding meta\ninformation to a file. The meta information is logically separated from the original file data,\nwhich is extremely important because meta information is routinely lost when files are edited.\n\nAlso, the MIE format supports multiple files by simple concatenation, enabling all kinds of\nwonderful features such as linear databases, edit histories or non-intrusive file updates. This\nability can also be leveraged to allow MIE-format trailers to be added to some other file types.\n\nMIE 1.1 FORMAT SPECIFICATION (2007-01-21)" }, { "name": "File Structure", "content": "A MIE file consists of a series of MIE elements. A MIE element may contain either data or a\ngroup of MIE elements, providing a hierarchical format for storing data. Each MIE element is\nidentified by a human-readable tag name, and may store data from zero to 2^64-1 bytes in length.\n" }, { "name": "File Signature", "content": "The first element in the MIE file must be an uncompressed MIE group element with a tag name of\n\"0MIE\". This restriction allows the first 8 bytes of a MIE file to be used to identify a MIE\nformat file. The following table lists the two possible initial byte sequences for a MIE-format\nfile (the first for big-endian, and the second for little-endian byte ordering):\n\nByte Number: 0 1 2 3 4 5 6 7\n\nC Characters: ~ \\x10 \\x04 ? 0 M I E\nor ~ \\x18 \\x04 ? 0 M I E\n\nHexadecimal: 7e 10 04 ? 30 4d 49 45\nor 7e 18 04 ? 30 4d 49 45\n\nDecimal: 126 16 4 ? 48 77 73 69\nor 126 24 4 ? 48 77 73 69\n\nNote that byte 1 may have one of the two possible values (0x10 or 0x18), and byte 3 may have any\nvalue (0x00 to 0xff).\n" }, { "name": "Element Structure", "content": "1 byte SyncByte = 0x7e (decimal 126, character '~')\n1 byte FormatCode (see below)\n1 byte TagLength (T)\n1 byte DataLength (gives D if DataLength < 253)\nT bytes TagName (T given by TagLength)\n2 bytes DataLength2 [exists only if DataLength == 255 (0xff)]\n4 bytes DataLength4 [exists only if DataLength == 254 (0xfe)]\n8 bytes DataLength8 [exists only if DataLength == 253 (0xfd)]\nD bytes DataBlock (D given by DataLength)\n\nThe minimum element length is 4 bytes (for a group terminator). The maximum DataBlock size is\n2^64-1 bytes. TagLength and DataLength are unsigned integers, and the byte ordering for\nmulti-byte DataLength fields is specified by the containing MIE group element. The SyncByte is\nbyte aligned, so no padding is added to align on an N-byte boundary.\n\nFormatCode\nThe format code is a bitmask that defines the format of the data:\n\n7654 3210\n++++ ---- FormatType\n---- +--- TypeModifier\n---- -+-- Compressed\n---- --++ FormatSize\n\nFormatType (bitmask 0xf0):\n0x00 - other (or unknown) data\n0x10 - MIE group\n0x20 - text string\n0x30 - list of null-separated text strings\n0x40 - integer\n0x50 - rational\n0x60 - fixed point\n0x70 - floating point\n0x80 - free space\n\nTypeModifier (bitmask 0x08):\nModifies the meaning of certain FormatTypes (0x00-0x60):\n\n0x08 - other data sensitive to MIE group byte order\n0x18 - MIE group with little-endian byte ordering\n0x28 - UTF encoded text string\n0x38 - UTF encoded text string list\n0x48 - signed integer\n0x58 - signed rational (denominator is always unsigned)\n0x68 - signed fixed-point\n\nCompressed (bitmask 0x04):\nIf this bit is set, the data block is compressed using Zlib deflate. An entire MIE group may\nbe compressed, with the exception of file-level groups.\n\nFormatSize (bitmask 0x03):\nGives the byte size of each data element:\n\n0x00 - 8 bits (1 byte)\n0x01 - 16 bits (2 bytes)\n0x02 - 32 bits (4 bytes)\n0x03 - 64 bits (8 bytes)\n\nThe number of bytes in a single value for this format is given by 2FormatSize (or 1 <<\nFormatSize). The number of values is the data length divided by this number of bytes. It is\nan error if the data length is not an even multiple of the format size in bytes.\n\nThe following is a list of all currently defined MIE FormatCode values for uncompressed data\n(add 0x04 to each value for compressed data):\n\n0x00 - other data (insensitive to MIE group byte order) (1)\n0x01 - other 16-bit data (may be byte swapped)\n0x02 - other 32-bit data (may be byte swapped)\n0x03 - other 64-bit data (may be byte swapped)\n0x08 - other data (sensitive to MIE group byte order) (1)\n0x10 - MIE group with big-endian values (1)\n0x18 - MIE group with little-endian values (1)\n0x20 - ASCII (ISO 8859-1) string (2,3)\n0x28 - UTF-8 string (2,3,4)\n0x29 - UTF-16 string (2,3,4)\n0x2a - UTF-32 string (2,3,4)\n0x30 - ASCII (ISO 8859-1) string list (3,5)\n0x38 - UTF-8 string list (3,4,5)\n0x39 - UTF-16 string list (3,4,5)\n0x3a - UTF-32 string list (3,4,5)\n0x40 - unsigned 8-bit integer\n0x41 - unsigned 16-bit integer\n0x42 - unsigned 32-bit integer\n0x43 - unsigned 64-bit integer (6)\n0x48 - signed 8-bit integer\n0x49 - signed 16-bit integer\n0x4a - signed 32-bit integer\n0x4b - signed 64-bit integer (6)\n0x52 - unsigned 32-bit rational (16-bit numerator then denominator) (7)\n0x53 - unsigned 64-bit rational (32-bit numerator then denominator) (7)\n0x5a - signed 32-bit rational (denominator is unsigned) (7)\n0x5b - signed 64-bit rational (denominator is unsigned) (7)\n0x61 - unsigned 16-bit fixed-point (high 8 bits is integer part) (8)\n0x62 - unsigned 32-bit fixed-point (high 16 bits is integer part) (8)\n0x69 - signed 16-bit fixed-point (high 8 bits is signed integer) (8)\n0x6a - signed 32-bit fixed-point (high 16 bits is signed integer) (8)\n0x72 - 32-bit IEEE float (not recommended for portability reasons)\n0x73 - 64-bit IEEE double (not recommended for portability reasons) (6)\n0x80 - free space (value data does not contain useful information)\n\nNotes:\n\n1. The byte ordering specified by the MIE group TypeModifier applies to the MIE group element\nas well as all elements within the group. Data for all FormatCodes except 0x08 (other data,\nsensitive to byte order) may be transferred between MIE groups with different byte order by\nbyte swapping the uncompressed data according to the specified data format. The following\nlist illustrates the byte-swapping pattern, based on FormatSize, for all format types except\nrational (FormatType 0x50).\n\nFormatSize Change in Byte Sequence\n-------------- -----------------------------------\n0x00 (8 bits) 0 1 2 3 4 5 6 7 --> 0 1 2 3 4 5 6 7 (no change)\n0x01 (16 bits) 0 1 2 3 4 5 6 7 --> 1 0 3 2 5 4 7 6\n0x02 (32 bits) 0 1 2 3 4 5 6 7 --> 3 2 1 0 7 6 5 4\n0x03 (64 bits) 0 1 2 3 4 5 6 7 --> 7 6 5 4 3 2 1 0\n\nRational values consist of two integers, so they are swapped as the next lower FormatSize.\nFor example, a 32-bit rational (FormatSize 0x02, and FormatCode 0x52 or 0x5a) is swapped as\ntwo 16-bit values (ie. as if it had FormatSize 0x01).\n\n2. The TagName of a string element may have an 6-character suffix to indicate a specific\nlocale. (eg. \"Title-enUS\", or \"Keywords-deDE\").\n\n3. Text strings are not normally null terminated, however they may be padded with one or more\nnull characters to the end of the data block to allow strings to be edited within\nfixed-length data blocks. Newlines in the text are indicated by a single LF (0x0a)\ncharacter.\n\n4. UTF strings must not begin with a byte order mark (BOM) since the byte order and byte size\nare specified by the MIE format. If a BOM is found, it should be treated as a zero-width\nnon-breaking space.\n\n5. A list of text strings separated by null characters. These lists must not be null padded or\nnull terminated, since this would be interpreted as additional zero-length strings. For\nASCII and UTF-8 strings, the null character is a single zero (0x00) byte. For UTF-16 or\nUTF-32 strings, the null character is 2 or 4 zero bytes respectively.\n\n6. 64-bit integers and doubles are subject to the specified byte ordering for both 32-bit words\nand bytes within these words. For instance, the high order byte is always the first byte if\nbig-endian, and the eighth byte if little-endian. This means that some swapping is always\nnecessary for these values on systems where the byte order differs from the word order (eg.\nsome ARM systems), regardless of the endian-ness of the stored values.\n\n7. Rational values are treated as two separate integers. The numerator always comes first\nregardless of the byte ordering. In a signed rational value, only the numerator is signed.\nThe denominator of all rational values is unsigned (eg. a signed 64-bit rational of\n0x80000000/0x80000000 evaluates to -1, not +1).\n\n8. 32-bit fixed point values are converted to floating point by treating them as an integer and\ndividing by an appropriate value. eg)\n\n16-bit fixed value = 16-bit integer value / 256.0\n32-bit fixed value = 32-bit integer value / 65536.0\n\nTagLength\nGives the length of the TagName string. Any value between 0 and 255 is valid, but the TagLength\nof 0 is valid only for the MIE group terminator.\n\nDataLength\nDataLength is an unsigned byte that gives the number of bytes in the data block. A value between\n0 and 252 gives the data length directly, and numbers from 253 to 255 are reserved for extended\nDataLength codes. Codes of 255, 254 and 253 indicate that the element contains an additional 2,\n4 or 8 byte unsigned integer representing the data length.\n\n0-252 - length of data block\n255 (0xff) - use DataLength2\n254 (0xfe) - use DataLength4\n253 (0xfd) - use DataLength8\n\nA DataLength of zero is valid for any element except a compressed MIE group. A zero DataLength\nfor an uncompressed MIE group indicates that the group length is unknown. For other elements, a\nzero length indicates there is no associated data. A terminator element must have a DataLength\nof 0, 6 or 10, and may not use an extended DataLength.\n\nTagName\nThe TagName string is 0 to 255 bytes long, and is composed of the ASCII characters A-Z, a-z, 0-9\nand underline (''). Also, a dash ('-') is used to separate the language/country code in the\nTagName of a localized text string, and a units string (possibly containing other ASCII\ncharacters) may be appear in brackets at the end of the TagName. The TagName string is NOT null\nterminated. A MIE element with a tag string of zero length is reserved for the group terminator.\n\nMIE elements are sorted alphabetically by TagName within each group. Multiple elements with the\nsame TagName are allowed, even within the same group.\n\nTagNames should be meaningful. Case is significant. Words should be lowercase with an uppercase\nfirst character, and acronyms should be all upper case. The underline (\"\") is provided to allow\nseparation of two acronyms or two numbers, but it shouldn't be used unless necessary. No\nseparation is necessary between an acronym and a word (eg. \"ISOSetting\").\n\nAll TagNames should start with an uppercase letter. An exception to this rule allows tags to\nbegin with a digit (0-9) if they must come before other tags in the sort order, or a lowercase\nletter (a-z) if they must come after. For instance, the '0Type' element begins with a digit so\nit comes before, and the 'data' element begins with a lowercase letter so that it comes after\nmeta information tags in the main \"0MIE\" group.\n\nTag names for localized text strings have an 6-character suffix with the following format: The\nfirst character is a dash ('-'), followed by a 2-character lower case ISO 639-1 language code,\nthen an underline (''), and ending with a 2-character upper case ISO 3166-1 alpha 2 country\ncode. (eg. \"-enUS\", \"-enGB\", \"-deDE\" or \"-frFR\". Note that \"GB\", and not \"UK\" is the code\nfor Great Britain, although \"UK\" should be recognized for compatibility reasons.) The suffix is\nincluded when sorting the tags alphabetically, so the default locale (with no tag-name suffix)\nalways comes first. If the country is unknown or not applicable, a country code of \"XX\" should\nbe used.\n\nTags with numerical values may allow units of measurement to be specified. The units string is\nstored in brackets at the end of the tag name, and is composed of zero or more ASCII characters\nin the range 0x21 to 0x7d, excluding the bracket characters 0x28 and 0x29. (eg.\n\"Resolution(/cm)\" or \"SpecificHeat(J/kg.K)\".) See Image::ExifTool::MIEUnits for details. Unit\nstrings are not localized, and may not be used in combination with localized text strings.\n\nSets of tags which would require a common prefix should be added in a separate MIE group instead\nof adding the prefix to all tag names. For example, instead of these TagName's:\n\nExternalFlashType\nExternalFlashSerialNumber\nExternalFlashFired\n\none would instead designate a separate \"ExternalFlash\" MIE group to contain the following\nelements:\n\nType\nSerialNumber\nFired\n\nDataLength2/4/8\nThese extended DataLength fields exist only if DataLength is 255, 254 or 253, and are\nrespectively 2, 4 or 8 byte unsigned integers giving the data block length. One of these values\nmust be used if the data block is larger than 252 bytes, but they may be used if desired for\nsmaller blocks too (although this may add a few unnecessary bytes to the MIE element).\n\nDataBlock\nThe data value for the MIE element. The format of the data is given by the FormatCode. For MIE\ngroup elements, the data includes all contained elements and the group terminator.\n\nMIE groups\nAll MIE data elements must be contained within a group. A group begins with a MIE group element,\nand ends with a group terminator. Groups may be nested in a hierarchy to arbitrary depth.\n\nA MIE group element is identified by a format code of 0x10 (big endian byte ordering) or 0x18\n(little endian). The group terminator is distinguished by a zero TagLength (it is the only\nelement allowed to have a zero TagLength), and has a FormatCode of 0x00.\n\nThe MIE group element is permitted to have a zero DataLength only if the data is uncompressed.\nThis special value indicates that the group length is unknown (otherwise the minimum value for\nDataLength is 4, corresponding the the minimum group size which includes a terminator of at\nleast 4 bytes). If DataLength is zero, all elements in the group must be parsed until the group\nterminator is found. If non-zero, DataLength includes the length of all elements contained\nwithin the group, including the group terminator. Use of a non-zero DataLength is encouraged\nbecause it allows readers quickly skip over entire MIE groups. For compressed groups DataLength\nmust be non-zero, and is the length of the compressed group data (which includes the compressed\ngroup terminator).\n\nGroup Terminator\nThe group terminator has a FormatCode and TagLength of zero. The terminator DataLength must be\n0, 6 or 10 bytes, and extended DataLength codes may not be used. With a zero DataLength, the\nbyte sequence for a terminator is \"7e 00 00 00\" (hex). With a DataLength of 6 or 10 bytes, the\nterminator data block contains information about the length and byte ordering of the preceding\ngroup. This additional information is recommended for file-level groups, and is used in\nmulti-document MIE files and MIE trailers to allow the file to be scanned backwards from the\nend. (This may also allow some documents to be recovered if part of the file is corrupted.) The\nstructure of this optional terminator data block is as follows:\n\n4 or 8 bytes GroupLength (unsigned integer)\n1 byte ByteOrder (0x10 or 0x18, same as MIE group)\n1 byte GroupLengthSize (0x04 or 0x08)\n\nThe ByteOrder and GroupLengthSize values give the byte ordering and size of the GroupLength\ninteger. The GroupLength value is the total length of the entire MIE group ending with this\nterminator, including the opening MIE group element and the terminator itself.\n\nFile-level MIE groups\nFile-level MIE groups may NOT be compressed.\n\nAll elements in a MIE file are contained within a special group with a TagName of \"0MIE\". The\npurpose of the \"OMIE\" group is to provide a unique signature at the start of the file, and to\nencapsulate information allowing files to be easily combined. The \"0MIE\" group must be\nterminated like any other group, but it is recommended that the terminator of a file-level group\ninclude the optional data block (defined above) to provide information about the group length\nand byte order.\n\nIt is valid to have more than one \"0MIE\" group at the file level, allowing multiple documents in\na single MIE file. Furthermore, the MIE structure enables multi-document files to be generated\nby simply concatenating two or more MIE files.\n" }, { "name": "Scanning Backwards through a MIE File", "content": "The steps below give an algorithm to quickly locate the last document in a MIE file:\n\n1. Read the last 10 bytes of the file. (Note that a valid MIE file may be as short as 12 bytes\nlong, but a file this length contains only an an empty MIE group.)\n\n2. If the last byte of the file is zero, then it is not possible to scan backward through the\nfile, so the file must be scanned from the beginning. Otherwise, proceed to the next step.\n\n3. If the last byte is 4 or 8, the terminator contains information about the byte ordering and\nlength of the group. Otherwise, stop here because this isn't a valid MIE file.\n\n4. The next-to-last byte must be either 0x10 indicating big-endian byte ordering or 0x18 for\nlittle-endian ordering, otherwise this isn't a valid MIE file.\n\n5. The value of the preceding 4 or 8 bytes gives the length of the complete file-level MIE\ngroup (GroupLength). This length includes both the leading MIE group element and the\nterminator element itself. The value is an unsigned integer with a byte length given in step\n3), and a byte order from step 4). From the current file position (at the end of the data\nread in step 1), seek backward by this number of bytes to find the start of the MIE group\nelement for this document.\n\nThis algorithm may be repeated again beginning at this point in the file to locate the\nnext-to-last document, etc.\n\nThe table below lists all 5 valid patterns for the last 14 bytes of a file-level MIE group, with\nall numbers in hex. The comments indicate the length and byte ordering of GroupLength (xx) if\navailable:\n\n?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 7e 00 00 00 - (no GroupLength)\n?? ?? ?? ?? 7e 00 00 06 xx xx xx xx 10 04 - 4 bytes, big endian\n?? ?? ?? ?? 7e 00 00 06 xx xx xx xx 18 04 - 4 bytes, little endian\n7e 00 00 0a xx xx xx xx xx xx xx xx 10 08 - 8 bytes, big endian\n7e 00 00 0a xx xx xx xx xx xx xx xx 18 08 - 8 bytes, little endian\n" }, { "name": "Trailer Signature", "content": "The MIE format may be used for trailer information appended to other types of files. When this\nis done, a signature must appear at the end of the main MIE group to uniquely identify the MIE\nformat trailer. To achieve this, a \"zmie\" trailer signature is written as the last element in\nthe main \"0MIE\" group. This element has a FormatCode of 0, a TagLength of 4, a DataLength of 0,\nand a TagName of \"zmie\". With this signature, the hex byte sequence \"7e 00 04 00 7a 6d 69 65\"\nappears immediately before the final group terminator, and the last 22 bytes of the trailer\ncorrespond to one of the following 4 patterns (where the trailer length is given by \"xx\", as\nabove):\n\n?? ?? ?? ?? 7e 00 04 00 7a 6d 69 65 7e 00 00 06 xx xx xx xx 10 04\n?? ?? ?? ?? 7e 00 04 00 7a 6d 69 65 7e 00 00 06 xx xx xx xx 18 04\n7e 00 04 00 7a 6d 69 65 7e 00 00 0a xx xx xx xx xx xx xx xx 10 08\n7e 00 04 00 7a 6d 69 65 7e 00 00 0a xx xx xx xx xx xx xx xx 18 08\n\nNote that the zero-DataLength terminator may not be used here because the trailer length must be\nknown for seeking backwards from the end of the file.\n\nMultiple trailers may be appended to the same file using this technique.\n\nMIE Data Values\nMIE data values for a given tag are usually not restricted to a specific FormatCode. Any value\nmay be represented in any appropriate format, including numbers represented in string (ASCII or\nUTF) form.\n\nIt is preferred that closely related values with the same format are written to a single tag\ninstead of using multiple tags. This improves localization of like values and decreases MIE\nelement overhead. For instance, instead of separate ImageWidth and ImageHeight tags, a single\nImageSize tag is defined.\n\nTags which may take on a discrete set of values should have meaningful values if possible. This\nimproves the extensibility of the format and allows a more reasonable interpretation of\nunrecognized values.\n\nNumerical Representation\nInteger and floating point numbers may be represented in binary or string form. In string form,\nintegers are a series of digits with an optional leading sign (eg. \"[+|-]DDDDDD\"), and multiple\nvalues are separated by a single space character (eg. \"23 128 -32\"). Floating point numbers are\nsimilar but may also contain a decimal point and/or a signed exponent with a leading 'e'\ncharacter (eg. \"[+|-]DD[.DDDDDD][e(+|-)EEE]\"). The string \"inf\" is used to represent infinity.\nOne advantage of numerical strings is that they can have an arbitrarily high precision because\nthe possible number of significant digits is virtually unlimited.\n\nNote that numerical values may have associated units of measurement which are specified in the\n\"TagName\" string.\n\nDate/Time Format\nAll MIE dates are strings in the form \"YYYY:mm:dd HH:MM:SS.ss+HH:MM\". The fractional seconds\n(\".ss\") are optional, and if included may contain any number of significant digits (unlike all\nother fields which are a fixed number of digits and must be padded with leading zeros if\nnecessary). The timezone (\"+HH:MM\" or \"-HH:MM\") is recommended but not required. If not given,\nthe local system timezone is assumed.\n\nMIME Type\nThe basic MIME type for a MIE file is \"application/x-mie\", however the specific MIME type\ndepends on the type of subfile, and is obtained by adding \"x-mie-\" to the MIME type of the\nsubfile. For example, with a subfile of type \"image/jpeg\", the MIE file MIME type is\n\"image/x-mie-jpeg\". But note that the \"x-\" is not duplicated if the subfile MIME type already\nstarts with \"x-\". So a subfile with MIME type \"image/x-raw\" is contained within a MIE file of\ntype \"image/x-mie-raw\", not \"image/x-mie-x-raw\". In the case of multiple documents in a MIE\nfile, the MIME type is taken from the first document. Regardless of the subfile type, all\nMIE-format files should have a filename extension of \".MIE\".\n" }, { "name": "Levels of Support", "content": "Basic MIE reader/writer applications may choose not to provide support for some advanced\nfeatures of the MIE format. Features which may not be supported by all software are:\n\nCompression\nSoftware not supporting compression must ignore compressed elements and groups, but should\nbe able to process the remaining information.\n\nLarge data lengths\nSome software may limit the maximum size of a MIE group or element. Historically, a limit of\n2GB may be imposed by some systems. However, 8-byte data lengths should be supported by all\napplications provided the value doesn't exceed the system limit. (eg. For systems with a 2GB\nlimit, 8-byte data lengths should be supported if the upper 17 bits are all zero.) If a data\nlength above the system limit is encountered, it may be necessary for the application to\nstop processing if it can not seek to the next element in the file.\n" } ] }, "EXAMPLES": { "content": "This section gives examples for working with MIE information using ExifTool.\n", "subsections": [ { "name": "Encapsulating Information with Data in a MIE File", "content": "The following command encapsulates any file recognized by ExifTool inside a MIE file, and\ninitializes MIE tags from information within the file:\n\nexiftool -o new.mie -tagsfromfile FILE '-mie:all> dst.jpg\n\nOnce added, ExifTool may be used to edit or delete a MIE trailer in a JPEG or TIFF image.\n" }, { "name": "Multiple MIE Documents in a Single File", "content": "The MIE specification allows multiple MIE documents (or trailers) to exist in a single file. A\nfile like this may be created by simply concatenating MIE documents. ExifTool may be used to\naccess information in a specific document by adding a copy number to the MIE group name. For\nexample:\n\n# write the Author tag in the second MIE document\nexiftool -mie2:author=phil test.mie\n\n# delete the first MIE document from a file\nexiftool -mie1:all= test.mie\n" }, { "name": "Units of Measurement", "content": "Some MIE tags allow values to be specified in different units of measurement. In the MIE file\nformat these units are combined with the tag name, but when using ExifTool they are specified in\nbrackets after the value:\n\nexiftool -mie:gpsaltitude='7500(ft)' test.mie\n\nIf no units are provided, the default units are written.\n" }, { "name": "Localized Text", "content": "Localized text values are accessed by adding a language/country code to the tag name. For\nexample:\n\nexiftool -comment-enus='this is a comment' test.mie\n" } ] }, "REVISIONS": { "content": "2010-04-05 - Fixed \"Format Size\" Note 7 to give the correct number of bits\nin the example rational value\n2007-01-21 - Specified LF character (0x0a) for text newline sequence\n2007-01-19 - Specified ISO 8859-1 character set for extended ASCII codes\n2007-01-01 - Improved wording of Step 5 for scanning backwards in MIE file\n2006-12-30 - Added EXAMPLES section and note about UTF BOM\n2006-12-20 - MIE 1.1: Changed meaning of TypeModifier bit (0x08) for\nunknown data (FormatType 0x00), and documented byte swapping\n2006-12-14 - MIE 1.0: Added Data Values and Numerical Representations\nsections, and added ability to specify units in tag names\n2006-11-09 - Added Levels of Support section\n2006-11-03 - Added Trailer Signature\n2005-11-18 - Original specification created\n", "subsections": [] }, "AUTHOR": { "content": "Copyright 2003-2022, Phil Harvey (philharvey66 at gmail.com)\n\nThis library is free software; you can redistribute it and/or modify it under the same terms as\nPerl itself. The MIE format itself is also copyright Phil Harvey, and is covered by the same\nfree-use license.\n", "subsections": [] }, "REFERENCES": { "content": "\n", "subsections": [] }, "SEE ALSO": { "content": "\"MIE Tags\" in Image::ExifTool::TagNames, Image::ExifTool::MIEUnits, Image::ExifTool(3pm)\n", "subsections": [] } } } }