Class Name: Image
Subclasses
This DRM class is concrete and has no subclasses.
Definition
An instance of this DRM class specifies one or more MIP levels of texels,
and can have three dimensions. Each texel consists of the set of
components identified by the image_signature
field.
Primary Page in DRM Diagram:
Secondary Pages in DRM Diagram:
Example
A brick <Image> instance that is repeated over
the surface of a <Polygon> instance to
represent a brick wall.
An <Image> instance of a tree that when applied to a
<Polygon> instance and combined with a
<Translucency> instance creates a flat version of a tree.
The sequence of <Image> instance(s) mapped to a
<Polygon> instance to represent a television.
Consider an <Image> instance that has three
<Property Table Reference> components:
- a reference to a <Property Table> instance for
infrared properties,
- a reference to a <Property Table> instance for
night vision goggles properties, and
- a reference to a <Property Table> instance for
surface material category properties (see Figure 6.23).
Figure 23 — <DRM Image> example
Consider the case of one material. A given texel contains a single
integer, which is used in place of the
index_on_axis
field for all the <Property Table Reference> components
of the <Image> instance.
Consider the case of two materials. A given texel contains
three integers, two of which are used in place of the
index_on_axis
field for all the <Property Table Reference> components
of the <Image> instance, and a third integer, which
specifies the percentage of the second material. For a given texel,
say the numbers are 7 6 50. The material at that texel is
something that is 50% glass and 50% concrete.
Consider the case of three materials. A given texel contains
five integers, three of which are used in place of the
index_on_axis
field for all the <Property Table Reference> components
of the <Image> instance, and two of which specify the
percentages of material two and three. For a given texel, say the
numbers are 4 6 7 20 30. The material at that texel is something
that is 50% wood, 20% concrete, and 30% glass.
FAQs
-
Where can users go for further information about
<Image> instances and texture mapping?
See Part 4 Volume 8,
Images and Colour Models Technical Guide, of the
SEDRIS Documentation Set for detailed information on
<Data Table> manipulation.
-
The <Image> class does not appear to have a
field for storing the texels of an <Image>
instance. Where are the texels, and how can a data provider get at
them?
The actual texels of an <Image> instance are
hidden by the API implementation being used to provide the
<Image> instance. See the
SE_PutImageData()
function in the level 0 API.
-
The <Image> class does not appear to have a
field for storing the texels of an <Image>
instance. Where are the texels, and how can a data consumer get at
them?
The actual texels of an <Image> instance are
hidden by the API implementation being used to provide the
<Image> instance, so they are accessed via the
SE_GetImageData()
(in level 0) and
SE_GetRearrangedImageData()
(in level 1) API functions.
-
How are the bits_of_xxx, min_value_of_xxx, and max_value_of_xxx fields
used?
See the comments for the individual image signatures in
SE_Image_Signature for
details on which values are present for which signature.
The mininum / maximum fields are used to specify the minimum and
maximum values that a component may have on the producer's system,
and do not relate to whatever values may actually be
present in the transmittal.
EXAMPLES:
If the image components are floating point 32 bits, a minimum
value of -1.0 and a maximum value of
1.0 means that all values in
an image on the producer's system shall be represented within the
range [-1.0, 1.0].
An image with unsigned integer components of 8 bits may specify its
range to be [0, 99], indicating that even though the maximum value
that can be specified with 8 bits is 255, the value 99 should be
treated as the maximum value for this image.
-
What is the maximum size of an image that the DRM can represent?
There is no known size limitation for images in a transmittal.
(Well, 1.8 x 10^19 texels by the depth of the texel.)
However, there may be size limitations in either the media that is used
in the transmission or in computer hardware that interprets the
transmittal. To alleviate some of the problems associated with large
images, the DRM has "hidden" the actual image data behind
a function
call that allows for the consumer to specify the size of the data that
is to be handed off to the consumer. This function call is documented
in P4V17 of the SEDRIS Documentation Set.
-
A data provider has an image that does not correspond to any registered
SE_Image_Signature in the DRM.
What can be done with it?
There are two possibilities.
Decompose this image into component images which do
correspond to various registered image signatures, if possible. In
addition to complex image signatures, individual image components
are also supported as an SE_Image_Signature.
After the decomposition, add
an <Identification> component to the resulting
<Image> instances to convey to
consumers how the component images are to be reassembled
into the complete image.
If one of the components of the image does not correspond to
any registered SE_Image_Signature,
submit a SEDRIS Change Request requesting that the desired
signature be registered as an addition to
SE_Image_Signature.
-
Why doesn't the DRM support JPEG (and other compressed formats)?
It is not currently deemed appropriate to directly support
"lossy" imagery within the DRM.
-
What kind of image data ordering does the DRM support?
Currently the DRM only supports texel (pixel) data ordering. Scan line
(All the red values on the first scan line, then all the green
values ...) and image plane ordering (all the values of red within
the image, then all the values of green...) are not supported.
-
The <Classification Data> component of a
<Geometry Representation> instance G
classifies G as a wall, but an <Image>
instance referenced by the <Image Mapping Function> component
of G has a <Classification Data> component
specifying railway track. Which is it?
The <Image> instance was created for use as a railway track,
but when it is creatively reused by a <Geometry Representation>
instance that is not classified as a railway track, the classification
of the <Geometry Representation> instance overrides.
Constraints
Associated by (one-way)
Composed of (two-way)
Composed of (two-way metadata)
Component of (two-way)
Inherited Field Elements
This class has no inherited field elements.
Notes
Composed of Notes
If provided, the <Classification Data>
component identifies the content of the imagery.
If provided, the <Identification>
component may be used to provide a more detailed description
than that specified by the name field.
If provided, the <Lineage> component specifies either
information about the events and/or source data used in
constructing the <Image> instance or
lack of knowledge about lineage.
The <Presentation Domain> component
is intended to support geospecific
<Image> instances that
are not referenced by any
<Image Mapping Function>
instance since an <Image> instance may
be significant only for a particular domain, such as radar,
thermal, or OTW.
Fields Notes
The name field specifies a
meaningful short name.
The colour_model field
specifies the colour model used throughout the
<Image> instance.
Only one colour model is allowed per
<Image> instance.
The level_count field
specifies the number of levels of detail defined for the
<Image> instance (for mipmaps). If the
given instance is not a MIP-mapped image, only one level is
specified (level_count = 1).
NOTE 1
Many end-user applications require that
<Image> instances
having MIP levels specify both the horizontal and vertical
dimensions as a power of two. However, some applications can
handle <Image> instances for which the
horizontal and vertical
dimensions are a multiple of two rather than a power of two.
For example, 96 texels in a direction is a multiple of two but not
a power of two. The DRM places no restriction on
either the dimensional size of
an <Image> instance, nor makes
any statement as to whether the use of MIP information within
the <Image> instance will be valid on a
given consuming application.
There are level_count
entries in the
mip_extents_array.
Each entry defines the number of horizontal, vertical, and z texels
for a single MIP level of the
<Image> instance.
The first map shall contain the highest level of detail;
that is, mip_extents_array[0]
corresponds to the level containing the most texels.
The image_signature field
specifies how texels are represented within the
<Image> instance (see
SE_Image_Signature for details).
NOTE 2
For an <Image> instance with
an image_signature of
SE_IMAGSIG_EDCS_CLASSIFICATION_CODE,
the bit size is a constant that represents the number of bits
needed to represent an ECC.
The scan_direction field
specifies the origin and direction of the horizontal and
vertical components of the <Image> instance.
The scan_direction_z field
specifies the direction in which the z components of the
<Image> instance are ordered.
The component_data_type field
specifies the data type of each component of the raw texel data.
If signed or unsigned integer is specified, the "minimum_value"
and "maximum_value" fields apply. If floating point is
specified, the component values are in the range
[0.0, 1.0], and the applicable
"minimum_value" and "maximum_value" fields
shall be set to the applicable value of either 0.0
or 1.0. In addition, if floating point is specified,
the applicable "bits_of" fields shall be set to either
32 or 64.
The data_is_little_endian
field specifies the endianess of the raw image data.
The data_is_3D field specifies
whether the image data has three dimensions.
The bits_of_alpha field specifies
how many bits of a texel within the image data specify
alpha information. It is zero if alpha is not used.
The bits_of_luminance field specifies
how many bits of a texel within the image data specify
luminance information. It is zero if luminance is not used.
The
bits_of_colour_coordinate_1
field specifies how many bits of a texel within the image data
specify colour coordinate 1 information.
It is zero if colour coordinate 1 is not used.
The
bits_of_colour_coordinate_2
field specifies how many bits of a texel within the image data
specify colour coordinate 2 information.
It is zero if colour coordinate 2 is not used.
The
bits_of_colour_coordinate_3
field specifies how many bits of a texel within the image data
specify colour coordinate 3 information.
It is zero if colour coordinate 3 is not used.
The
bits_of_bump_map_height
field specifies how many bits of a texel within the image data
specify bump map height information.
It is zero if bump map height is not used.
If the value of the
bits_of_material_1 field is
non-zero, the <Image> instance has at least one
<Property Table Reference> component, and the bits in
the image data corresponding to material 1 specify indexes
into the <Property Table> instance(s)
that are referenced by the <Property Table Reference>
component(s) of the <Image> instance.
If the value of the
bits_of_material_1 field is
zero, the image data does not contain material 1 index information.
NOTE 3
With no material 2 or material 3 percentages, material 1
is at 100%.
If the value of the bits_of_material_2
field is non-zero, the <Image> instance has
at least one <Property Table Reference> component,
and the bits in the image data corresponding to material 2
specify indexes into the <Property Table> instance(s)
referenced by the <Property Table Reference> component(s)
of the <Image> instance.
However, if bits_of_material_2
= 0, the texel data of the <Image> instance does not
contain material 2 index information.
If the bits_of_material_3
field specifies non-zero, the <Image> instance has
at least one <Property Table Reference> component,
and the bits in the image data corresponding to material 3
specify indexes into the <Property Table> instance(s)
referenced by the <Property Table Reference> component(s)
of the <Image> instance.
However, if bits_of_material_3
= 0, the texel data of the <Image> instance does not
contain material 3 index information.
If required by the image_signature
value of the <Image> instance, the
bits_of_material_2_percentage
field is used to specify the percentage of material 2.
NOTE 4
If data is provided for only two materials, the percentage of
material 1 is (100% - (percentage of material 2))
If required by the image_signature
value of the <Image> instance, the
bits_of_material_3_percentage
field is used to specify the percentage of material 3.
NOTE 5
If data for all three materials is provided, the percentage of
material 1 is
(100% - (percentage of material 2) - percentage of material 3))
The
bits_of_image_index
field specifies how many bits of a texel within the image data
specify image index information. It is zero if image index is not used.
The
bits_of_bump_map_u
field specifies how many bits of a texel within the image data
specify bump map u information. It is zero if bump map u is not used.
The
bits_of_bump_map_v
field specifies how many bits of a texel within the image data
specify bump map v information. It is zero if bump map v is not used.
The min_value_of_alpha
field specifies the minimum value that alpha can be within the
image data. It is zero if alpha is not used.
The max_value_of_alpha
field specifies the maximum value that alpha can be within the
image data. It is zero if alpha is not used.
The min_value_of_luminance
field specifies the minimum value that luminance can be within the
image data. It is zero if luminance is not used.
The max_value_of_luminance
field specifies the maximum value that luminance can be within the
image data. It is zero if luminance is not used.
The min_value_of_colour_coordinate_1
field specifies the minimum value that colour coordinate 1
can be within the image data. It is zero if
colour coordinate 1 is not used.
The max_value_of_colour_coordinate_1
field specifies the maximum value that colour coordinate 1
can be within the image data. It is zero if
colour coordinate 1 is not used.
The min_value_of_colour_coordinate_2
field specifies the minimum value that colour coordinate 2
can be within the image data. It is zero if
colour coordinate 2 is not used.
The max_value_of_colour_coordinate_2
field specifies the maximum value that colour coordinate 2
can be within the image data. It is zero if
colour coordinate 2 is not used.
The min_value_of_colour_coordinate_3
field specifies the minimum value that colour coordinate 3
can be within the image data. It is zero if
colour coordinate 3 is not used.
The max_value_of_colour_coordinate_3
field specifies the maximum value that colour coordinate 3
can be within the image data. It is zero if
colour coordinate 3 is not used.
The min_value_of_bump_map_height
field specifies the minimum value that bump map height
can be within the image data. It is zero if
bump map height is not used.
The max_value_of_bump_map_height
field specifies the maximum value that bump map height
can be within the image data. It is zero if
bump map height is not used.
The min_value_of_bump_map_u
field specifies the minimum value that bump map u
can be within the image data. It is zero if
bump map u is not used.
The max_value_of_bump_map_u
field specifies the maximum value that bump map u
can be within the image data. It is zero if
bump map u is not used.
The min_value_of_bump_map_v
field specifies the minimum value that bump map v
can be within the image data. It is zero if
bump map v is not used.
The max_value_of_bump_map_v
field specifies the maximum value that bump map v
can be within the image data. It is zero if
bump map v is not used.
Prev: Identification.
Next: Image Anchor.
Up:Index.