#include <Inventor/fields/SoSFImage.h>
Inheritance diagram for SoSFImage::
Public Methods | |
const unsigned char * | getValue (SbVec2s &size, int &nc) const |
void | setValue (const SbVec2s &size, const int nc, const unsigned char *bytes) |
int | operator== (const SoSFImage &field) const |
int | operator!= (const SoSFImage &field) const |
unsigned char * | startEditing (SbVec2s &size, int &nc) |
void | finishEditing (void) |
Static Public Methods | |
void | initClass (void) |
The SoSFImage class provides storage for inline 2D image maps. Images in Coin are mainly used for texture mapping support.
SoSFImage instances can be exported and imported as any other field class in Coin.
The components of an SoSFImage is: its image dimensions (width and height), the number of bytes used for describing each pixel (number of components) and an associated pixel buffer. The size of the pixel buffer will be width*height*components.
For texture maps, the components / bytes-per-pixel setting translates as follows: use 1 for a grayscale imagemap, 2 for grayscale + opacity (i.e. alpha value), 3 for RGB (1 byte each for red, green and blue) and 4 components means 3 bytes for RGB + 1 byte opacity value (aka RGBA).
This field is serializable into the Inventor / Coin file format in the following manner:
FIELDNAME X Y C 0xRRGGBBAA 0xRRGGBBAA ...
"X" and "Y" are the image dimensions along the given axes, "C" is the number of components in the image. The number of 0xRRGGBBAA pixel color specifications needs to equal the exact number of pixels, which of course is given by X*Y. Each part of the pixel color value is in the range 0x00 to 0xff (hexadecimal, 0 to 255 decimal).
For 3-component images, the pixel-format is 0xXXRRGGBB, where the byte in the pixel color value marked as "XX" is ignored and can be left out.
For 2-component images, the pixel-format is 0xXXXXGGAA, where the bytes in the pixel color values marked as "XX" are ignored and can be left out. "GG" is the part which gives a grayscale value and "AA" is for opacity.
For 1-component images, the pixel-format is 0xXXXXXXGG, where the bytes in the pixel color values marked as "XX" are ignored and can be left out.
The pixels are read as being ordered in rows along X (width) and columns along Y (height, bottom to top).
Here's a simple example of the file format serialization, for a 2x2 RGB-image inside an SoTexture2 node, as mapped unto an SoCube:
Texture2 { image 2 2 3 0xffffff 0x00ff00 # white green 0xff0000 0xffff00 # red yellow } Complexity { textureQuality 0.1 } # set low to avoid smoothing Cube { }
The mini-scenegraph above results in the following mapping on the cube:
The cube has only been slightly rotated, so as you can see from the snapshot, the Y-rows are mapped from bottom to top, while the X-column pixels are mapped unto the cube from left to right.
|
Internal method called upon initialization of the library (from SoDB::init()) to set up the type system. Reimplemented from SoSField. |
|
Return pixel buffer, set size to contain the image dimensions and nc to the number of components in the image. |
|
Initialize this field to size and nc.
If bytes is not The image dimensions is given by the size argument, and the nc argument specifies the number of bytes-pr-pixel. A 24-bit RGB image would for instance have an nc equal to 3. |
|
Compare image of field with the image in this field and return |
|
Compare image of field with the image in this field and return |
|
Return pixel buffer, set size to contain the image dimensions and nc to the number of components in the image. The field's container will not be notified about the changes until you call finishEditing(). |
|
Notify the field's auditors that the image data has been modified. |