The SEDRIS Data Representation Model
APPENDIX A - Classes
Image
|
|---|
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 3 dimensions.
Primary Page in DRM Diagram:
Secondary Pages in DRM Diagram:
Example
A brick <Image> that is repeated over the surface
of a <Polygon> to represent a brick wall.
An <Image> of a tree that when applied to a
<Polygon> and combined with
<Translucency> creates a flat version of a tree.
The <Image> mapped to the surface of a
Dismounted Infantryman icon.
The sequence of <Image>(s) mapped to a
<Polygon> to represent a television.
Consider an <Image> instance that has 3
<Property Table Reference>
components:
- one to a table for Infrared properties,
- one to a table for Night Vision Goggles properties,
- and the third to a <Property Table> for
Surface Material Category properties.
NOTE: There is no restriction on the number of possible
<Property Table Reference> components.
Consider the case of 1 material. A given texel will contain
a single integer, which is used in place of the
index_on_axis
field for all the
<Property Table Reference>
components of the <Image>.
Consider the case of 2 materials. A given texel will contain
3 integers, 2 of which are used in place of the
index_on_axis
field for all the
<Property Table Reference>s of the <Image>,
and a third integer, which specifies the percentage of the
2nd material. For a given texel, say the numbers are
7 6 50 ; then the material at that texel is something that's 50% glass
and 50% concrete.
Consider the case of 3 materials. A given texel will contain
5 integers, 3 of which are used in place of the
index_on_axis
field for all the
<Property Table Reference> components of the <Image>,
and 2 of which specify the percentages of material 2 and 3.
For a given texel, say the numbers are 4 6 7 20 30;
then 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
<Images> 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>. See the
SE_PutImageData()
function in the level 0 write 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>, so they are accessed via the
SE_GetImageData()
(in level 0) and
SE_GetRearrangedImageData() (in level 1) API functions.
- How do I use the bits_of_xxx, min_value_of_xxx, and
max_value_of_xxx fields?
See the comments for the individual image signatures in
SE_Image_Signature for
details on which values are present for which signature.
The min / max fields are used to specify the minimum and
maximum values a component may have on the producer's system, and
do not relate to whatever values may actually be
present in the transmitted through SEDRIS.
EXAMPLES:
If the image components are floating point 32 bits, then 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 SEDRIS can
transmit?
There is no known size limitation for images in a SEDRIS 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, SEDRIS 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.
- As a data provider, I have an image that I wish to transmit which
does not correspond to any registered
SE_Image_Signature in SEDRIS. What can I do?
There are two possibilities.
Decompose your 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 a
<Description> component to the resulting
<Images> to convey to
your consumers how the component images are to be reassembled
into the complete image.
If one of the components of your image does not correspond to
any registered
SE_Image_Signature and / or if you have the time,
submit a SEDRIS Change Request requesting that the desired
signature be registered as a new addition to
SE_Image_Signature.
- Why doesn't SEDRIS 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 SEDRIS support?
Currently SEDRIS 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.
- A <Geometry Representation>'s
<Classification Data> component
identifies it as a wall, but its <Image> via
<Image Mapping Function> has
<Classification Data>
for railroad track. Which is it?
The <Image> was created for use as a
railroad track, but when it is creatively reused by a
non-railroad <Geometry Representation>,
the <Geometry Representation>
classification 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> identifies the content of
the imagery.
If provided, the <Description> component may be used to provide
a more detailed description than that specified by the name field.
If provided, this specifies either
- information about the events and/or source data
used in constructing the given <Image> instance, or
- lack of knowledge about lineage.
This is intended to support geo-specific <Image> instances
that are not referenced by any <Image Mapping Function>
instance, because an <Image> instance may be significant only
for a particular domain, such as radar, thermal, out-the-window.
Fields Notes
The name field specifies a meaningful short name.
The colour_model field specifies the colour model used
throughout the given <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 given <Image> instance (for mipmaps). If the
given instance is not a mipmapped image, only one level will
be defined (level_count == 1).
Many end-user applications require that <Image> instances
having MIP levels specify both the horizontal and vertical
dimensions as a power of 2. However, some applications can
handle <Image> instances for which the horizontal and vertical
dimensions are a multiple of 2 rather than a power of 2.
For example, 96 texels in a direction is a multiple of 2 but not
a power of 2. Please note that SEDRIS places no restriction on
either the dimensional size of an <Image> instance, nor makes
any statement as to whether the use of MIPS information within
the <Image> instance will be valid on a given consumer's system.
There are level_count entries in the mip_extents_array, each
entry of which defines the "size" (the number of horizontal,
vertical, and z texels) for a single MIP level of the given
<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 given <Image> instance; see SE_Image_Signature for details.
Note that for an <Image> instance with an image_signature of
SE_IMG_SIG_EDCS_CLASSIFICATION_CODE, the bit size is a constant
of sizeof(EDCS_Classification_Code).
The scan_direction field specifies the origin and direction of
the horizontal and vertical components of the given <Image>
instance.
The scan_direction_z specifies the direction in which the given
<Image> instance's z components are ordered.
The component_data_type field specifies the data type of the raw
image data. If signed or unsigned integer is specified, the maximum
size fields apply. If floating point is specified, the values range
from 0.0 to 1.0.
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
3 dimensions.
If 0 is specified, the image data does not contain alpha information.
If 0 is specified, the image data does not contain luminance information.
If 0 is specified, the image data does not contain colour information
for this colour coordinate (R, C, H).
If 0 is specified, the image data does not contain colour information
for this colour coordinate (G, M, S).
If 0 is specified, the image data does not contain colour information
for this colour coordinate (B, Y, V).
If 0 is specified, the image data does not contain bump_map_height
information.
If 0 is specified, the image data does not contain material 1 index
information. If non-0 is specified, then this is an index into the
<Property Table> instance(s) that are referenced from the given
<Image> instance.
NOTE: With no material_2 or material_3 percentages, material_1
is at 100%.
If the bits_of_material_2 field specifies non-zero for a given
<Image> instance X, then
- X has at least one <Property Table Reference> component, and
- the bits in the image data of X corresponding to material 2
specify indices into the <Property Table> instance(s) referenced
by X's <Property Table Reference> component(s).
However, if bits_of_material_2 = 0, the given <Image> instance's
texel data do not contain material 2 index information.
If the bits_of_material_3 field specifies non-zero for a given
<Image> instance X, then
- X has at least one <Property Table Reference> component, and
- the bits in the image data of X corresponding to material 3
specify indices into the <Property Table> instance(s) referenced
by X's <Property Table Reference> component(s).
However, if bits_of_material_3 = 0, the given <Image> instance's
texel data do not contain material 3 index information.
If required by the given <Image> instance's image_signature,
the bits_of_material_2_percentage field is used to specify
the percentage of material 2.
NOTE: the percentage of material 1 is
(100% - (percentage of material 2))
If required by the given <Image> instance's image_signature,
the bits_of_material_3_percentage field is used to specify
the percentage of material 3.
NOTE: the percentage of material 1 is
(100% - (percentage of material 2) - percentage of material 3))
If 0 is specified, the image data does not contain image index
information.
If 0 is specified, the image data does not contain bump_map_u
information.
If 0 is specified, the image data does not contain bump_map_v
information.
The min_value_of_alpha field specifies the minimum value that
alpha can be within the image data; it is 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 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 0.0 if bump_map_v is not used.
Prev: Icon.
Next: Image Anchor.
Up:Index.
|
Last updated: July 16, 2004
|
Copyright © 2004 SEDRIS™
|
|