Part 3: Transmittal format binary encoding
The topics in this clause are listed in Table 6.1.
This clause specifies the binary encoding for each non-abstract (i.e., concrete) DRM class that may be represented in a transmittal. Also specified is the encoding of transmittal constructs such as header information. 5 Encoding of data types specifies the encoding of each data type that can be used in a transmittal. In the following text, upper case is used for the names of bit fields while lower case is used to specify the contents of bit fields.
Each non-abstract DRM class specified in 6.3.DRM class specifications of Part 1 of ISO/IEC 18023 may be instanced to create a DRM object within the transmittal. The abstract syntax of an STF-encoded representation of a DRM object is:
<object instance> ::= <object header>
<object field>* (see 6.2.7 <object field>)<object header> ::= <header control> (see 6.2.2 <header control>)
<field offset>0 (see 6.2.3 <field offset>)
<aggregate count>0 (see 6.2.4 <aggregate list> and <aggregate count>)
<associate count>0 (see 6.2.5 <associate list> and <associate count>)
<component count>0 (see 6.2.6 <component list> and <component count>)
<aggregate list>0 (see 6.2.4 <aggregate list> and <aggregate count>)
<associate list>0 (see 6.2.5 <associate list> and <associate count>)
<component list>0 (see 6.2.6 <component list> and <component count>)
The non-terminal abstract syntax elements above are expanded into more detailed syntax in the remainder of 6.2. Together these STF abstract syntax elements encode the abstract syntax elements specified in 5.2.8 DRM objects of Part 2 of ISO/IEC 18023.
One occurrence of this element and the values of its bit fields determines the number of occurrences of the <field offset>, <aggregate count>, <aggregate list>, <associate count>, <association list>, <component count>, <component list>, and <object field> elements (see 6.2.2 <header control>).
The abstract syntax of the <header control> element is:
<header control> ::= <field flag>
<aggregate control>
<association control>
<component control>
The <header control> element is encoded in a single octet divided into four fields as specified in Figure 6.1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
<field flag> |
<aggregate control> |
<associate control> |
<component control> |
||||
Figure 6.1 — <header control> element fields
The meanings of the encoded values of each bit field as well as how those values affect the number of occurrences of other elements in the productions specified in 6.2.1 Introduction are:
The <field flag> element determines if the <field offset> element occurs:
'0' The <field offset> element is not present (that is, the number of occurrences of the <field offset> element is zero).
'1' The <field offset> element is present (that is, the number of occurrences of the <field offset> element is exactly one).
The <aggregate control> element determines if the <aggregate count> and <aggregate list> elements occur:
'00' The object has no aggregates. The <aggregate count> element and the <aggregate list> elements do not occur.
'01' The object has one aggregate. The <aggregate count> element does not occur. The <aggregate list> element occurs exactly once and contains exactly one reference.
'10' The object has two aggregates. The < aggregate count> element does not occur. The <aggregate list> element occurs exactly once and contains exactly two references.
'11' The object has more than two aggregates. The <aggregate count> element occurs exactly once and specifies the number of references in the <aggregate list>. The <aggregate list> element occurs exactly once and contains the number of references specified in the <aggregate count> element.
The <associate control> element determines if the <associate count> and <associate list> elements occur:
'00' The object has no associations. The <associate count> element and the <associate list> elements do not occur.
'01' The object has one association. The <associate count> element does not occur. The <associate list> element occurs exactly once and contains exactly one reference.
'10' The object has two associations. The <associate count> element does not occur. The <associate list> element occurs exactly once and contains exactly two references.
'11' The object has more than two associations. The <associate count> element occurs exactly once and specifies the number of references in the <associate list>. The <associate list> element occurs exactly once and contains the number of references specified in the <associate count> element.
The <component control> element determines if the <component count> and <component list> elements occur:
'000' The object has no components. The <component count> element and the <component list> elements do not occur.
'001' – '110' The object has the number of components specified by the binary value of the <component control> field when considered as an integer between 1 and 6 inclusive. The <component count> element does not occur. The <component list> element occurs exactly once and contains exactly the number of references (between 1 and 6 inclusive) specified by this field.
'111' The object has more than six components. The <component count> element occurs exactly once and specifies the number of references in the <component list>. The <component list> element occurs exactly once and contains the number of references specified in the <component count> element.
The <field_offset> specifies the offset in octets from the beginning of the object to the first field. The <field_offset> element is encoded as specified in 5.2.4.2 OCE8_Unsigned.
If this object instance is a component of other object instances, the <aggregate list> element represents a list of references (see 6.2.8 Encoding of object reference lists) to all such object instances.
The <aggregate count> element determines the number of references in the <aggregate list> when the number of references is greater than two. The <aggregate control> bit field of the <header control> element (see 6.2.2 <header control>) determines the number of references in the <aggregate list> when the number of references is two or less. The <aggregate list> element does not occur when the number of references in the aggregate list is zero.
There is one reference represented in the <aggregate list> of a DRM object A to each DRM object B of which A is an aggregate (that is, B is composed of A).
EXAMPLE Table 6.3 DRM_Absolute_Time_Interval of Part 1 ISO/IEC 18023 specifies that the <DRM Absolute Time Interval> class is Composed of (two-way) one <DRM Absolute Time> instance. Therefore, the <aggregate list> for the instance of DRM class <DRM Absolute Time> that <DRM Absolute Time Interval> is composed of contains exactly one reference to this DRM object whose DRM class is <DRM Absolute Time Interval>.
If this object instance has association relationships with other object instances, the <association list> element represents a list of references (see 6.2.8 Encoding of object reference lists) to all such object instances.
The <associate count> element determines the number of references in the <associate list> when the number of references is greater than two. The <associate control> bit field of the <header control> element (see 6.2.2 <header control>) determines the number of references in the <associate list> when the number of references is two or less. The <associate list> element does not occur when the number of references in the <associate list> is zero.
There is one reference represented in the <association list> of a DRM object A to each DRM object that A is associated with.
EXAMPLE Table 6.93 DRM_Geometry_Edge of Part 1 of ISO/IEC 18023 specifies that a DRM object whose DRM Class is <DRM Geometry Edge> is associated with exactly two DRM objects of DRM class<DRM Geometry Node> (and may, in addition, be optionally associated with other DRM objects.) Therefore, the <association list> for an DRM object of DRM class <DRM Geometry Edge> contains at least two references to DRM objects of DRM class <DRM Geometry Node> and may, in addition, contain references to other DRM objects.
If this object is a composed of other object instances, the <component list> element represents a list of references (see 6.2.8 Encoding of object reference lists) to all such object instances.
The <component count> element determines the number of references in the <component list> when the number of references is greater than two. The <component control> sub-element of the <header control> element (see 6.2.2 <header control>) determines the number of references in the <component list> when the number of references is two or less. The <component list> element does not occur when the number of references in the <component list> is zero.
There is one reference represented in the <component list> of a DRM object A to each DRM object that A is composed of.
EXAMPLE 1 Table 6.3 DRM_Absolute_Time_Interval of Part 1 ISO/IEC 18023 specifies that a DRM object whose DRM Class is <DRM Absolute Time Interval> is Composed of (two-way) one <DRM Absolute Time> instance. Therefore, the <component list> for an DRM object of DRM class <DRM Absolute Time Interval> contains exactly one reference to the DRM object whose DRM class is <DRM Absolute Time> that it is composed of.
EXAMPLE 2 Table 6.3.24 DRM_Blend_Directional_Light of Part 1 ISO/IEC 18023 specifies that a DRM object whose DRM Class is <DRM Absolute Time Interval> is Composed of (two-way) (inherited) one <DRM Lobe Data> instance and one <DRM Location> instance. Therefore, the <component list> for an instance of this DRM class contains exactly two references, one to a DRM object whose DRM class is <DRM Lobe Data> and another to a DRM object whose DRM class is <DRM Location>.
For each field of the object instance (see 6.3 of Part 1 of ISO/IEC 18023), one occurrence of this element represents the value of that field.
The field data for an object (if needed) shall immediately follow the last reference list item (or the object header if all reference lists are empty). The fields shall be encoded in the order specified in 6.3 DRM classes of Part 1 of ISO/IEC 18023.
Each instance of <object field> shall be encoded as an instance of its data type. The encoding of each data type used in this part of ISO/IEC 18023 is specified in 5 Encoding of data types.
The <aggregate count>, <associate count>, and <component count> elements are each encoded as specified in 5.2.4.2 OCE8_Unsigned.
The abstract syntax of the three list elements is further specified as follows:
<aggregate list> ::= <object reference>+
<association list> ::= <object reference>+
<component list> ::= <object reference>+
<object reference> ::= <local reference> |
<non-local reference> |
<non-local reference with local link> |
<non-local reference with non-local link><local reference> ::= '1'
<LOCAL OBJECT INDEX><non-local reference> ::= '0'
'0'
<non-local specific reference><non-local reference with local link> ::= '0'
'1'
<non-local specific reference>
<local reference><non-local reference with non-local link> ::= '0'
'1'
<non-local specific reference>
<non-local reference><non-local specific reference> ::= <near block reference> |
<far block reference> |
<other block reference> |
<inter-transmittal reference>
4.3.3.3 Object data and object referencing specifies how each <object reference> is conceptually composed of three indices that are together called the FBO of the object. The following subclauses further specify the syntax and encoding of <object reference> in terms of the FBO of the object making the reference.
The <local reference> element is encoded in a single eight-bit octet as depicted in Figure 6.2.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
'1' |
<LOCAL OBJECT INDEX> |
||||||
Figure 6.2 — <local reference>
The high order bit shall be '1' indicating that this is a local reference. The low-order seven bits represent the <LOCAL OBJECT INDEX>. The file and block index of the FBO (see 4.3.3.3 Object data and object referencing) are not specified and shall be the same file and block as the referencing object. The object index of the FBO is determined from <LOCAL OBJECT INDEX> interpreted as an unsigned integer as follows:
There are three forms of non-local reference:
<non-local reference>
<non-local reference with local link>
<non-local reference with non-local link>
The three forms of reference depend on the value of bit 6 of the first octet which represents the link flag. If the link flag has value '0', <non-local reference> in 6.2.8.1 Introduction specifies the form of the reference. If the link flag has value '1', either <non-local reference with local link> or <non-local reference with non-local link> specifies the form of the reference depending on whether the reference to the link object is a local reference or a non-local reference.
For non-local references, there are four types of non-local references. This subclause describes the conceptual layout of a non-local specific reference. Each type of reference is individually defined in subsequent subclauses. However, the overall form is as depicted in Figure 6.3.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
'0' |
link flag |
reference-specific information |
|
index octet 1 |
|
index octet 2 |
|||||||||||||||||||
Figure 6.3 — Non-local specific reference general form
In each of the <non-local specific reference> types specified below, the meanings of the encoded values that represent the three elements that make up a <non-local reference header> element as well as how those values affect the number of occurrences of other elements in the productions are:
a. Bit 6 encodes the link flag element that specifies if a link object reference is present. It shall have the following meaning:
'0' denotes that there is no link object reference .
'1' denotes that there is a link object reference.
b. The reference-specific information varies depending on the value of bits 4 and 5. Bits 0-3 have meaning as specified for the specific type of reference. The bit sequences below represent bits 4 and 5 and described the meaning of bits 0-3 for the respective value:
'00' The reference is a <near block reference> and the value of bits 0-3 shall be interpreted as described in 6.2.8.4.2 <near block reference>.
'01' The reference is a <far block reference> and the value of bits 0-3 shall be interpreted as described in 6.2.8.4.3 <far block reference>.
'10' The reference is an <other file reference> and the value of bits 0-3 shall be interpreted as described in 6.2.8.4.4 <other file reference>.
'11' The reference is an <inter-transmittal reference> and the value of bits 0-3 shall be interpreted as described in 6.2.8.4.5 <inter-transmittal file reference>.
The existence and meaning of the index 1 and index 2 octets depends on the value of bits 4 and 5 of the first octet. The detailed encoding for each non-local reference type is specified in the remainder of 6.2.8.3.
The syntax of the <near block reference> element as illustrated in Figure 6.4 is:
<near block reference> ::= '00' <NEAR BLOCK INDEX>
<OBJECT INDEX>
The values of the file index and block index (see 4.3.3.3 Object data and object referencing) for the referenced object are specified as follows:
Figure 6.4 — Near-block reference
For a near-block reference, <OBJECT INDEX> is represented by index octet 1 of the general form (see 6.2.8.4.1 General form). Index octet 2 does not occur.
The syntax of the <far block reference> element as illustrated in Figure 6.5 is:
<far block reference> ::= '01' <HIGH ORDER BLOCK INDEX>
<LOW ORDER BLOCK INDEX>
<OBJECT INDEX>
The <HIGH ORDER BLOCK INDEX> is encoded in bits 0-3 of the first octet. The <LOW ORDER BLOCK INDEX> element is encoded in index octet 1 (see 6.2.8.4.1 General form). The values of the file index and block index (see 4.3.3.3 Object data and object referencing) for the referenced object are specified as follows:
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
'0' |
l |
'01' |
<HIGH ORDER BLOCK INDEX> |
|
<LOW ORDER BLOCK INDEX> |
|
<OBJECT INDEX> |
||||||||||||||||||
Figure 6.5 — Far-block reference
For a far-block reference, <OBJECT INDEX> is represented by index octet 2 of the general form.
The syntax of the <other file reference> element as illustrated in Figure 6.6 is:
<other file reference> ::= '10' <HIGH ORDER BLOCK INDEX>
<LOW ORDER BLOCK INDEX>
<OBJECT INDEX>
<REFERENCED FILE INDEX>
The <HIGH ORDER BLOCK INDEX> is encoded in bits 0-3 of the first octet. The <LOW ORDER BLOCK INDEX> element is encoded in index octet 1 (see 6.2.8.4.1 General form). The <OBJECT INDEX> is encoded in index octet 2. The <REFERENCED FILE INDEX> element is encoded as specified in 5.2.4.2 OCE8_Unsigned after index octet 2. The values of the file index and block index (see 4.3.3.3) for the referenced object are specified as follows:
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
|
'0' |
l |
'10' |
<HIGH ORDER BLOCK INDEX> |
|
<LOW ORDER BLOCK INDEX> |
|
<OBJECT INDEX> |
|
<REFERENCED FILE INDEX> |
||||||||||||||||||
Figure 6.6 — Other file reference
The syntax of the <inter-transmittal reference> element as illustrated in Figure 6.7 is:
<inter-transmittal reference> ::= '11' <4_BIT_PADDING>
<ITR REFERENCED OBJECTS TABLE INDEX>
Bits 0-3 of the first octet are not used and may be encoded with any value. The <object reference table index> element is encoded as specified in 5.2.4.2 OCE8_Unsigned. The referenced object is located by resolving the inter-transmittal reference by the following process:
Figure 6.7 — Inter-transmittal reference
An STF root file encodes the production rule specified in 5.2.4 Transmittal root file grammar of Part 2 of ISO/IEC 18023.
The fields in the root file header shall be as specified below. All offsets shall be specified in octets from the beginning of the file. An offset is a specification of the number of octets to skip from the beginning of the file.
Magic number : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
Endianess : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
E |
where:
E indicates the endianess of the encoding of the entire transmittal:
0 The entire transmittal is encoded big endian.
1 The entire transmittal is encoded little endian.
File major version number : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
File major version |
|||||||
File minor version number : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
File minor version |
|||||||
|
software_version : STF_Characters1 |
|
root_object_file_fbo : STF_FBO |
|
master_file_table_size : STF_Integer_Unsigned |
|
master_file_table_offset : STF_Integer_Unsigned |
|
ITR_referenced_transmittals_table_size : STF_Integer_Unsigned |
|
ITR_referenced_transmittals_table_offset : STF_Integer_Unsigned |
|
ITR_referenced_objects_table_size : STF_Integer_Unsigned |
|
ITR_referenced_objects_table_offset : STF_Integer_Unsigned |
|
published_objects_table_size : STF_Integer_Unsigned |
|
published_objects_table_offset : STF_Integer_Unsigned |
|
unique_transmittal_identifier : Byte_Unsigned[20] |
|
transmittal_name : STF_Characters2 |
|
root_file_name : STF_Characters3 |
1The buffer in which software_version is stored is 64 octets in length. Unused octets shall be padded with NULL characters.
2The buffer in which transmittal_name is stored is 256 octets in length. Unused octets shall be padded with NULL characters.
3The buffer in which root_file_name is stored is 128 octets in length. Unused octets shall be padde35with NULL characters.
The master file table shall start at the offset given in the root file header. The master file table shall contain the list of STF object and STF ImgDTData files that comprise the transmittal. Each entry in this list shall be a NULL terminated file name (i.e., a string comprised of UTF-8 character) of maximum length 256 octets. Path names are not encoded. Unused octets shall be padded with NULL characters. An index into this table shall be used to identify in which file an object is stored. The ‘F’ in an FBO object reference shall be an index into the master file table.
The ITR referenced transmittal table shall start at the offset given in the root file header. This shall be used to implement ITR references from this transmittal to other transmittals. Each entry shall be a NULL terminated transmittal name (i.e., a string of type STF_Characters) of a transmittal that is referenced by this transmittal. The size of the buffer for the transmittal name is 256 octets. Unused octets shall be padded with NULL characters.
The ITR Referenced Object Table shall start at the offset given in the root file header. This shall be used to implement ITR references from this transmittal to other transmittals. The table shall contain an entry for each ITR reference in this transmittal. An entry shall consist of an index into the ITR referenced transmittal list specified as a OCE8_Unsigned number, and a NULL terminated object label (i.e., a string of type STF_Characters) that shall match the published label of an object in the referenced transmittal. The string shall have maximum length of 256 octets including the terminating NULL character. Unused octets in each entry shall be padded with NULL characters.
The published object table shall start at the offset given in the root file header. This shall be a table of all the objects in this transmittal that are allowed to be referenced by other transmittals. The size of the table is specified in the root file header (see 6.3.1.1 Root file header).
Immediately following, there shall be an entry with the following format for each published object:
|
published_object_label : STF_Characters1 |
|
reference_to_published_object : STF_FBO |
1The buffer in which published_object_label is stored is 256 octets in length. Unused octets shall be padded with NULL characters.
An STF-encoded transmittal may have from 1 to 30000 STF object files. These files shall be ordered according to their position in the root file’s master file table. The ordering shall be zero-based.
Each STF Object file shall contain no more than 4096 blocks.
The STF object file encodes the produciton rules specified in 5.2.5 Transmittal object file grammar of Part 2 of ISO/IEC 18023.
The fields of the file header are specified below. All offsets shall be specified in bytes from the beginning of the file.
magic_number : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 |
1 |
1 |
1 |
0 |
1 |
1 |
1 |
File major version number : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
File major version |
|||||||
File minor version number : STF_Byte_Unsigned
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
File minor version |
|||||||
|
referenced_file_count : STF_Short_Integer_Unsigned |
|
referenced_file_table_offset : STF_Integer_Unsigned |
|
block_count : STF_Short_Integer_Unsigned |
|
block_table_offset : STF_Integer_Unsigned |
|
compressed_block_count : STF_Short_Integer_Unsigned |
|
compressed_block_table_offset : STF_Integer_Unsigned |
|
root_file_name : STF_Characters1 |
1The buffer in which root_file_name is stored is 128 octets in length. Unused octets shall be padded with NULL characters.
The reference file table shall contain the index into the master file table containing all files that this STF object file references. An entry of the following form shall be provided for each referenced file in the table.
|
referenced_file_index : STF_Short_Integer_Unsigned |
The Block Table is an array of entries, each of which consists of a block size and a block offset as depicted below. The block table entries are not required to be ordered by block offset. The number of entries is specified by the block_count field of the file header (see 6.3.2.2 File header). The block_index of the FBO (see 4.3.3.3 Object data and object referencing) selects an entry in this table.
|
block_size : STF_Integer_Unsigned |
|
block_offset : STF_Integer_Unsigned |
The compressed block table specifies the uncompressed sizes for each block. The size of this table shall be either 0 or the same size as the block table depending on whether there are any compressed blocks in the file. If a block has been compressed, the block’s entry in the block table shall specify the compressed size and the value in the compressed blocks table shall specify the uncompressed size. For blocks that are uncompressed, the compressed_block_size shall be zero.
|
uncompressed_block_size : STF_Short_Integer_Unsigned |
The following STF block format specifies offsets and sizes based on an uncompressed block. Whether a block is compressed or not shall be determined from its entry in the compressed block table as described above.
Each STF block shall contain no more than 256 objects.
The block header shall consist of two fields.
The first field is of type STF_Integer_Unsigned and shall specify the offset in octets from the beginning of the block to the object pointer table at the end of the block:
|
object_pointer_table_offset : STF_Integer_Unsigned |
The second field is of type STF_Byte_Unsigned and shall specify the last_object_index. This shall be the highest object index used in the block:
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
last_object_index |
|||||||
The number of objects in the block shall be:
last_object_index + 1
NOTE Some of the objects may have been deleted.
The block header shall be followed by a table of nine-bit fields for the object types of each of the objects in the block. This table shall always contain 256 entries (288 bytes) regardless of the number of objects in the block. For objects past the last_object_index, the object type shall be set to zero. For STF object files, the type of the object shall represent the DRM class of the object. For STF ImgDTData Files where the objects do not represent a DRM object, the object type shall indicate whether the object is an IMAGE_DATA, DT_DATA, DT_BLOCK_DATA, or DT_BLOCK_PARAMS object.
STF object data shall consist of no more than 256 STF objects, the offsets of which are specified in the object pointer table as described in 6.3.3.5 Object pointer table. For STF object files, the object data shall represent DRM objects and their relationships. The format of these STF objects shall be as described in 6.2 DRM object structure syntax and encoding. For STF ImgDTData Files, the object data represents STF-specific objects for image and data table data. These objects shall be as specified in 6.3.4 STF ImgDTData files.
The object pointer table shall contain an object pointer for each object in the block. These objects shall be objects with indexes in the range 0..last_object_index. Each object pointer shall be encoded as specified in 5.2.4.2 OCE8_Unsigned. The object pointer shall either be an offset or a sentinel value of 1. The offset specifies the location of the STF object data in the block. The offset shall be specified as a number of octets and shall be relative to the beginning of the uncompressed block. The offsets are not required to be in increasing order. An object’s size shall be determined by subtracting the object’s offset from the smallest object offset that is larger than the object’s own offset. The size of the last object shall be determined from its offset and the size of the block. The sentinel value 1 shall be reserved as an object pointer value to indicate objects that have been deleted from the transmittal and that this object index may not be reused.
This object shall specify the image data for one mip level of a DRM_Image. Each DRM_Image object shall have component references to all IMAGE_DATA objects containing image data for the DRM_Image. These references are not DRM-specified aggregation relationships since the IMAGE_DATA object is not a DRM object. However, STF shall use the same encoding method as is used for DRM relationships. This encoding shall be as specified in 6.2 DRM object structure syntax and encoding. These component references shall be ordered so that the position of an IMAGE_DATA object indicates the mip level for which the image data applies. Mip levels shall be ordered from smallest to largest.
The IMAGE_DATA object is assigned the object type value of 511. This value is used only in the object type type table of the STF block (see 6.3.3.3 Object type table).
There shall be no references from IMAGE_DATA objects to other objects; hence, there shall be no object header similar to STF object headers. Each mip level of the data is encoded as specified in 5.3.7.16 Image_Data:
|
image_data : Image_Data |
An STF ImgDTData file containing image data encodes the production rules specified in 5.2.6 Transmittal image file grammar of Part 2 of ISO/IEC 18023.
Each DRM_DataTable object shall have one or more component references to DT_DATA objects. These references are not DRM-specified aggregation relationships since the DT_DATA object is not a DRM object. However, STF shall use the same encoding method as is used for DRM relationships as specified in 6.2 DRM object structure syntax and encoding. These component references shall be ordered so that the position of a DT_DATA object indicates which element of the data table the DT_DATA object represents. A DRM_Data_Table shall have one or more ordered DRM_Table_Property_Description objects that define the elements of the data table. The first DT_DATA component of the DRM_Data_Table shall describe the data table elements for the first DRM_Table_Property_Description object.
The DT_DATA object is assigned the object type value of 510. This value is used only in the object type type table of the STF block (see 6.3.3.3 Object type table).
The DT_DATA object shall have the structure specified in Table 6.3:
The DT_DATA object does not store the data table data directly, but rather serves to organize the DT_BLOCK_DATA objects which do. The DT_DATA object shall have no fields. It shall have one or more component references to DT_BLOCK_DATA objects with a component link reference to a DT_BLOCK_PARAMS object. These component with link references shall be stored using the same encoding as STF objects as is described in 6.2 DRM object structure syntax and encoding. However, the fields offset, aggregate count and associate count bit fields in the object header shall all be set to zero since they do not apply to DT_DATA objects.
The first byte of the DT_DATA object shall be an object header with the following format:
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 |
00 |
00 |
DDD |
||||
where DDD specifies the component count as described in 6.2.2 <header control>.
The component object reference list shall consist of a list of object references all of which shall contain link object references. The format of this reference list shall be identical to the reference lists of DRM objects as specified in 6.2.8 Encoding of object reference lists.
The first field of a DT_BLOCK_DATA object shall specify the size in octets of the block data array stored in the block. Immediately following this shall be an array of Byte_Unsigned values representing the block data. The meaning and format of this block data array shall be as described in 4.3.4.2 Data table data storage.
The DT_BLOCK_DATA object is assigned the object type value of 509. This value is used only in the object type type table of the STF block (see 6.3.3.3 Object type table).
The DT_BLOCK_DATA object shall have the following layout:
|
block_data_array : Byte_Unsigned[block_data_array_size : Integer_Unsigned] |
An STF ImgDTData file containing data table data encodes the production rules specified in 5.2.7 Transmittal data table data file grammar of Part 2 of ISO/IEC 18023.
The DT_BLOCK_PARAMS object shall contain information needed to describe the meaning and format of the DT_BLOCK_DATA data.
The DT_BLOCK_PARAMS object is assigned the object type value of 508. This value is used only in the object type type table of the STF block (see 6.3.3.3 Object type table).
The layout of this object shall be as follows:
|
meaning : Element_Type |
|
value_unit : EDCS_Unit_Code |
|
value_scale : EDCS_Scale_Code |
|
value_type : Data_Table_Data_Value_Type |
|
component_data_table_ecc : EDCS_Classification_Code |
|
sub_extents : STF_Data_Table_Extents |
|
data_packed_flag : Boolean |
|
base_data_value : Single_Value |
|
maximum_value : Single_Value |
|
scale_factor : Byte_Unsigned |
|
packed_element_size : Byte_Unsigned |
|
sentinel_values : STF_Data_Table_Sentinel_Type[sentinel_count : Byte_Unsigned] |
|
tolerance : Long_Float |
http://www.iso.ch/iso/en/ittf/PubliclyAvailableStandards/ISO_IEC_18023-3_Ed1.html