| 84656 packages online |
|
|
| docs/misc/IFF-metadata.lha | | | No screenshot available |
|
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.
|
Contents of docs/misc/IFF-metadata.lha 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
|
|
|
|
Aminet © 1992-2024 Urban
Müller and
the Aminet team.
Aminet contact address: <aminetaminet net> |