[visionegg] Re: Stimulus brightness vs. background brightness
- From: Andrew Straw <astraw@xxxxxxxxxxx>
- To: visionegg@xxxxxxxxxxxxx
- Date: Thu, 10 Feb 2005 02:15:09 -0800
On Feb 7, 2005, at 1:37 AM, Martin Spacek wrote:
I've noticed that if I set both the brightness of a target and the
brightness of the screen background to be 0.1, I can still faintly
distinguish the target from the background (the target is slightly
darker). This isn't the case if I set them both to 0.099 or 0.11. Has
anyone else noticed this? Is this some kind of roundoff error, where
the value for the target is rounding off in a different way from the
value of the background?
(I've just been reformatting a manuscript today to have "bullet point"
sub-section titles, so bear with me...)
More background on the artifact.
I just ran a similar test on one of my systems (nVidia on linux), and
although I can't see the difference on my LCD display, a saved frame
has mostly pixel values of 26 while the target is 25. (I used
something like the makeMovie.py demo to save the frames for later
analysis.) Running again on my iBook G4, I get mostly pixel values of
25 with a target at 26.
Is the artifact related to blending?
Blending is the mathematical function used to convert (and combine) new
color information of "fragments" onto the framebuffer. After modifying
Target2D to disable blending, I (surprisingly) get the similar behavior
on my iBook. This would seem to rule out blending as the cause
(although, "disabling" blending really must mean setting the blending
function to one that takes the source values directly to replace the
destination values). Furthermore, it indicates that OpenGL treats "0.1"
differently as a color value to the clear screen command versus a fill
color for a quad.
If I create two Target2DNoBlending stimuli (my modified version that
disables blending), both with the same color, one draw huge to re-paint
the screen background, I do get a uniform color screen. (Whew!) Yet, if
I use the original versions of Target2D for this test, I an outline of
the smaller rectangle may have pixels values as much a 2 away from the
background color. This is undoubtedly due to some interaction between
the related players of blending, anti-aliasing, and the limited dynamic
range of the frame buffer.
The working hypothesis and conclusions.
So, there seem to be two issues here 1) OpenGL may interpret color
values for clearing differently than for fragments. 2) Blending into a
limited bit-depth framebuffer may introduce quantization errors, even
if both source and destination have the same color.
Unfortunately, this looks like a system/driver/phase-of-moon dependent
OpenGL thing, and nothing the Vision Egg can control. :(
If this is a serious issue for you (and I'm sure it may be a serious
issue for anyone doing low-contrast work), I offer the suggestion of
drawing into an array, sending this to a texture object, and rendering
that. If you have a better idea, I'd love to hear it.
Cheers!
Andrew
Andrew D. Straw Post-doctoral scholar
,-. Dickinson Lab
\_/ California Institute of Technology
8||} Mailcode 138-78
/ \ Pasadena CA 91125, USA
`-^
email: astraw@xxxxxxxxxxx
office: +1 626 395 5828
======================================
The Vision Egg mailing list
Archives: //www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html
Other related posts:
