psychopy.org | Reference | Downloads | Github

Monitor Gamma or something else Brightness/Contrast/Light related decreases each time I run my experiment


#1

Hello ladies and gentlemen,

I’ve written a software using the psychopy library. In fact I’m running an experiment that plays video stimuli.
So I’m using visual.window and MovieStim3.

Each time I run the experiment the monitor’s brighness/gamma or whatever it is decreases. This affects the settings outside of psychopy as well - desktop gets darker too.

The effect is very subtile for each run, it just adds up, when running multiple times.

The output of my gammagrid stays the same, as well as the settings that are provided to my ATI grafic card configurator.

Rebooting the system corrects and resets the driver settings I guess, because after a reboot the brightness etc is fine again.

Anybody has experience with this problem?

Is there any way to prohibit psychopy to change brighnetss /gamma settings at all? I’m not really required to allways have a calibrated brightness. But the videos become unviewable after a while.

Kind regards,

Max


#2

Here’s a related thread: Bug in 1.90 branch? Display turns dark after closing Window object


#3

I’m using psychopy 1.90.2 Standalone on Windows 7.

Interestingly the mouse pointer is not affected by the brightness change!

I’m using the latest ATI drivers for a HD4000 Series.

I’ve looked into the thread you suggested. Don’t think it is solved yet right?


#4

If I understand correctly the visual.window is basically using pyglet?


#5

Thanks for reporting this. I’ve raised an issue here.


#6

Curious. My guess is that something has changed in Windows gamma tables (e.g. as part of a Win10 update) that means a very slight error when we try to reset the windows gamma to a previous level. (The fact that the mouse cursor isn’t affected is not surprising - that’s generally white and black and only mid-grey levels should be affected by gamma settings)

It sounds like @djmannion’s fix will solve the problem for you, but we’ll need to work out whether this breaks things on other systems (e.g. with an older version of pyglet, or with an older version of windows)


#7

Thank you for the quick responses!

I will test it tomorrow when I’m in the lab.

Obviously the experiment needs to run on different computer configurations, although I’ve implemented that python 2.7 and windows 7 are required currently. If conditions are not met an error message will occur.

I’m not using Windows 10, so maybe it is something more general?

Is there any possibility to prevent Psychopy code at all to influence the systems gamma settings? Can’t it just take the desktop values in some way?

Greetings

Max


#8

That’s pretty much what it is trying to do. The issue is that in reading and rewriting the system values, a slight cumulative distortion is creeping in.

A workaround that might be worth trying in the meantime, that doesn’t require you to change anything in the psychopy code, is to put something like the below immediately before closing the window (assuming the window is called win):

origLUT = np.round(win.backend._origGammaRamp * 65535.0).astype("uint16")
origLUT = origLUT.byteswap() / 255.0
win.backend._origGammaRamp = origLUT

#9

Appologize me investigating any further, but I’m curious. Why does it need to write the settings in the first place.


#10

Often people like to have linearised monitor output while psychopy is running, but not linearised for typical desktop usage. This is why psychopy attempts to return the system to the state it was when psychopy was started - otherwise any gamma settings within psychopy would be still active after the program finishes.

In the case where no setting changes are requested, then psychopy could indeed not do anything. But there are a few ways in which the settings can be changed, so it is safer (in theory) to always reinstate the original settings.


#11

@djmannion

how can I achieve this? That it is ignored I mean? I’m not really proficient and python yet.


#12

Does the workaround I posted above fix it?


#13

@djmannion

I think so, but I’m not totally sure yet :).