Release 8.1.5
A67293-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Visual Information Retrieval User's Guide and Reference Release 8.1.5 A67293-01 |
|
This appendix describes the Oracle raw pixel image format and is intended for developers and advanced users who wish to use the raw pixel format as a gateway to import unsupported image formats into Visual Information Retrieval, or who wish to use the raw pixel format as a means to directly access the pixel data in an image.
Much of this appendix is also applicable to foreign images.
Visual Information Retrieval supports many popular image formats suitable for storing artwork, photographs, and other images in an efficient, compressed way, and provides the capability to convert between these formats. However, most of these formats are proprietary to at least some degree, and the format of their content is often widely variable, and not particularly suited for easy access to the pixel data of the image.
The raw pixel format is useful for applications that need direct access to the pixel data without the encumbrance of the complex computations required to determine the location of pixels within a compressed data stream. This simplifies reading the image for applications that are performing pixel-oriented image processing, such as filtering and edge detection. This format is even more useful to applications that need to write data back to the image. Because changing even a single pixel in a compressed image can have implications for the entire image stream, providing an uncompressed format enables applications to write pixel data directly, and later compress the image with a single call to the process( ) method.
This format is also useful to users who have data in a format not directly supported by Visual Information Retrieval, but that is in a simple, uncompressed format. These users can simply prepend a raw pixel identifier and header onto their data and import it directly into the product. For users who only need to read these images (such as for import or conversion), this capability is built into the product as "Foreign Image Support". How this capability is related to the raw pixel format is described in Section D.10.
In addition to supporting image types not already built into the product, the raw pixel format also permits the interpretation of N-band imagery, such as satellite images. Using the raw pixel format, one or three bands of an N-band image may be selected during conversion to another image format, allowing easy visualization within programs that do not otherwise support N-band images. Note that images written with the raw pixel format still may only have one or three bands.
The current version of the raw pixel format is "1.0". This appendix is applicable to raw pixel images of this release only, as the particulars of the format may change with other releases.
A raw pixel image consists of a 4-byte image identifier, followed by a 30-byte image header, followed by an arbitrary gap of zero or more bytes, followed by pixel data.
It is worth noting that raw pixel images are never color-mapped, and therefore do not contain color look-up tables.
The raw pixel "header" consists of the "Image Identifier" and the "Image Header". The image header is actually composed of several fields. Table D-1 describes the header structure.
Note that the first byte in the image is actually offset `0'. All integer fields are unsigned and are stored in big-endian byte order.
This section describes the fields of the raw pixel header in greater detail.
Occupying the first 4 bytes of a raw pixel image, the identifier string must always be set to the ASCII values "RPIX" (hex 52 50 49 58). These characters identify the image as being encoded in RPIX format.
This string is currently independent of the raw pixel version.
The raw pixel reader uses the value stored in this field to find the start of the pixel data section within a raw pixel image. To find the offset of the pixel data in the image, the reader adds the length of the image identifier (always `4') to the value in the image header-length field. Thus, for raw pixel 1.0 images with no post-header gap, the pixel data starts at offset 34.
For raw pixel version 1.0 images, this field normally contains the integer value `30', which is the length of the raw pixel image header (not including the image identifier). However, the raw pixel format allows this field to contain any value equal to or greater than 30. Any information in the space between the end of the header data and the start of the pixel data specified by this header length is ignored by the raw pixel reader. This is useful for users who wish to prepend a raw pixel header onto an existing image whose pixel data area is compatible with the raw pixel format. In this case, the header length would be set to 30 plus the length of the existing header. The maximum length of this header is 4294967265 bytes (the maximum value that can be stored in the 4-byte unsigned field minus the 30 byte header required by the raw pixel image format).
This field is stored in big-endian byte order.
A single-byte integer containing the major version number of the raw pixel format version used to encode the image. The current raw pixel version is "1.0", therefore this field is `1'.
A single-byte integer containing the minor version number of the raw pixel format version used to encode the image. The current raw pixel version is "1.0", therefore this field is `0'.
The width (x-dimension) of the image in pixels.
Although this field is capable of storing an image dimension in excess of 4 billion pixels, limitations within the product require that this field be in the range 1 <= width <= 32767.
This field is stored in big-endian byte order.
The height (y-dimension) of the image in pixels.
Although this field is capable of storing an image dimension in excess of 4 billion pixels, limitations within this product require that this field be in the range 1 <= height <= 32767.
This field is stored in big-endian byte order.
This field contains the compression type of the raw pixel image. As of version 1.0, this field may contain the following values:
| Value | Name | Compression |
|
1 |
NONE |
No compression |
|
2 |
FAX3 |
CCITT Group 3 compression |
|
3 |
FAX4 |
CCITT Group 4 compression |
For grayscale, RGB, and N-band images, the image is always uncompressed, and only a value of `0' is valid. If the compression type is value `1' or `2', then the image is presumed to be monochrome. In this case, the image is presumed to contain only a single band, and must specify "normal" pixel order, "normal" scanline order, and "BIP" interleave.
This field describes the pixel order within the raw pixel image. Normally, pixels in a scanline are ordered from left to right, along the traditional positive x-axis. However, some applications require that scanlines be ordered from right to left.
This field may contain the following values:
| Value | Name | Pixel Order |
|
1 |
NORMAL |
Left-most pixel first |
|
2 |
REVERSE |
Right-most pixel first |
This field cannot contain `0', as this indicates an unspecified pixel order; if it does contain '0', the image cannot be interpreted. For images with FAX3 and FAX4 compression types, this field must contain the value `1'.
This field describes the scanline order within the raw pixel image. Normally, scanlines in an image are ordered from top to bottom. However, some applications require that scanlines are ordered from bottom to top.
This field may contain the following values:
| Value | Name | Scanline Order |
|
1 |
NORMAL |
Top-most scanline first |
|
2 |
INVERSE |
Bottom-most scanline first |
This field cannot contain `0', as this indicates an unspecified scanline order; if it does contain '0', the image cannot be interpreted. For images with FAX3 and FAX4 compression types, this field must contain the value `1'.
This field describes the interleaving of the various bands within a raw pixel image. For more information on the meaning of the various interleave options, see Section D.5.3.
This field may contain the following values:
| Value | Name | Interleave |
|
1 |
BIP |
Band Interleave by Pixel, also known as "chunky" |
|
2 |
BIL |
Band Interleave by Line |
|
3 |
BSQ |
Band SeQuential, also known as "planar" |
This field cannot contain `0', as this indicates an unspecified interleave; if it does contain '0', the image cannot be interpreted. For images with FAX3 and FAX4 compression types, this field must contain the value `1'.
This field contains the number of bands or planes in the image, and must be in the range 1 <= number of bands <= 255. This field may not contain the value `0'.
For CCITT images, this field must contain the value `1'.
This field contains the number of the band that is to be used as the "red" channel during image conversion operations. This may be used to change the interpretation of a normal RGB image, or to specify a default band to be used as "red" in an N-band image. This default may be overridden using the "inputChannels" operator in the process( ) or processCopy( ) methods.
If the image has only one band, or only one band from an N-band image should be selected for display, then the band number should be encoded as the red channel. In this case, the green and blue channels should be set to `0'.
This field may not contain the value `0'. Only values in the range 1 <= red <= number-of-bands may be specified.
This field contains the number of the band that is to be used as the "green" channel during image conversion operations. This may be used to change the interpretation of a normal RGB image, or to specify a default band to be used as "green" in an N-band image. This default may be overridden using the "inputChannels" operator in the process( ) or processCopy( ) methods.
If the image has only one band, or only one band from an N-band image should be selected for display, then the band number should be encoded as the red channel. In this case, the green and blue channels should be set to `0'.
This field may contain values in the range 1 <= green <= number-of-bands.
This field contains the number of the band that is to be used as the "blue" channel during image conversion operations. This may be used to change the interpretation of a normal RGB image, or to specify a default band to be used as "blue" in an N-band image. This default may be overridden using the "inputChannels" operator in the process() or processCopy() command.
If the image has only one band, or only one band from an N-band image should be selected for display, then the band number should be encoded as the red channel. In this case, the green and blue channels should be set to `0'.
This field may contain values in the range 1 <= blue <= number-of-bands.
The application of these 8 bytes is currently under development, but they are reserved even within raw pixel version 1.0 images. These bytes must all be cleared to zero. Failure to do so will create undefined results.
Apart from the image identifier and the image header, raw pixel version 1.0 images contain an optional post-header "gap", which precedes the actual pixel data. Unlike the "reserved area" part of the image header, the bytes in this gap can contain any values the user wishes. This is useful to store additional metadata about the image, which in some cases may be the actual image header from another file format.
However, because there is no standard for the information stored in this gap, care must be taken if metadata is stored in this area as other users may interpret this data differently. It is also worth noting that when a raw pixel image is processed, information stored in this gap is not copied to the destination image. In the case of the process( ) method, which writes its output to the same location as the input, the source information will be lost unless the transaction in which the processing took place is rolled back.
The data section of a raw pixel image is where the actual pixel data of an image is stored; this area is sometimes called the bitmap data. This section describes the layout of the bitmap data.
For images using CCITT compression, the bitmap data area stores the raw CCITT stream with no additional header. The rest of this section applies only to uncompressed images.
Bitmap data in a raw pixel image is stored as 8-bit per plane, per-pixel, direct-color packed data. There is no pixel, scanline, or band blocking or padding. Scanlines may be presented in the image as either top-most first, or bottom-most first. Within a scanline, pixels may be ordered left-most first, or right-most first. All these options are affected by the interleave field in a relatively straightforward way. Examples are provided inthe following sections.
On the screen, an image may look like the following:
1111111111... 2222222222... 3333333333... 4444444444...
Each digit represents a single pixel; the value of the digit is the scanline that the pixel is on.
Generally, the scanline that forms the upper or top-most row of pixels is stored in the image data stream before lower scanlines. The image would appear as follows in the bitmap data stream:
...1111111111...2222222222...3333333333...4444444444...
Note that the first scanline appears earlier than the remaining scanlines. The raw pixel format refers to this scanline ordering as "normal."
However, some applications prefer that the bottom-most scanline appear in the data stream first:
...4444444444...3333333333...2222222222...1111111111...
The raw pixel format refers to this scanline ordering as "inverse."
On the screen, a scanline of an image may look like the following:
...123456789...
Each digit represents a single pixel; the value of the digit is the column that the pixel is on.
Generally, the data that forms the left-most pixels is stored in the image data stream before pixels toward the right. The scanline would appear as follows in the bitmap data stream:
...123456789...
Note that the left pixel appears earlier than the remaining pixels. The raw pixel format refers to this pixel ordering as "normal."
However, some applications prefer that the right-most pixel appear in the data stream first:
...987654321...
The raw pixel format refers to this pixel ordering as "reverse."
Band interleaving describes the relative location of different bands of pixel data within the image buffer.
Note that for the purposes of this project, bands are ordered by their appearance in an image data stream, with `1' being the first band, `n' being the last band. Band `0' would indicate `no band' or `no data.'
BIP, or "chunky", images place the various bands or channels of pixel data sequentially by pixel, so that all data for one pixel is in one place. If the bands of the image are the red, green, and blue channels, then a BIP image might look like this:
scanline 1: RGBRGBRGBRGBRGBRGBRGB... scanline 2: RGBRGBRGBRGBRGBRGBRGB... scanline 3: RGBRGBRGBRGBRGBRGBRGB... ...
BIL images place the various bands of pixel data sequentially by scanline, so that data for one pixel is spread across multiple notional "rows" of the image. This reflects the data organization of a sensor that buffers data by scanline. If the bands of the image are the red, green, and blue channels, then a BIL image might look like this:
scanline 1: RRRRRRRRRRRRRRRRRRRRR... GGGGGGGGGGGGGGGGGGGGG... BBBBBBBBBBBBBBBBBBBBB... scanline 2: RRRRRRRRRRRRRRRRRRRRR... GGGGGGGGGGGGGGGGGGGGG... BBBBBBBBBBBBBBBBBBBBB... scanline 3: RRRRRRRRRRRRRRRRRRRRR... GGGGGGGGGGGGGGGGGGGGG... BBBBBBBBBBBBBBBBBBBBB... ...
Planar images place the various bands of pixel data sequentially by bit-plane, so that data for one pixel is spread across multiple "planes" of the image. This reflects the data organization of some video buffer systems, which control the different electron guns of a display from different locations in memory. If the bands of the image are the red, green, and blue channels, then a planar image might look like this:
plane 1: RRRRRRRRRRRRRRRRRR... (part of scanline 1) RRRRRRRRRRRRRRRRRR... (part of scanline 2) RRRRRRRRRRRRRRRRRR... (part of scanline 3) ... plane 2: GGGGGGGGGGGGGGGGGG... (part of scanline 1) GGGGGGGGGGGGGGGGGG... (part of scanline 2) GGGGGGGGGGGGGGGGGG... (part of scanline 3) ... plane 3: BBBBBBBBBBBBBBBBBB... (part of scanline 1) BBBBBBBBBBBBBBBBBB... (part of scanline 2) BBBBBBBBBBBBBBBBBB... (part of scanline 3) ...
The raw pixel format supports up to 255 bands of data in an image. The relative location of these bands of data in the image is described in Section D.5.3, which gives examples of interleaving for 3 bands of data.
In the case of a single band of data, there is no interleaving; all three schemes are equivalent. Examples of interleaving other numbers of bands are given in the following table. All images have three scanlines and four columns. Each band of each pixel is represented by a single-digit band number. Numbers in italic represent the second scanline of the image, and numbers in boldface represent the third scanline of the image.
The following C language structure describes the raw pixel header in a programmatic way. This structure is stored unaligned in the image file (fields are aligned on 1-byte boundaries), and all integers are stored in big-endian byte order.
struct RawPixelHeader { unsigned char identifier[4]; /* Always "RPIX" */ unsigned long hdrlength; /* Length of this header in bytes */ /* Including the hdrlength field */ /* Not including the identifier field */ /* &k.hdrlength + k.hdrlength = pixels */ unsigned char majorversion; /* Major revision # of RPIX format */ unsigned char minorversion; /* Minor revision # of RPIX format */ unsigned long width; /* Image width in pixels */ unsigned long height; /* Image height in pixels */ unsigned char comptype; /* Compression (none, FAXG3, FAXG4, ... ) */ unsigned char pixelorder; /* Pixel order */ unsigned char scnlorder; /* Scanline order */ unsigned char interleave; /* Interleaving (BIP/BIL/Planar) */ unsigned char numbands; /* Number of bands in image (1-255) */ unsigned char rchannel; /* Default red channel assignment */ unsigned char gchannel; /* Default green channel assignment */ unsigned char bchannel; /* Default blue channel assignment */ /* Grayscale images are encoded in R */ /* The first band is '1', not '0' */ /* A value of '0' means "no band" */ unsigned char reserved[8]; /* For later use */ };
The following C language constants define the values used in the raw pixel header.
#define RPIX_IDENTIFIER "RPIX" #define RPIX_HEADERLENGTH 30 #define RPIX_MAJOR_VERSION 1 #define RPIX_MINOR_VERSION 0 #define RPIX_COMPRESSION_UNDEFINED 0 #define RPIX_COMPRESSION_NONE 1 #define RPIX_COMPRESSION_CCITT_FAX_G3 2 #define RPIX_COMPRESSION_CCITT_FAX_G4 3 #define RPIX_COMPRESSION_DEFAULT RPIX_COMPRESSION_NONE #define RPIX_PIXEL_ORDER_UNDEFINED 0 #define RPIX_PIXEL_ORDER_NORMAL 1 #define RPIX_PIXEL_ORDER_REVERSE 2 #define RPIX_PIXEL_ORDER_DEFAULT RPIX_PIXEL_ORDER_NORMAL #define RPIX_SCANLINE_ORDER_UNDEFINED 0 #define RPIX_SCANLINE_ORDER_NORMAL 1 #define RPIX_SCANLINE_ORDER_INVERSE 2 #define RPIX_SCANLINE_ORDER_DEFAULT RPIX_SCANLINE_ORDER_NORMAL #define RPIX_INTERLEAVING_UNDEFINED 0 #define RPIX_INTERLEAVING_BIP 1 #define RPIX_INTERLEAVING_BIL 2 #define RPIX_INTERLEAVING_BSQ 3 #define RPIX_INTERLEAVING_DEFAULT RPIX_INTERLEAVING_BIP #define RPIX_CHANNEL_UNDEFINED 0
Note that the various macros for the "undefined" values are meant to be illustrative and not necessarily used, except for "RPIX_CHANNEL_UNDEFINED" which is used for the green and blue channels of single band images.
The following PL/SQL constants define the values used in the raw pixel information:
CREATE OR REPLACE PACKAGE ORDVirConstants AS RPIX_HEADER_LENGTH_1_0 CONSTANT INTEGER := 34; END ORDVirConstants;
Although the raw pixel format is generally aimed at uncompressed direct color images, provision is also made to store monochrome images using CCITT Fax Group 3 or Fax Group 4 compression. This is useful for storing scans of black and white pages, such as for document management applications. These images are generally infeasible to store even as merely grayscale, as the unused data bits combined with the very high resolution used in these images would use excessive disk space.
Raw pixel images using CCITT compression are treated as normal Raw Pixel images, with the following restrictions:
In addition to these restrictions, applications that attempt to access pixel data directly will need to understand how to read and write the CCITT formatted data.
Visual Information Retrieval provides support for reading certain "foreign images" that can be described in terms of a few simple parameters, and whose data is arranged in a certain straightforward way within the image file. There is no list of the supported formats because the list would be so large and continually changing. Instead, there are some simple guidelines to determine if an image can be read using the foreign image support in the product. These rules are summarized in the following sections.
Foreign images may have any header, in any format, as long as its length does not exceed 4294967265 bytes. As has been noted before, all information in this header will be ignored.
Foreign images may be up to 32767 pixels wide.
Foreign images may be up to 32767 pixels high.
Foreign images must be uncompressed or compressed using CCITT Fax Group 3 or Fax Group 4. Other compression schemes, such as run-length encoding, are not currently supported.
Foreign images may store pixels from left-to-right or right-to-left. Other pixel ordering schemes are not currently supported.
Foreign images may have top-first or bottom-first scanline orders. Scanlines that are adjacent in the image display must be adjacent in the image storage. Some image formats stagger their image scanlines so that, for example, scanlines 1,5,9, and so forth, are adjacent, and then 2,6,10 are also adjacent. This is not currently allowed.
Foreign images must use BIP, BIL, or BSQ interleaving. Other arrangements of data bands are not allowed, nor may bands have any pixel, scanline, or band-level blocking or padding.
Foreign images may have up to 255 bands of data. If there are more bands of data, the first 255 can be accessed if the interleaving of the image is "band sequential." In this case, the additional bands of data lie past the accessible bands and do not affect the layout of the first 255 bands. Images with other interleaving types may not have more than 255 bands because the additional bands will change the layout of the bitmap data.
Foreign images may have an image trailer following the bitmap data, and this trailer may be of arbitrary length. However, such data is completely ignored by the product, and there is no method (or need) to specify the presence of length of such a trailer.
If an image with such a trailer is modified with the process( ) or processCopy( ) methods, the resulting image will not contain this trailer. In the case of the processCopy method, the source image will still be intact.
