Class Name: Image

Superclass - <SEDRIS Abstract Base>

Subclasses

Definition

An instance of this DRM class defines one or more MIP levels of texels, and can have 3 dimensions.

Primary Page in DRM Diagram:

• 22

Secondary Pages in DRM Diagram:

• 10

Example

1. A brick <Image> that is repeated over the surface of a <Polygon> to represent a brick wall.

2. An <Image> of a tree that when applied to a <Polygon> and combined with <Translucency> creates a flat version of a tree.

3. The <Image> mapped to the surface of a Dismounted Infantryman icon.

4. The sequence of <Image>(s) mapped to a <Polygon> to represent a television.

5. Consider an <Image> 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.

                            Image
            ------------------------------------
            |                 |                 |
          PT Ref           PT Ref             PT Ref
      (specifies Axis)  (specifies Axis)  (specifies Axis)
            |                 |                 |
       (Infrared table)    (NVG Table)       (SMC Table)
   
       1   xx                xx                 yy
       2   xx                xx                 yy
       3   xx                xx                 yy
       4   xx                xx                 wood
       5   xx                xx                 yy
       6   xx                xx                 concrete
       7   xx                xx                 glass
       8   xx                xx                 yy
   

   1. 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>.

   2. 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 we have something that's 50% glass and 50% concrete.

   3. 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 References> 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 we have something at that texel 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.

As a data provider, I can't figure out where I store the texels of an <Image> instance; I don't see a field for them. Where are they, and how can I 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.

As a data consumer, I can't figure out how to retrieve the texels of an <Image> instance; I don't see a field for them. Where are they, and how do I 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:

1. 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].

2. 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.

1. 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.

2. 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.

How is the <Classification Data> component used, if present?

The <Classification Data> identifies the content of the imagery.

A <Geometry>'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>, the <Geometry> classification overrides.

Constraints

Associated by (one-way)

• zero or more <Image Mapping Function> instances

Composed of (two-way)

• zero or one <Classification Data> instance
• zero or one <Image Anchor> instance
• zero or one <Presentation Domain> instance (notes)
• zero or more <Property Table Reference> instances
• zero or one <Spatial Domain> instance

Composed of (two-way metadata)

• zero or one <Access> instance
• zero or more <Browse Media> instances
• zero or one <Citation> instance
• zero or more <Cross Reference> instances
• zero or one <Description> instance
• zero or one <Keywords> instance
• zero or one <Point Of Contact> instance
• zero or more <Process> instances
• zero or more <Source> instances
• zero or one <Time Constraints Data> instance

Component of (two-way)

• one <Image Library> instance

Inherited Field Elements

Field Elements

Notes

Composed of Notes

Presentation_Domain

 This is intended to support geo-specific <Images> that
 are not referenced by any <Image Mapping Function>,
 because an <Image> may be significant only for a
 particular domain, e.g. radar, thermal, out-the-window.

Fields Notes

name

 This is a meaningful short name. The data provider may use
 the <Description> component to provide a more detailed
 description.

colour_model

 This specifies the colour model used throughout the given
 <Image> instance.  Only one colour model is allowed per
 <Image> instance.

level_count

 This specifies the number of Levels of Detail defined for the
 given <Image> instance (for mipmaps).

 If this is not a mipmapped image, only one level will 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>
 will be valid on a given consumer's system.

 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).

mip_extents_array

 There are level_count entries in the array.  Each entry defines
 the 'size' (the number of horizontal, vertical, and z texels)
 for a single MIP level of the <Image>.

 The first map shall contain the highest level of detail;
 that is, mip_extents_array[0] corresponds to the level
 containing the most texels.

image_signature

 This indicates how texels are represented within the <Image>.
 See SE_Image_Signature for details.

scan_direction

 This specifies the origin and direction of the horizontal and
 vertical components of the <Image>.

scan_direction_z

 This specifies the direction in which the <Image>'s z components
 are ordered.

component_data_type

 This specifies the data type of the raw image data.
 If signed or unsigned integer is specified, the max size fields
 apply. If floating point is specified, the values range from
 0.0 to 1.0.

data_is_little_endian

 This flag specifies the endianess of the raw image data.

data_is_3D

 This flag specifies whether the image data has 3 dimensions.

bits_of_alpha

 If 0 specified, the image data does not contain alpha information.

bits_of_luminance

 If 0 specified, the image data does not contain luminance information.

bits_of_colour_coordinate_1

 If 0 specified, the image data does not contain colour information
 for this colour coordinate (R, C, H).

bits_of_colour_coordinate_2

 If 0 specified, the image data does not contain colour information
 for this colour coordinate (G, M, S).

bits_of_colour_coordinate_3

 If 0 specified, the image data does not contain colour information
 for this colour coordinate (B, Y, V).

bits_of_bump_map_height

 If 0 specified, the image data does not contain bump_map_height
 information.

bits_of_material_1

 If 0 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 this image.

 NOTE: With no material_2 or material_3 percentages, material_1
       is at 100%.

bits_of_material_2

 If 0 specified, the image data does not contain material 2 index
 information. If non-0 is specified, then this is an index into the
 <Property Table> instance(s) that are referenced from this image.

bits_of_material_3

 If 0 specified, the image data does not contain material 3 index
 information. If non-0 is specified, then this is an index into the
 <Property Table> instance(s) that are referenced from this image.

bits_of_material_2_percentage

 percentage of material 2 (if used)

 NOTE: the percentage of material 1 is
 (100% - (percentage of material 2))

bits_of_material_3_percentage

 percentage of material 3 (if used)

 NOTE: the percentage of material 1 is
 (100% - (percentage of material 2) - percentage of material 3))

bits_of_image_index

 If 0 specified, the image data does not contain image index information

bits_of_bump_map_u

 If 0 specified, the image data does not contain bump_map_u
 information

bits_of_bump_map_v

 If 0 specified, the image data does not contain bump_map_v
 information

min_value_of_alpha

 minimum value that alpha can be within the image data;
 0 if not used.

max_value_of_alpha

 maximum value that alpha can be within the image data;
 0 if not used.

min_value_of_luminance

 minimum value that luminance can be within the image data;
 0 if not used.

max_value_of_luminance

 maximum value that luminance can be within the image data;
 0 if not used.

min_value_of_colour_coordinate_1

 minimum value that colour_coordinate_1 can be within the image data;
 0 if not used.

max_value_of_colour_coordinate_1

 maximum value that colour_coordinate_1 can be within the image data;
 0 if not used.

min_value_of_colour_coordinate_2

 minimum value that colour_coordinate_2 can be within the image data;
 0 if not used.

max_value_of_colour_coordinate_2

 maximum value that colour_coordinate_2 can be within the image data;
 0 if not used.

min_value_of_colour_coordinate_3

 minimum value that colour_coordinate_3 can be within the image data;
 0 if not used.

max_value_of_colour_coordinate_3

 maximum value that colour_coordinate_3 can be within the image data;
 0 if not used.

min_value_of_bump_map_height

 minimum value that bump_map_height can be within the image data;
 0 if not used.

max_value_of_bump_map_height

 maximum value that bump_map_height can be within the image data;
 0 if not used.

min_value_of_bump_map_u

 minimum value that bump_map_u can be within the image data;
 0 if not used.

max_value_of_bump_map_u

 maximum value that bump_map_u can be within the image data;
 0 if not used.

min_value_of_bump_map_v

 minimum value that bump_map_v can be within the image data;
 0 if not used.

max_value_of_bump_map_v

 maximum value that bump_map_v can be within the image data;
 0 if not used.