The SEDRIS Data Representation Model
APPENDIX A - Classes Image |
---|
An instance of this DRM class defines one or more MIP levels of texels, and can have 3 dimensions.
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> that has 3 <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
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.
See Part 4 Volume 8, Images and Colour Models Technical Guide, of the SEDRIS Documentation Set for detailed information on <Data Table> manipulation.
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 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.
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.
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.
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.
It is not currently deemed appropriate to directly support "lossy" imagery within the DRM.
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.
The <Classification Data> identifies the content of the imagery.
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.
This is intended to support geo-specific <Image> instances 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.
This is a meaningful short name. The data provider may use the <Description> component to provide a more detailed description.
This specifies the colour model used throughout the given <Image> instance. Only one colour model is allowed per <Image> instance.
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).
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 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.
This indicates how texels are represented within the given <Image> instance; see SE_Image_Signature for details.
This specifies the origin and direction of the horizontal and vertical components of the given <Image> instance.
This specifies the direction in which the given <Image> instance's z components are ordered.
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.
This flag specifies the endianess of the raw image data.
This flag 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 this image. NOTE: With no material_2 or material_3 percentages, material_1 is at 100%.
If this value is 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 this value is 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.
percentage of material 2 (if used) NOTE: the percentage of material 1 is (100% - (percentage of material 2))
percentage of material 3 (if used) 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.
This is the minimum value that alpha can be within the image data; it is 0.0 if alpha is not used.
This is the maximum value that alpha can be within the image data; it is 0.0 if alpha is not used.
This is the minimum value that luminance can be within the image data; it is 0.0 if luminance is not used.
This is the maximum value that luminance can be within the image data; it is 0.0 if luminance is not used.
minimum value that colour_coordinate_1 can be within the image data; 0 if not used.
This is the maximum value that colour_coordinate_1 can be within the image data; it is 0.0 if colour_coordinate_1 is not used.
This is the minimum value that colour_coordinate_2 can be within the image data; it is 0.0 if colour_coordinate_2 is not used.
This is the maximum value that colour_coordinate_2 can be within the image data; it is 0.0 if colour_coordinate_2 is not used.
This is the minimum value that colour_coordinate_3 can be within the image data; it is 0.0 if colour_coordinate_3 is not used.
maximum value that colour_coordinate_3 can be within the image data; 0 if not used.
minimum value that bump_map_height can be within the image data; 0 if not used.
maximum value that bump_map_height can be within the image data; 0 if not used.
minimum value that bump_map_u can be within the image data; 0 if not used.
maximum value that bump_map_u can be within the image data; 0 if not used.
minimum value that bump_map_v can be within the image data; 0 if not used.
maximum value that bump_map_v can be within the image data; 0 if not used.
|