Hi Chris,
We have an issue that seems to be related to blending.
We have a background stimulus, a rectangle, and then the drifting grating on top of that.
The issue appears to be that the background is set to intensity value 188 (of 255), while the drifting grating appears to be drawn on a circle that has a mean pixel value of 187 (of 255). That 0.5% contrast change, over a circle the size of the overall stimulus, appears to be partially detectable by the animals.
Here’s our simplified code:
blank_screen background (
color = 0.5, 0.5, 0.5
)
layer target_grating {
rectangle (
color = 0.5, 0.5, 0.5
)
stimulus/drifting_grating (
direction = 0
starting_phase = 0
spatial_frequency = 0.05
grating_type = sinusoid
rotation = 0
alpha_multiplier = tCurrentStimContrast
autoplay = true
)
mask (
mask = raised_cosine
edge_width = 0.4
std_dev = 0.33
mean = 0
normalized = false
)
}
We change the variable tCurrentStimContrast to vary the stim contrast.
Paul (cc’d) measured the screen pixel values, and a summary of those measurements are posted below. The mean of the grating should be 188 if color = 0.5, 0.5, 0.5 is going to equal 188.
Can you tell us if there’s a way to fix this in our code?
thanks!
Mark
Attachment: PastedGraphic-5.jpg (105 KB)
Hi Mark,
I’m currently out of the office until January 2. I’ll look in to this when I return.
Cheers,
Chris
Hi Mark & Paul,
I think I need a little more information. Can you send me a working example experiment that produces the circle with mean pixel value of 187? Or at the very least, can you tell me what value of tCurrentStimContrast corresponds to each “contrast level” in Paul’s chart?
Also, on what version(s) of MWorks are you seeing this issue?
Thanks,
Chris
Hi Chris and Paul,
I’m attaching a test experiment that shows the behavior. I took the attached screenshot of the mirror window when tCurrentStimContrast was set to zero, and adjusted brightness/contrast so you can see the mask produces a different color than the background.
We’re using the nightly from 2019.09.24.
Does this help?
Thanks,
Mark
Hi Mark,
I can reproduce this behavior, but only on my 2018 Mac mini, which has an Intel GPU. On the other three machines in my office (which all have either AMD or NVIDIA GPU’s), the stimulus display is a uniform 188 sRGB when tCurrentStimContrast is zero. For reference, are you also using a Mac with an Intel GPU?
I don’t have any immediate explanation for why this would be happening. Let me think about it a bit.
Chris
Hi Mark,
This issue seems to be due to a slight difference in how the Intel GPU and/or driver handles sRGB-format textures, as compared to its AMD and NVIDIA peers. The problem disappears when you turn off MWorks’ color management, as the layer stimulus uses a non-sRGB texture in that case.
I’m currently evaluating a few potential fixes. I’ll try to get one of them in to the nightly build soon.
Cheers,
Chris
Hey Chris,
Thanks for looking into this. Let us know what you come up with for fixes. We particularly need to keep MWorks’ color management on so that the monitor luminance is linear.
Best,
Paul LaFosse
Hi Mark & Paul,
This issue is fixed in the current nightly build. You should now see a pixel value of 188 both inside and outside the circle, even on systems with Intel GPU’s. If not, please let me know!
Cheers,
Chris
Thanks! Looks like you converted these textures to using single-precision floats. Mark
Looks like you converted these textures to using single-precision floats.
Yes, layers are now rendered into floating-point textures (actually half-precision (16-bit) floats). That avoids the need to use the GPU’s linear-to-sRGB conversion, which seems a little wonky on Intel hardware.
Chris
Great. So then I assume the linear-to-monitor colorspace conversion is
happening elsewhere?
So then I assume the linear-to-monitor colorspace conversion is happening elsewhere?
Yes, that happens near the end of the process, when the fully-rendered stimulus display framebuffer is drawn to the window.
Chris
