DriftDemo2: mask looks too transparent

1

Dear PTB experts,

I use Ubuntu with AMD Radeon R9 380 "Tonga pro" and PTB version 3.0.12.

In my study I want to show moving gratings blended at the borders with a Gaussian mask, pretty much as in DriftDemo2.

However in both my script and in the DriftDemo2 the mask looks too transparent: one can see some strips even in the corners, which make the square pattern obvious. In the other words, the strips never become as gray as the background.


This effect was reproduced with different displays and screen refresh rates (60 to 240 Hz). However, this effect disappears when I run my script on MAC OS, with the same PTB version.

Could anybody suggest what is the problem and how to resolve it?


Elena

2
XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :

Dear PTB experts,

 

I use Ubuntu with AMD Radeon R9 380 "Tonga pro" and PTB version 3.0.12.

 

In my study I want to show moving gratings blended at the borders with a Gaussian mask, pretty much as in DriftDemo2.

However in both my script and in the DriftDemo2 the mask looks too transparent: one can see some strips even in the corners, which make the square pattern obvious.  In the other words, the strips never become as gray as the background.


-> The script is a bit sloppy when it calculates the 1-exp hull function and the alpha channel never exactly reaches the maximum 255 value for totally intransparent. As 'MakeTexture' always rounds down, it ends up at 254, letting a bit of signal through. You could add some round() statement there to enforce the 255 value.


This effect was reproduced with different displays and screen refresh rates (60 to 240 Hz). However, this effect disappears when I run my script on MAC OS, with the same PTB version.


-> If you see the 1 unit difference to background, ie. 1/256th, depends on the numeric roundoff behaviour of the specific graphics card in 8 bit framebuffer mode, the gamma correction, display type/settings etc. Your Linux system will use 1.0 gamma by default unless you set different gamma luts. The OSX machine will probably correct for a 2.2 gamma by default, displaying things slightly different. Or the graphics card in the Mac rounds a little bit differently in 8 bpc mode, given the input.


On my Linux laptop i don't see the effect with DriftDemo2, but instead see the problem with DriftDemo or DriftWaitDemo, where also a round() statement is missing.


One way to avoid such problems apart from more careful coding is to use higher precision floating point textures or framebuffers, as shown, e.g., in BitsPlusCSFDemo or GarboriumDemo or AdditiveBlendingForLinearsuperpositionTutorial.


For Gabor patches you could also use our procedural Gabor shader instead like in ProceduralGaborDemo or ProceduralGarboriumDemo. This shader always works with maximum precision and are much faster and flexible, especially if you need many Gabor patches or dynamic changes of parameters.


Btw. your systems software update manager should have informed you by now that an update of the PTB from NeuroDebian to the latest 3.0.14 release is available. That update would be recommended.


-mario


Could anybody suggest what is the problem and how to resolve it?


Elena

3

Dear Mario,

-> The script is a bit sloppy when it calculates the 1-exp hull function and the alpha channel never exactly reaches the maximum 255 value for totally intransparent. As 'MakeTexture' always rounds down, it ends up at 254, letting a bit of signal through. You could add some round() statement there to enforce the 255 value.

This is exactly what I did and now I do not have the transparency effect.

However, I noticed another problem. One of my stimulus is a very low contrast (1%) gray sine grating. However, with this contrast I see only two shades of gray: background and grating. I do not see any gradual transitions between the grating strips. Unlike my Ubuntu Linux, I do see these transitions on my mac. The values in the grating matrix have 4 digits after the point, which is apparently enough for good precision:

128.6874 128.5462 128.3964 128.2404 128.0805 127.9195 ...

When I change gamma in the terminal window: xgamma -gamma 2.2, it does not help.

How can I increase the precision?


Elena




On 29 January 2017 at 06:15, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Dear PTB experts,

I use Ubuntu with AMD Radeon R9 380 "Tonga pro" and PTB version 3.0.12.

In my study I want to show moving gratings blended at the borders with a Gaussian mask, pretty much as in DriftDemo2.

However in both my script and in the DriftDemo2 the mask looks too transparent: one can see some strips even in the corners, which make the square pattern obvious. In the other words, the strips never become as gray as the background.


-> The script is a bit sloppy when it calculates the 1-exp hull function and the alpha channel never exactly reaches the maximum 255 value for totally intransparent. As 'MakeTexture' always rounds down, it ends up at 254, letting a bit of signal through. You could add some round() statement there to enforce the 255 value.


This effect was reproduced with different displays and screen refresh rates (60 to 240 Hz). However, this effect disappears when I run my script on MAC OS, with the same PTB version.


-> If you see the 1 unit difference to background, ie. 1/256th, depends on the numeric roundoff behaviour of the specific graphics card in 8 bit framebuffer mode, the gamma correction, display type/settings etc. Your Linux system will use 1.0 gamma by default unless you set different gamma luts. The OSX machine will probably correct for a 2.2 gamma by default, displaying things slightly different. Or the graphics card in the Mac rounds a little bit differently in 8 bpc mode, given the input.


On my Linux laptop i don't see the effect with DriftDemo2, but instead see the problem with DriftDemo or DriftWaitDemo, where also a round() statement is missing.


One way to avoid such problems apart from more careful coding is to use higher precision floating point textures or framebuffers, as shown, e.g., in BitsPlusCSFDemo or GarboriumDemo or AdditiveBlendingForLinearsuper positionTutorial.


For Gabor patches you could also use our procedural Gabor shader instead like in ProceduralGaborDemo or ProceduralGarboriumDemo. This shader always works with maximum precision and are much faster and flexible, especially if you need many Gabor patches or dynamic changes of parameters.


Btw. your systems software update manager should have informed you by now that an update of the PTB from NeuroDebian to the latest 3.0.14 release is available. That update would be recommended.


-mario


Could anybody suggest what is the problem and how to resolve it?


Elena


4
--In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :

Dear Mario,

-> The script is a bit sloppy when it calculates the 1-exp hull function and the alpha channel never exactly reaches the maximum 255 value for totally intransparent. As 'MakeTexture' always rounds down, it ends up at 254, letting a bit of signal through. You could add some round() statement there to enforce the 255 value.

This is exactly what I did and now I do not have the transparency effect.


-> Good. I fixed some of the scripts with round() statements for the next ptb beta.


However, I noticed another problem. One of my stimulus is a very low contrast (1%) gray sine grating. However, with this contrast I see only two shades of gray: background and grating. I do not see any gradual transitions between the grating strips. Unlike my Ubuntu Linux, I do see these transitions on my mac. The values in the grating matrix have 4 digits after the point, which is apparently enough for good precision:

128.6874  128.5462  128.3964  128.2404  128.0805  127.9195 ...


-> The digits get truncated to zero by PTB, to integral values 0 - 255, so above sequence would get drawn as 128,128,128,128,128,127

-> Exactly two values. The framebuffer is 8 bpc by default, so also can only represent those 256 discrete levels

So i'm not sure how you could get anything but 2 levels? That BenQ display you have also only supports 256 discrete levels.


You'd have to show me your exact code that you use. Also the specification of the Mac - what Macintosh model, graphics card, monitor, what OSX version? Same Psychtoolbox? Same display device and display settings (resolution etc.)? Moving stimuli?


You can use Screen('GetImage', ...) to take screenshots of what ends up in the framebuffer.



When I change gamma in the terminal window:  xgamma -gamma 2.2, it does not help. 

How can I increase the precision?


-> You could use high precision floating point textures and high precision floating point framebuffers, as well as a Native 10 bit framebuffer mode. Cfe. AdditiveBlendingForLinearSuperpositionTutorial ('Native10Bit') that demonstrates this and the needed setup steps. Your BenQ 240 Hz panel is only 8 bpc capable, so it can't really output finer than 1/256th. However, you can enable digital display spatial dithering, and that would perceptually simulate 10 bpc or 1024 levels of intensity. Downside might be that the dithering method would interfere with high frequency spatial low level stimuli like gratings of small period. Another perceptual method of simulating ~ 10.7 bpc on a 8 bpc display is to use the method shown via AdditiveBlendingForLinearSuperpositionTutorial ('PseudoGray') for pure luminance/grayscale stimuli. That one requires proper gamma correction and may not introduce spatial artifacts, but slight colorization.


I'm a bit worried if you want to use such low contrast gratings on the 240 Hz display for animations? LCD panels are not known for fast pixel response times. The way such fast panels like yours achieve the feat of 240 fps animations is usually by using all kinds of trickery like Overdrive to boost the transition speed of the lcd pixels. Those usually come with significant color/luminance artifacts or loss of precision for fast moving stimuli, which may well totally distort your stimulus especially at such low contrasts, effectively showing not the stimuli you actually specified. The rule for digital displays is usually "fast, accurate, cheap -- pick (at most) two of these".


-mario



Elena




On 29 January 2017 at 06:15, mario.kleiner@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
 

XX---In PSYCHTOOLBOX@yahoogroups.com, <orekhova.elena.v@...> wrote :


Dear PTB experts,

 

I use Ubuntu with AMD Radeon R9 380 "Tonga pro" and PTB version 3.0.12.

 

In my study I want to show moving gratings blended at the borders with a Gaussian mask, pretty much as in DriftDemo2.

However in both my script and in the DriftDemo2 the mask looks too transparent: one can see some strips even in the corners, which make the square pattern obvious.  In the other words, the strips never become as gray as the background.


-> The script is a bit sloppy when it calculates the 1-exp hull function and the alpha channel never exactly reaches the maximum 255 value for totally intransparent. As 'MakeTexture' always rounds down, it ends up at 254, letting a bit of signal through. You could add some round() statement there to enforce the 255 value.


This effect was reproduced with different displays and screen refresh rates (60 to 240 Hz). However, this effect disappears when I run my script on MAC OS, with the same PTB version.


-> If you see the 1 unit difference to background, ie. 1/256th, depends on the numeric roundoff behaviour of the specific graphics card in 8 bit framebuffer mode, the gamma correction, display type/settings etc. Your Linux system will use 1.0 gamma by default unless you set different gamma luts. The OSX machine will probably correct for a 2.2 gamma by default, displaying things slightly different. Or the graphics card in the Mac rounds a little bit differently in 8 bpc mode, given the input.


On my Linux laptop i don't see the effect with DriftDemo2, but instead see the problem with DriftDemo or DriftWaitDemo, where also a round() statement is missing.


One way to avoid such problems apart from more careful coding is to use higher precision floating point textures or framebuffers, as shown, e.g., in BitsPlusCSFDemo or GarboriumDemo or AdditiveBlendingForLinearsuper positionTutorial.


For Gabor patches you could also use our procedural Gabor shader instead like in ProceduralGaborDemo or ProceduralGarboriumDemo. This shader always works with maximum precision and are much faster and flexible, especially if you need many Gabor patches or dynamic changes of parameters.


Btw. your systems software update manager should have informed you by now that an update of the PTB from NeuroDebian to the latest 3.0.14 release is available. That update would be recommended.


-mario


Could anybody suggest what is the problem and how to resolve it?


Elena