|
3.2.1 |
The Usual Suspects: Fields |
|
The most frequently asked question that new users ask when they first
begin studying the <Image>
class (and which is captured as a FAQ
within the class' documentation) is (paraphrased):
- Question:
- I don't see a field in the
<Image> class for the texels; where are they?
- Answer:
- The actual texels of an
<Image> instance are hidden by the
API implementation being used to provide the
<Image>. To
create the texels of an <Image>,
a data provider shall use the Transmittal Access Level 0 API function
SE_PutImageData(). To retrieve the texels of an
<Image>, a consumer
shall use the Transmittal Access Level 0 API function
SE_GetImageData().
These two functions accept and retrieve the texels of an
<Image>
instance as an array of bytes, using the fields of the
<Image>
to determine how many texels are present and the structure of each.
The level_count and
mip_extents_array fields,
together with data_is_3D,
indicate how many texels are present in the
<Image>. The
data_is_3D field
indicates whether a 3D or 2D image is being represented,
while the
mip_extents_array (which has
level_count entries)
specifies the horizontal, vertical, and z dimensions of each MIP level in the
<Image>. Mipmapping
is discussed in detail below; for a non-mipmapped image,
level_count is 1 and
the single entry in
mip_extents_array gives the dimensions of the
<Image>. Note that for a
2D <Image>, the z field of each
mip_extents_array
entry is set to 1.
The remaining fields of <Image>
can be grouped into those which are
needed to specify the structure of an individual texel, and those which
are needed to interpret the image data when it is retrieved. The
image_signature,
bits_of_xxx, and min / max_value_of_xxx fields fall
into the first category, while the remaining fields fall into the
second category.
|
3.2.2 |
Image Signatures |
|
3.2.2.1 |
Overview |
|
The image_signature
of an <Image>
instance specifies the structure of an individual texel,
including which of the bits_of_xxx, min_value_of_xxx, and max_value_of_xxx
fields are applicable. Essentially, the
image_signature
indicates how many components are in an individual texel,
what they mean, and which bits_of_xxx / min_value_of_xxx /
max_value_of_xxx fields are therefore applicable; the bits_of_xxx and
min / max fields themselves specify the size and ranges of the
individual components of a texel. The individual image signatures
are discussed in detail in the rest of this section.
|
3.2.2.2 |
LUMINANCE |
|
If image_signature
is set to
SE_IMAGSIG_LUMINANCE,
then each texel in the
<Image> consists of a
luminance value, representing the luminance
(also called intensity) of the texel. A luminance of 0 indicates that the
texel is black, while a luminance of 1 indicates that the texel is white;
all intermediate values are shades of grey. An
<Image> with this
signature may be called a luminance
<Image>, intensity <Image>,
or a greyscale <Image>. The
effect is that of a "black and white" television.
A LUMINANCE <Image> can be
composited with a compatible ALPHA image to produce a
SE_IMAGSIG_LUMINANCE_AND_ALPHA
<Image>.
An example of compositing
SE_IMAGSIG_LUMINANCE
<Images> is the case of large areas
of terrain <Polygons>,
where the same textures for dirt are repeated over
and over. To avoid creating a "quilt" effect on the terrain, a
luminance <Image> can
be composited with the terrain (using different
offsets at different locations to make the effect appear random) to
"dirty" the textures and give the terrain a more realistic
appearance.
FURTHER CONSTRAINTS:
- bits_of_luminance
shall equal the size per texel (in bits); all other
bits_of_xxx fields (and their corresponding min_value_of_xxx,
max_value_of_xxx fields) shall be zero.
|
3.2.2.3 |
COLOUR_COORDINATE_1 |
|
Used to indicate that each texel in the
<Image> consists of 1 colour
component, namely the first for its colour model (G for RGB, M for CMY, or
S for HSV). The first colour component of the colour model shall be the only
value in the texel.
Note that a
COLOUR_COORDINATE_1
<Image>
can be composited with compatible
COLOUR_COORDINATE_2
and
COLOUR_COORDINATE_3
<Images>
of the same dimensions to produce a
123COLOUR
<Image>. (These can also be
composited with a compatible alpha map to produce a
123COLOUR_ALPHA
map.)
FURTHER CONSTRAINTS:
-
bits_of_colour_coordinate_1 shall equal the size per texel (in bits);
all other bits_of_xxx fields (and their corresponding min_value_of_xxx,
max_value_of_xxx) shall be zero.
- When an object has K
<Image Mapping Functions> providing texture
mapping information, at most one of the K
<Image Mapping Functions> can be associated with a
COLOUR_COORDINATE_1
<Image>. (Multiple
COLOUR_COORDINATE_1
<Images> produce
an undefined result.)
EXAMPLES:
- An RGB texel shall have red as the texel value.
- An CMY texel shall have cyan as the texel value.
- An HSV texel shall have hue as the texel value.
|
3.2.2.4 |
COLOUR_COORDINATE_2 |
|
See
SE_IMAGSIG_COLOUR_COORDINATE_2's
documentation.
|
3.2.2.5 |
COLOUR_COORDINATE_3
|
|
See
SE_IMAGSIG_COLOUR_COORDINATE_3's
documentation.
|
3.2.2.6 |
ALPHA |
|
If image_signature
is set to
SE_IMAGSIG_ALPHA,
then each texel in the
<Image> consists of an
alpha value, representing the coverage of
the texel. An alpha of 0 indicates that the texel is transparent, while
an alpha of 1 indicates that the texel constitutes part of the important
content of the <Image>. An
<Image> with this signature may be
called an alpha channel or an alpha map. For further
details, see [FOLEY_VAN_DAM]
Section 17.6, "Image Compositing".
Note that an alpha map can be composited with:
FURTHER CONSTRAINTS:
- bits_of_alpha
shall equal the size per texel (in bits); all
other bits_of_xxx fields (and their corresponding min_value_of_xxx,
max_value_of_xxx) fields shall be zero.
- When an object has K
<Image Mapping Functions> providing its texture
mapping information, at most one of the K
<Image Mapping Functions>
can legally provide an alpha map. (Multiple alpha maps produce an
undefined result.)
|
| |
3.2.2.7 |
BUMP_MAP_HEIGHT |
|
Used to indicate that the <Image>
represents a 2-D height bump map (or just height map), specifying
information used to modify the surface normals of a smooth surface.
When used with a ray-tracing technique, bump mapping introduces
variations in intensity across the surface, so that it simulates a
rough, wrinkled, or dimpled surface (e.g., the surface of the ocean).
A UV type of bump map can be derived from a height bump map by
computing the texel gradients in both the X and Y directions.
Rather than manipulating the colour of a flat surface, bump mapping
modifies the physical texture of the surface. For a description
of bump mapping, see [WATT].
FURTHER CONSTRAINTS:
-
bits_of_bump_map_height shall equal the size per texel (in bits);
all other bits_of_xxx fields (and their corresponding
min_value_of_xxx, max_value_of_xxx) fields shall be zero.
- When an object has K
<Image Mapping Functions> providing its
texture mapping information, at most one of the K
<Image Mapping Functions> can legally provide a bump map.
(Multiple bump maps produce an undefined result.)
|
3.2.2.8 |
EDCS_CLASSIFICATION_CODE |
|
Used to indicate that each texel in the
<Image> consists of 1 value,
an
EDCS Classification Code (ECC).
CONSTRAINTS:
- The size per texel shall be the size of
EDCS_Classification_Code.
- Since no bits_of, min_value, or max_value fields are needed for this
signature, all bits_of_xxx fields (and their corresponding
min_value_of_xxx, max_value_of_xxx fields) shall be zero.
|
3.2.2.9 |
LUMINANCE_AND_ALPHA |
|
Used to indicate that the <Image>
is (functionally) a composite of a luminance
<Image> and an alpha
<Image> (see
SE_IMAGSIG_ALPHA,
SE_IMAGSIG_LUMINANCE).
Each texel consists of an intensity value followed
by an alpha value. No other ordering is possible with this signature.
A LUMINANCE_AND_ALPHA
<Image>
can be down-sampled to produce
an ALPHA
<Image> and a
LUMINANCE
<Image>.
FURTHER CONSTRAINTS:
- bits_of_luminance
+ bits_of_alpha
shall equal the size per texel (in bits); all other bits_of_xxx
fields shall be zero.
- When an object has K
<Image Mapping Function>
instances providing its texture mapping information, at most one of of the K
<Image Mapping Functions>
instances can legally provide a luminance & alpha map.
(Multiple alpha maps produce
an undefined result.)
|
3.2.2.10 |
123COLOUR |
|
Used to indicate that each texel in the
<Image> consists of 3 colour
components (RGB, CMY, or HSV). The first colour component of the
colour model shall be the first value in the texel, the second colour
component of the colour model shall be the second value in the texel,
and the third colour component of the colour model shall be the third
value in the texel. No other ordering is possible with this
signature.
Note that a
123COLOUR
<Image>
can be down-sampled to produce a
COLOUR_COORDINATE_1,
COLOUR_COORDINATE_2,
or
COLOUR_COORDINATE_3
<Image>.
FURTHER CONSTRAINTS:
-
bits_of_colour_coordinate_1 +
bits_of_colour_coordinate_2 +
bits_of_colour_coordinate_3
shall equal the size per texel (in bits); all other bits_of_xxx fields
(and their corresponding min_value_of_xxx, max_value_of_xxx) shall
be zero.
- When an object has K
<Image Mapping Functions> providing texture
mapping information, at most one of the K
<Image Mapping Functions> can be associated
with a 123 colour map
<Image>. (Multiple 123 colour maps produce an undefined
result.)
EXAMPLES:
- An RGB texel shall have red as the first value in the texel, green
next and finally blue.
- A CMY texel shall have cyan as the first value in the texel, magenta
next, and finally yellow.
- An HSV texel shall have hue as the first value in the texel, saturation
next and finally brightness value.
|
3.2.2.11 |
123COLOUR_ALPHA |
|
Used to indicate that each texel in the
<Image> consists of 3 colour
components (RGB, CMY, or HSV) and an alpha value. The first colour
component of the colour model shall be the first value in the texel,
the second colour component of the colour model shall be the second
value in the texel, the third colour component of the colour model
shall be the third value in the texel, and the alpha value shall be
the last value in the texel. No other ordering is possible with
this signature.
Note that a
123COLOUR_ALPHA
<Image>
can be down-sampled to produce a
COLOUR_COORDINATE_1,
COLOUR_COORDINATE_2,
COLOUR_COORDINATE_3,
and / or
ALPHA
<Image>.
FURTHER CONSTRAINTS:
-
bits_of_colour_coordinate_1 +
bits_of_colour_coordinate_2 +
bits_of_colour_coordiante_3 +
bits_of_alpha shall equal the size per texel (in bits); all other
bits_of_xxx fields (and their corresponding min_value_of_xxx,
max_value_of_xxx) shall be zero.
- When an object has K
<Image Mapping Functions> providing texture
mapping information, at most one of the K
<Image Mapping Functions> can
be associated with a 123 colour & alpha map
<Image> (Multiple 123
colour and alpha maps produce an undefined result.)
EXAMPLES:
- An RGBA texel shall have red as the first value in the texel, green
next, then blue, and finally alpha.
- A CMYA texel shall have cyan as the first value in the texel, magenta
next, then yellow, and finally alpha.
- An HSVA texel shall have hue as the first value in the texel,
saturation next, then brightness value, and finally alpha.
|
3.2.2.12 |
ONE_MATERIAL |
|
Used to indicate that each texel in the
<Image> consists of 1 value,
an index into the
<Property Tables> referenced by this
<Image>.
These <Property Tables>
describe the material. Normally, a
<Property Table Reference> is used to find the corresponding
<Property Table>,
find which <Axis> is referred to, and
which hash value measurement along that
<Axis> is being referenced.
The bits_of_material_1
field is used in place of the
<Property Table Reference>'
index_on_axis
fields.
See the examples for the <Image>
class.
CONSTRAINTS:
- The <Image> shall have at
least one
<Property Table Reference>.
(The data producer may have as many
<Property Table References>
as desired, as long as there is at least one, and bits_of_material_#
will handle them.)
- All the
<Property Tables> being referred to by the
<Property Table Reference> shall be of the same size, since the
material reference corresponds to all of them.
- bits_of_material_1
shall equal the size per texel (in bits); all
other bits_of_xxx fields (and their corresponding min_value_of_xxx,
max_value_of_xxx) shall be zero.
|
3.2.2.13 |
TWO_MATERIALS |
|
Used to indicate that each texel in the
<Image> represents a linear
combination of 2 materials in the
<Property Tables> referenced
by this <Image>. That is, each
texel consists of 3 values: 2 indexes into the
<Property Tables>
referenced by this <Image>,
and the percentage (an integer, 0 - 100%) of material 2.
These <Property Tables>
describe the materials. Normally, a
<Property Table Reference> is used to find the corresponding
<Property Table>, find
which <Axis> is referred to, and
which hash value measurement along that
<Axis> is being referenced.
The bits_of_material1 and bits_of_material2 fields are used in
place of the
<Property Table References>'
index_on_axis fields.
See the examples for the <Image>
class.
CONSTRAINTS:
- The <Image> shall have at
least one
<Property Table Reference>.
(The data producer may have as many
<Property Table References>
as desired, as long as there is at least one, and bits_of_material_#
will handle them.)
- All the
<Property Tables> being referred to by the
<Property Table References> shall be of the same
size, since the material reference corresponds to all of them.
- bits_of_material_1
+
bits_of_material_2 +
bits_of_material_2_percentage
shall equal the size per texel (in bits); all other bits_of_xxx
fields (and their corresponding min_value_of_xxx, max_value_of_xxx)
shall be zero.
|
3.2.2.14 |
THREE_MATERIALS |
|
Used to indicate that each texel in the
<Image> represents a linear
combination of 3 materials in the
<Property Tables> referenced
by this <Image>. That is,
each texel consists of 4 values: 3 indexes into the
<Property Tables>
referenced by this <Image>,
and the percentages (integers, 0 - 100%) of materials 2 and 3
These <Property Tables>
describe the materials. Normally, a
<Property Table Reference> is used to find the corresponding
<Property Table>,
find which <Axis> is referred to, and
which hash value measurement along that
<Axis> is being referenced.
The bits_of_material_1,
bits_of_material_2,
and bits_of_material_3
fields are used in place of the
<Property Table References>'
index_on_axis fields.
See the examples for the <Image>
class.
CONSTRAINTS:
- The <Image> shall have at
least one
<Property Table Reference>.
(The data producer may have as many
<Property Table References>
as desired, as long as there is at least one, and bits_of_material_#
will handle them.)
- All the <Property Tables> being referred to by the <Property Table
References> shall be of the same size, since the material reference
corresponds to all of them.
- bits_of_material_1
+
bits_of_material_2 +
bits_of_material_2_percentage +
bits_of_material_3 +
bits_of_material_3_percentage shall equal the
size per texel (in bits); all other bits_of_xxx fields (and their
corresponding min_value_of_xxx, max_value_of_xxx) shall be zero.
|
3.2.2.15 |
IMAGE_INDEX |
|
Used to indicate that the <Image>
consists of references to other
<Images> (i.e., each texel
within the <Image> is the index
of another <Image>). This
mechanism allows an <Image> to
define high-resolution
insets.
Each texel is to be replaced by the entire
<Image>
identified by the <Image>
whose index is specified by that texel.
This allows data providers to create a gigantic
<Image> formed by
many smaller <Image>.
The index is an index into the
<Image Library> containing this
<Image>.
FURTHER CONSTRAINTS:
-
bits_of_image_index shall equal the size per texel (a positive value),
while all other bits_of_xxx fields (and their corresponding
min_value_of_xxx, max_value_of_xxx fields) shall be zero.
- Each texel within the
<Image> shall resolve to a valid index within
the <Image Library>
containing this image, but neither directly nor via other
SE_IMAGSIG_IMAGE_INDEX
<Image> instances
to the index of this <Image>.
(This would cause infinite recursion when trying to resolve
the image to its component parts).
- All referenced <Image>
instances shall have the same values as the main
<Image>
for colour_model,
data_is_little_endian,
data_is_3D,
component_data_type,
scan_direction,
and
scan_direction_z.
- All referenced <Images>
shall have either the same image signature X, or
SE_IMAGSIG_IMAGE_INDEX
which resolves to referenced images
with signature X, so that the main
<Image> can be resolved to a single image signature.
|
3.2.2.16 |
BUMP_MAP_UV |
|
Used to indicate that the <Image>
represents a bump map in UV space, specifying information used to
modify the surface normals of a smooth surface. See
SE_IMAGSIG_BUMP_MAP_HEIGHT
for further information on bump maps.
FURTHER CONSTRAINTS:
-
bits_of_bump_map_u +
bits_of_bump_map_v shall equal the size per
texel (in bits); all other bits_of_xxx fields (and their
corresponding min_value_of_xxx, max_value_of_xxx) fields shall be
zero.
- When an object has K
<Image Mapping Functions> providing its
texture mapping information, at most one of the K
<Image Mapping Functions> can legally provide a bump map.
(Multiple bump maps produce an undefined result.)
|
|
|
|
An <Image> instance
may itself directly represent environmental data, as in the case
of raw satellite imagery, for example. In such cases, a
<Image> instance
may itself require a mapping to a spatial reference frame,
independent of any
<Image Mapping Function> instances.
An <Image Anchor>
instance, when used as a component of an
<Image> instance,
indicates that the <Image>
in question is specific to the given region in the environment.
(When the region represents part of the surface of Earth, the
image is sometimes said to be geo-specific.) That is, the
<Image Anchor>
defines a spatial reference frame, three
<Location> instances in
that spatial reference frame, and a mapping between those
<Location> instances and
the <Image>, so that the
<Image> is "anchored"
to that specific region in space.
When an <Image Anchor>
is interpreted as a component of an
<Image>,
the <Location> components
of the <Image Anchor>
are interpreted as follows.
The first <Location>
component specifies the location to which the lower left corner of
the <Image> is mapped.
The second <Location>
component specifies the location to which the upper left corner of
the <Image> is mapped.
The third <Location>
component specifies the location to which the upper right corner of
the <Image> is mapped.
The three <Location>
components of an
<Image Anchor> instance
are interpreted as the locations of corners of the given
<Image> instance,
NOT those of the centre of the texels in the corners
of the <Image>.
|