[visionegg] Re: Stimulus brightness vs. background brightness

Hi Andrew,

Thanks for that. Well, I tried making a second Target2D stimulus and treating it as the background. Seems to work perfectly. I've tried several different intensities, and when equal, the foreground and background targets are indistinguishable. This is true for both aliased and antialiased targets, running with and without gamma correction. You said you found that wasn't the case unless you modified the code for Target2D? That doesn't seem to be necessary, at least in my case... Keep in mind, I'm using only greyscale.

This is on an Nvidia with OpenGL 1.4.1 in Win2K with the 1.0 cvs, running at 8x8x8x8 bit depth. I'll try it on a different system in the lab. If I find anything different, I'll report it.

Cheers,

Martin Spacek
PhD student, Swindale lab
Graduate Program in Neuroscience
Dept. of Ophthalmology and Visual Sciences
University of British Columbia, Vancouver, BC, Canada
+1-604-875-4555 ext. 66282
mspacek@xxxxxxxxxxxxxxx | http://swindale.ecc.ubc.ca

On 2005-02-10 2:15 AM, Andrew Straw wrote: 
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: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: