Values returned from glReadPixels slightly off.

Values returned from glReadPixels slightly off.

Post by Chris Haye » Thu, 29 Oct 1998 04:00:00



I'm trying to use glReadPixels() to read pixel colors (for selection via
back buffer) and am having problems getting expected results.  The RGB float
values I get back are not quite what (I think) they should be (i.e., what
they were set to).  For example, instead of getting back an expected value
of 0.5 for the red component I get back 0.516129017.  Instead of 0.65 I get
0.645161271.  I tried setting GL_RED_BIAS and GL_RED_SCALE to 0.0 and 1.0,
respectively, via glPixelTransferf and disabling lighting and dithering but
got the same results.  Could the fact that my pixel format has only 16 color
bits have something to do with this (e.g., only 5 bits each for
GL_RED/GL_GREEN/GL_BLUE)?
Thanks.
Chris Hayes
 
 
 

Values returned from glReadPixels slightly off.

Post by Paul Mart » Fri, 30 Oct 1998 04:00:00



>I'm trying to use glReadPixels() to read pixel colors (for selection via
>back buffer) and am having problems getting expected results.  The RGB
float
>values I get back are not quite what (I think) they should be (i.e., what
>they were set to).  For example, instead of getting back an expected value
>of 0.5 for the red component I get back 0.516129017.  Instead of 0.65 I get
>0.645161271.  I tried setting GL_RED_BIAS and GL_RED_SCALE to 0.0 and 1.0,
>respectively, via glPixelTransferf and disabling lighting and dithering but
>got the same results.  Could the fact that my pixel format has only 16
color
>bits have something to do with this (e.g., only 5 bits each for
>GL_RED/GL_GREEN/GL_BLUE)?

Yes. Try running the same code in a framebuffer with 8 bits per component,
and you should get better results. But I doubt you will find a framebuffer
that will return you exactly the floating point values you specified, unless
the framebuffer stores its RGB components as IEEE floats.

If you only have 5 bits of precision, and want to get exactly the values you
specify back out, I suggest you use glColor3ub to specify the colors. Encode
the unique 5-bit value in the most significant bits of each 8-bit component.
A subsequent glReadPixels call (with format unsigned byte) should return
exactly the value you specify.

   -Paul Martz
    Hewlett Packard Workstation Systems Lab
    To reply, remove "DONTSPAM" from email address.

 
 
 

Values returned from glReadPixels slightly off.

Post by Chris Haye » Fri, 30 Oct 1998 04:00:00


O.K.  I set the color using glColor3ub and read the pixels back with type
GL_UNSIGNED_BYTE.   The values I get back via glReadPixels are still off by
a small amount (e.g., set a color component to 0xA0 (160) and read back 0x9C
(156)).
Also, after reading the MS programmer's ref (see below), it appears that the
current color will be stored as a float regardless of the type used to set
it and that unsigned integers (not sure if this includes ubyte) will be
mapped to 0.0 to 1.0.  So, if I'm interpreting what they're saying
correctly, I won't be able to specify an "absolute" byte value as the
current color (on the Windows implementation of OpenGL) or get this value
into the frame buffer.  Perhaps this is possible with other OpenGL
implementations(?)

From the MS OpenGL programmer's reference for glColor*:
------------------------------
"Current color values are stored in floating-point format, with unspecified
mantissa and exponent sizes. Unsigned integer color components, when
specified, are linearly mapped to floating-point values such that the
largest representable value maps to 1.0 (full intensity), and zero maps to
0.0 (zero intensity). Signed integer color components, when specified, are
linearly mapped to floating-point values such that the most positive
representable value maps to 1.0, and the most negative representable value
maps to -1.0. Floating-point values are mapped directly.

Neither floating-point nor signed integer values are clamped to the range
[0,1] before updating the current color. However, color components are
clamped to this range before they are interpolated or written into a color
buffer. "
--------------------------------


>If you only have 5 bits of precision, and want to get exactly the values
you
>specify back out, I suggest you use glColor3ub to specify the colors.
Encode
>the unique 5-bit value in the most significant bits of each 8-bit
component.
>A subsequent glReadPixels call (with format unsigned byte) should return
>exactly the value you specify.

>   -Paul Martz
>    Hewlett Packard Workstation Systems Lab
>    To reply, remove "DONTSPAM" from email address.

 
 
 

Values returned from glReadPixels slightly off.

Post by Paul Mart » Fri, 30 Oct 1998 04:00:00



>O.K.  I set the color using glColor3ub and read the pixels back with type
>GL_UNSIGNED_BYTE.   The values I get back via glReadPixels are still off by
>a small amount (e.g., set a color component to 0xA0 (160) and read back
0x9C
>(156)).

Hm. It would appear that you either have some state turned on which is
affecting the color, or you have a bug in your program or your OpenGL
implementation.

Quote:>Also, after reading the MS programmer's ref (see below), it appears that
the
>current color will be stored as a float regardless of the type used to set
>it and that unsigned integers (not sure if this includes ubyte) will be
>mapped to 0.0 to 1.0.  So, if I'm interpreting what they're saying
>correctly, I won't be able to specify an "absolute" byte value as the
>current color (on the Windows implementation of OpenGL) or get this value
>into the frame buffer.

Since a float has more precision than an unsigned byte, the conversion you
are referring to should not be a problem.

The OpenGL specification, section 2.13.9, is very explicit about how OpenGL
should work when the number of bits 'b' used to specify the color is greater
than the number of bits 'm' in the framebuffer. It reads as follows:
"Suppose that lighting is disabled, the color associated with a vertex has
not been clipped, and one of Colorub, Colorus, or Colorui was used to
specify that color. When these conditions are satisfied, an RGBA component
must convert to a value that matches the component as specified in the Color
command: if 'm' is less than the number of bits 'b' with which the component
was specified, then the converted value must equal the most significant 'm'
bits of the specified value..."

   -Paul Martz
    Hewlett Packard Workstation Systems Lab
    To reply, remove "DONTSPAM" from email address.

 
 
 

Values returned from glReadPixels slightly off.

Post by Chris Haye » Sat, 31 Oct 1998 04:00:00


Dithering has been disabled (as is lighting).  Same results.
At this point, I'm convinced that this is busted in the Win98 implementation
with 16 bit color.  I'd be overjoyed if someone could prove me wrong with a
code sample or just a statement like "Yes.  I've gotten it to work
(accurately read back the 5 MSBs that were written) with 16 bit color on
Windows9X/NT."
Thanks.
Chris
 
 
 

Values returned from glReadPixels slightly off.

Post by Paul Mart » Sat, 31 Oct 1998 04:00:00



>Dithering has been disabled (as is lighting).  Same results.
>At this point, I'm convinced that this is busted in the Win98
implementation
>with 16 bit color.  I'd be overjoyed if someone could prove me wrong with a
>code sample or just a statement like "Yes.  I've gotten it to work
>(accurately read back the 5 MSBs that were written) with 16 bit color on
>Windows9X/NT."

I'll be the first to admit Windows graphics isn't my strength, but doesn't
the OS provide further dithering for all colors written to the framebuffer?
And if so, shouldn't OpenGL have a way to circumvent this so that it doesn't
happen? Maybe someone in one of the Windows newsgroups has more info on
this.

In any event, it does sound like something is broken. The ability to perform
picks based on primitive color (a commonly-used OpenGL technique) depends on
this working correctly.

   -Paul Martz
    Hewlett Packard Workstation Systems Lab
    To reply, remove "DONTSPAM" from email address.

 
 
 

Values returned from glReadPixels slightly off.

Post by Andrew F. Vespe » Sat, 31 Oct 1998 04:00:00



> The OpenGL specification, section 2.13.9, is very explicit about how OpenGL
> should work when the number of bits 'b' used to specify the color is greater
> than the number of bits 'm' in the framebuffer. It reads as follows:
> "Suppose that lighting is disabled, the color associated with a vertex has
> not been clipped, and one of Colorub, Colorus, or Colorui was used to
> specify that color. When these conditions are satisfied, an RGBA component
> must convert to a value that matches the component as specified in the Color
> command: if 'm' is less than the number of bits 'b' with which the component
> was specified, then the converted value must equal the most significant 'm'
> bits of the specified value..."

Yes, that is what the specification says. However, the conformance suite does
not
test this, and I know of a number of implementation that do not guarantee this.

You are safe doing this only if you make sure that the bits that will be
discarded
are zero. For example, if you have 5 bits of Red available in the frame buffer,
you
should use only unsigned bytes with the low 3 bits clear. So, use 0x00 instead
of
0x01 through 0x07, 0x08 instead of 0x09 through 0x0f, etc.

--
Andy V (OpenGL Alpha Geek)
Non erravi perniciose!

 
 
 

Values returned from glReadPixels slightly off.

Post by Christopher Haye » Sat, 31 Oct 1998 04:00:00


O.K.  I sent a note to NVidia (maker of the processor on my graphics board)
about this problem and they mentioned that my chip, the RIVA 128/ZX, does
not allow dithering to be disabled.  Hmmm.  Errrrrrrrrrrr.  Growllllllll.
So, I went down and bought a TNT-based card which supposedly does not have
the dithering limitation and installed it.  Tried the pixel read, first, in
32-bit color mode / 8-bits per component.  No problem (ubytes read match
ubytes written exactly!).  Then the real test, switching to 16-bit color.
Describe pixel format indicated 5 bits per component.  Rendered and read the
pixels and....the 5 most significant bits match (finally)!!!
Thanks for the help on this!!!  A * one.
Chris Hayes



>>Dithering has been disabled (as is lighting).  Same results.
>>At this point, I'm convinced that this is busted in the Win98
>implementation
>>with 16 bit color.  I'd be overjoyed if someone could prove me wrong with
a
>>code sample or just a statement like "Yes.  I've gotten it to work
>>(accurately read back the 5 MSBs that were written) with 16 bit color on
>>Windows9X/NT."

>I'll be the first to admit Windows graphics isn't my strength, but doesn't
>the OS provide further dithering for all colors written to the framebuffer?
>And if so, shouldn't OpenGL have a way to circumvent this so that it
doesn't
>happen? Maybe someone in one of the Windows newsgroups has more info on
>this.

>In any event, it does sound like something is broken. The ability to
perform
>picks based on primitive color (a commonly-used OpenGL technique) depends
on
>this working correctly.

>   -Paul Martz
>    Hewlett Packard Workstation Systems Lab
>    To reply, remove "DONTSPAM" from email address.

 
 
 

1. Streamline installation (slightly off topic and off time)

Hi there,
surprise, surprise...
Back in 1992 when I was in the US, I purchased a photshop 2.5 /
Illustrator - pack. Used photoshop intensively, AI also from time to
time, flipped through the manuals, as far as I needed them...

Now, these days I decided it was time to clear some shelves. When I
loked into the AI box, I found an envelope, and in this envelope a
disk labeled Adobe Streamline. Great. Now I understood why they packed
the Streamline manual (I remember, a sticker on the shrink wrap said
something about an add-on).
Load the floppy, start slsetup, enter my name, organization, serial
number - serial number! Look into the manual. NO serial number behind
the cover! look up install in the index. Aha, page 16,
'The product serial number is on the back of the program disk.'
Hmmm, only a part number, which, of course, does not work.

Long story, short question:
Whom should I contact at Adobe, and how is that position's email
address?

I am serious about this, nope, no cheap trick, I paid for this
software, and it was my fault to not realize this sooner, but now I
would at least like to see the program on my computer and work with
it.

Thanks for reading this and maybe giving me a small hint.

Ulli

Dont flame me, I am only the keyboard player !

2. Anyone running pshop in 95 successfully?

3. glReadPixels returns corrupted image

4. How to combine two transparent Gifs

5. glReadPixels returns BGR data ?

6. Book suggestions?

7. Slightly off topic -PS and external HD

8. cpus for 3dstudio - performance ?

9. Slightly Off Topic... Agent reqd UK

10. unser interfaces (slightly off topic)

11. slightly off-topic - 3d/cad program wit moderate price

12. Slightly off subject: Inkjet printers

13. Slightly off-topic: Poser 2 Anyone