SoMFImage Class Reference
[Fields]

Field containing multiple 2D images. More...

#include <Inventor/fields/SoMFImage.h>

Inheritance diagram for SoMFImage:
SoMField SoField SoTypedObject

List of all members.

Public Types

enum  CopyPolicy {
  COPY = 0,
  NO_COPY = 1,
  NO_COPY_AND_DELETE = 2,
  NO_COPY_AND_FREE = 3
}

Public Member Functions

virtual SoType getTypeId () const
const SoMFImageoperator= (const SoMFImage &f)
 SoMFImage ()
virtual ~SoMFImage ()
const unsigned char * getValue (SbVec2s &size, int &nc) const
void setValue (const SbVec2s &size, int nc, const unsigned char *bytes, CopyPolicy copy=COPY)
void setNeverWrite (SbBool neverWrite)
SbBool isNeverWrite ()
SbBool hasTransparency () const

Static Public Member Functions

static SoType getClassTypeId ()

Detailed Description

Field containing multiple 2D images.

A field containing two-dimensional images. Images can be grayscale (intensity), grayscale with transparency information, RGB, or RGB with transparency. Each component of the image (intensity, red, green, blue or transparency (alpha)) can have an unsigned one-byte value from 0 to 255.

Values are returned as arrays of unsigned chars. The image is stored in this array starting at the bottom left corner of the image with the intensity or red component of that pixel, followed by either the alpha, the green and blue, or the green, blue and alpha components (depending on the number of components in the image). The next value is the first component of the next pixel to the right.

SoMFImages are written to file as three integers representing the width, height and number of components in the image, followed by width*height hexadecimal values representing the pixels in the image, separated by whitespace. A one-component image will have one-byte hexadecimal values representing the intensity of the image. For example, 0xFF is full intensity, 0x00 is no intensity. A two-component image puts the intensity in the first (high) byte and the transparency in the second (low) byte. Pixels in a three-component image have the red component in the first (high) byte, followed by the green and blue components (so 0xFF0000 is red). Four-component images put the transparency byte after red/green/blue (so 0x0000FF80 is semi-transparent blue). Note: each pixel is actually read as a single unsigned number, so a 3-component pixel with value "0x0000FF" can also be written as "0xFF" or "255" (decimal).

For example,

      1 2 1 0xFF 0x00
     

is a 1 pixel wide by 2 pixel high grayscale image, with the bottom pixel white and the top pixel black. And:

      2 4 3 0xFF0000 0xFF00 0 0 0 0 0xFFFFFF 0xFFFF00
     

is a 2 pixel wide by 4 pixel high RGB image, with the bottom left pixel red, the bottom right pixel green, the two middle rows of pixels black, the top left pixel white, and the top right pixel yellow.

Data copying:

SoMF fields are a kind of "smart container", automatically expanding as necessary to hold the data provided by the application. This is very convenient, but for large blocks of data it may be desireable to avoid making a copy of the application data. The setValuesPointer() methods allow Open Inventor to directly use an array of values supplied by the application. The application data is not copied. Please see SoMFVec3f for more information and example code.

SEE ALSO

SoField, SoMField


Member Enumeration Documentation

SoMFImage may be manipulating some large amounts of memory.

It is therefore convienent to be able to set the memory usage policy dynamically. By default, the memory policy is COPY, which is consistent with other OIV fields. The most likely to be efficient is NO_COPY. See also setNeverWrite.

Enumerator:
COPY 

Open Inventor will make a copy of the data (default).

NO_COPY 

Passed buffer used, user will delete.

NO_COPY_AND_DELETE 

Passed buffer used, SoMFImage will delete.

Use this if memory is allocated with "new".

NO_COPY_AND_FREE 

Passed buffer used, SoMFImage will free.

Use this if memory is allocated with "malloc".


Constructor & Destructor Documentation

SoMFImage::SoMFImage (  ) 

Default constructor.

virtual SoMFImage::~SoMFImage (  )  [virtual]

Destructor.


Member Function Documentation

static SoType SoMFImage::getClassTypeId (  )  [static]

Returns the type identifier for this class.

Reimplemented from SoMField.

virtual SoType SoMFImage::getTypeId (  )  const [virtual]

Returns the type identifier for this specific instance.

Implements SoTypedObject.

const unsigned char* SoMFImage::getValue ( SbVec2s size,
int &  nc 
) const

Returns the pixels in the image as an array of unsigned chars.

The size and nc arguments are filled in with the dimensions of the image and the number of components in the image; the number of bytes in the array returned will be size[0]* size[1]* nc.

SbBool SoMFImage::hasTransparency (  )  const

Returns TRUE if the image contains any transparent pixels.

Specifically if the image has 2 or 4 components and at least one pixel has an alpha value less then 255.

SbBool SoMFImage::isNeverWrite (  )  [inline]

Queries the "neverWrite" flag.

const SoMFImage& SoMFImage::operator= ( const SoMFImage f  ) 

Copy from another field of same type.

void SoMFImage::setNeverWrite ( SbBool  neverWrite  ) 

Sets the "neverWrite" flag.

As this field may have to handle large amounts of data and its representation in an .iv file is not very efficient, it is often a good idea not to allow that data to be written out when required by a write action. By default, the "neverWrite" condition is FALSE.

void SoMFImage::setValue ( const SbVec2s size,
int  nc,
const unsigned char *  bytes,
CopyPolicy  copy = COPY 
)

Sets the value of this field to be an image of the given size, with the given number of components, and with the given pixel values.

size[0]* size[1]* nc bytes from the given array will be copied into internal storage maintained by the SoMFImage field.

At times, SoMFImage may need to manipulate large amounts of memory. Therefore, it is useful to be able to specify the memory usage policy dynamically. By default, the memory policy is COPY, which is consistent with other Open Inventor fields. The most likely to be efficient is NO_COPY. See also setNeverWrite().


The documentation for this class was generated from the following file:

Open Inventor Toolkit reference manual, generated on 15 Mar 2023
Copyright © Thermo Fisher Scientific All rights reserved.
http://www.openinventor.com/