Hi. I have to apologize for what seems like a trivial question. But I couldn't find the answer on the forum.
I superimpose two drifting gratings to produce a plaid. Everything works well at low drifting speeds (<1 Hz), but I get an artifact (see attached image) at higher speeds (>1 Hz). The artifact looks like a circle at the corner of the plaid's intersections.
I'm attaching my code so you can reproduce the artifact. If you comment out line 120 (to produce one grating), you can see that the artifact arises from the non-smooth edge of the grating bars, which only occurs at high drifting speeds. Strangely, only the edge that's in the direction of motion has a discontinuity.
My guess is that this is an aliasing issue since I have no problems at low speeds. My monitor (refresh rate 120 Hz) should be able to handle speeds well above 2 Hz. My spatial frequencies aren't that low (0.002 cycles/pixel) I made sure my texture size and sinusoid period were integers. What else can I try?
How was that picture created? Photo of the screen or screenshot via Screen('GetImage')?
One thing you don't do in your code is set the floatprecision flag in 'MakeTexture', so your grating textures will still be resolved with only 8 bits unsigned, 256 levels of grey, instead of signed floating point precision, so i think the negative half-waves are not represented with a negative sign, but just as below 50% gray values.
The other is that you don't use additive alpha blending, so what you create is not a mathematical superposition of two gratings afaics. AdditiveBlendingForLinearSuperPositionTutorial.m would be the demo that shows linear superposition. Or the GarboriumDemo.m or ProceduralGarboriumDemo.m.
If those would be ruled out, it could be some artifact of the display device, but i think fixing those two would be a good start. -mario
I ran your code quickly on my laptop (macbook pro retina) I'm not seeing the problem you are describing. How did you grab the screen shot?
Do you see the problem on individual frames? You can modify your while loop code to pause on individual frames. Does the artifact still show up? "yoffset" is the key variable that's changing when you increase speeds. What are there specific values for "yoffset" that cause this artifact?
Remove the && KbCheck from your while loop and add this code:
Hi. I have to apologize for what seems like a trivial question. But I couldn't find the answer on the forum.
I superimpose two drifting gratings to produce a plaid. Everything works well at low drifting speeds (<1 Hz), but I get an artifact (see attached image) at higher speeds (>1 Hz). The artifact looks like a circle at the corner of the plaid's intersections.
I'm attaching my code so you can reproduce the artifact. If you comment out line 120 (to produce one grating), you can see that the artifact arises from the non-smooth edge of the grating bars, which only occurs at high drifting speeds. Strangely, only the edge that's in the direction of motion has a discontinuity.
My guess is that this is an aliasing issue since I have no problems at low speeds. My monitor (refresh rate 120 Hz) should be able to handle speeds well above 2 Hz. My spatial frequencies aren't that low (0.002 cycles/pixel) I made sure my texture size and sinusoid period were integers. What else can I try?
The picture was a screenshot, because the artifact only appears in motion, so the screen grab from Screen GetImage looks normal (attached), regardless of when the image is grabbed during the stimulus cycle. The on-screen display also looks normal when the stimulus playback is paused.
Changing the floatprecision flag in 'MakeTexture' didn't resolve the artifact.
I'll do proper linear superposition with alpha blending and will keep you posted.
Couold you clarify what you mean by screenshot? Was it taken by a camera? The screen print button on the keyboard? etc. If Screen('GetImage') does not show a problem, this may be telling, but we'd need to know more first.
The picture was a screenshot, because the artifact only appears in motion, so the screen grab from Screen GetImage looks normal (attached), regardless of when the image is grabbed during the stimulus cycle. The on-screen display also looks normal when the stimulus playback is paused.
Changing the floatprecision flag in 'MakeTexture' didn't resolve the artifact.
I'll do proper linear superposition with alpha blending and will keep you posted.
I can say that we had ghosting issues on the original VIEWPixx where a moving dot would leave a persistent trail on a dark background. This is a limitation of slow (as in pixel rise and fall times, relative to CRTs) LCD panels. We had more success with the VIEWPixx3D (faster panel but only 10-bit luminance instead of 12) and the backlight scanning mode enabled.
Not sure if this applies to your situation, but it seems possible since you have no artifacts at low speeds.
Pardon the confusion. The image that shows the artifact was taken with my iphone camera, of the display screen. This is the only way I can capture the artifact. The second image is from Screen('GetImage'), and it look fine.
Yep agreed, while it still makes sense to fix the linear superposition in code, for that visual artifact, enabling the scanning backlight might be your best option.
Yep agreed, while it still makes sense to fix the linear superposition in code, for that visual artifact, enabling the scanning backlight might be your best option.
The backlight did the trick! But I'm not sure I totally get why.
I changed the flag from: PsychDataPixx('EnableVideoScanningBacklight') to PsychDataPixx(DisableVideoScanningBacklight'),
and got rid of the artifacts. According to the help file, the 'Disable'
flag maintains the backlight on continuously, whereas the 'Enable' flag
turns on backlight scanning 'in synchrony with LCD pixel updates'.
So, I guess the scanning couldn't be done fast-enough?
--- In PSYCHTOOLBOX@yahoogroups.com, <madinehsarvestani@...> wrote :
> The backlight did the trick! But I'm not sure I totally get why.
With a scanning backlight you just have a higher chance of picking up irregularities in the settling time course of the LC pixels. I guess that the pixels within this artificial circle share a specific property regarding the pixel luminance range and the direction and rate of pixel change (like all pixels in there increase in luminance when the plaid is in motion, or they switch from becoming brighter to becoming darker - something like that). This is also in line with your observations with a simple grating. However, it is particularly disturbing that the artificial circle is so sharply defined and that the luminance error seems to be relatively uniform; and all this across quite some range of gray levels. Hard to believe that this could be induced by pure LC physics. Maybe it is some problem with the overdrive control in the VIEWPixx monitor.