Only 16 grays in imagegen

[vmerget]

I have a weird problem with an imagegen plug-in I wrote.
I'm using it to display grayscale images (though the plug-in
technically accepts 32-bit RGBA) on a TEXQUAD.

The plug-in works fine *except* on one machine. On that
one machine, the plug-in only displays 16 levels of gray.
A smooth gradient from black to white turns into a
series of stripes.

Some experiments imply that the lower 4 bits of each byte
are being discarded (e.g. when I set all R and G components
to 0, I got 16 shades of blue). The bytes are fine when I
write them into the osg::Image, so it's happening after that.

It doesn't seem to be a hardware limitation of the
machine: it displays textures read from a grayscale JPEG
just fine.

Is there something in the imagegen support code that
would cause something like this?

[farshizzo]

Hi,

Have you tried creating the image as a true grayscale image? To do that you would create the image like so:image->setImage(size,size,1,1,GL_LUMINANCE,GL_UNSIGNED_BY TE,new unsigned char[size*size],osg::Image::USE_NEW_DELETE);Then you would set each pixel value using a single byte:unsigned char *pixel = image->data(x,y);
*pixel = 255;If you need the image to be created as RGBA then you can either post the code you are using or email it to me at lashkari@worldviz.com.

Also, make sure that the computer which is experiencing this problem is set to 32-bit color mode in the graphics card settings. It might be set to 16-bit.

[vmerget]

Checking the settings of the graphics card was the first thing
I checked. Unless I missed something, it's 32 bits. I also tried
a JPEG that I created in Photoshop -- an RGB image that
"just happened" to have R == G == B for all pixels --- and it
displayed a full range of greys. I looked very closely at the
screen, just to see if it were dithering 16 grays to create the
illusion of ~256 grays, and I don't believe it was.

I'll probably try creating the image as a true grayscale as an
experiment later, just to see if the result changes. I didn't
do so originally because I wanted the flexibility of being able
to write a colored image, even if the image was currently
greyscale. In particular, I might want to have a key that
adds some colored dots or squares at key points on the
mage. (Basically, the plugin enables you to dynamically
update the texture from a Python string containing a grayscale
or RGBA image in SGI format.

Here's the code that creates the image:

void InitImageGen(void *imagegen)
{
VizImageGenObj *self =
reinterpret_cast<VizImageGenObj*>(imagegen);

strcpy(self->version, "strtexture v1.0");
self->user[0] = 0;
self->dataSize = 0;


int imageWidth = nearbyPowerOf2(self->x);
int imageHeight = nearbyPowerOf2(self->y);
if (imageWidth <= 0 || imageHeight <= 0) {
imageWidth = 256;
imageHeight = 256;
}

osg::Image *image = new osg::Image;
image->setImage(imageWidth, imageHeight, 1, 4,
GL_RGBA, GL_UNSIGNED_BYTE,
new uchar[imageWidth * imageHeight * 4],
osg::Image::USE_NEW_DELETE);
clearImage(image);
self->image = image;
self->texture = new osg::Texture2D(image);
CommandImageGen(self);

self->status = 1;
}

And here's the shortest routine I use to write fill the image:

void clearImage(osg::Image *image, uchar red = 0,
uchar green = 0, uchar blue = 0,
uchar alpha = 255)
{
for (int ii = 0; ii < image->s(); ii++) {
for(int jj = 0; jj < image->t(); jj++) {
uchar *pixel = image->data(ii, jj);
pixel[0] = red;
pixel[1] = green;
pixel[2] = blue;
pixel[3] = alpha;
}
}
image->dirty();
}

[farshizzo]

Hi,

Is the computer that is experiencing this problem using a different graphics card/driver than the other computers?