psychopy.org | Reference | Downloads | Github

Bits# and Gamma Correction


#1

Hi guys,

I haven’t been using my Bits# lately and I think something has changed in the last year and I can’t figure out what. Previously, I have manually entered the gamma correction values into the linearisation table in Monitor Centre and then controlled the bits# in the code and everything worked as expected.

Now, the window starts off gamma corrected, but as soon as the bits# is activated is switches back to it’s non-linearised state. Do I now need to enter the correction values directly into a LUT or is there a way to persuade the Bits# to take the values from PsychoPy?

Thanks,
Becky

FWIW this minimal script produces the effect - the screen becomes noticeably darker after the bits# is initialised:

from psychopy import visual,event
from psychopy.hardware import crs

myWin = visual.Wndow(size = [1024,768], screen = 1, useFBO = True, fullscr = True, allowGUI = False, monitor = ‘Topaz’, units = ‘pix’)

bits = crs.BitsSharp(myWin, mode = ‘bits++’)
event.waitKeys()


#2

Hi Becky

When the Bits++/Bits#/Display++ device is initialised by PsychoPy, a linear ramp should be loaded into the host GPU palette. That is done to ensure that the specially coded RGB values that need to be used to create your high-resolution colour/contrast stimuli are the values that actually get sent to the device in the video stream. Any other type of transfer function in the host GPU palette would break our special RGB encoding scheme.

Monitor Centre had a special calibration mode to support Bits++/Bits#/Display++ running in Bits++ video mode. This applied the calibration state to the T-Lock LUT that gets transmitted to the device and loaded into the Bits++/Bits#/Display++ palette. I don’t know of any reason why that would have changed.

As you have a Bits# system, you can bypass the PsychoPy Monitor Centre linearisation tables and use the Bits#/Display++ hardware gamma correction tables instead. The factory tables are stored in the /Gamma folder on the USB MSD volume; the active table is defined in the config.xml device configuration file stored in the /Firmware folder on the USB MSD volume. Set the value. These hardware tables are compatible with all three video modes (Bits++/Mono++/Color++) and get loaded automatically when the device displays live video. You can also change the enableGammaCorrection value on demand using the USB CDC interface. The default “13bitLinearLUT.txt” table is filled with the linear ramp, so your host RGB values get passed through unchanged. You can load any other transfer function that you like for each RGB channel. A sample “invGammaLUT.txt” table is provided so you can see what you need to use to get a typical CRT linear light output characteristic.

Hope this helps.

Steve


#3

I have encountered the same issue when using the mono++ mode. A similar minimal example would be:

from psychopy import visual,event
from psychopy.hardware import crs

myWin = visual.Wndow(size = [1024,768], screen = 1, useFBO = True, fullscr = True, allowGUI = False, monitor = ‘exp’, units = ‘deg’)

bits = crs.BitsSharp(myWin, mode = ‘mono++’)
event.waitKeys()

The ‘exp’ monitor has a calibration file in which a single gamma value is defined. Currently, it is unclear to me which value the ‘gammaCorrect’ argument should get in order to ensure that everything is properly loaded.

Second, do I understand correctly that bits.setContrast should not be used for the mono++ mode, but that the contrast of a stimulus can be modulated by using stim.contrast?

Thanks in advance,
Pieter.


#4

Hi Steve,

I’ve finally had a chance to try this out. If I understand you correctly changing the enableGammaCorrection value in config.xml to ‘invGammaLUT.txt’ should mean that the display is corrected with a gamma value of 2.2. If I do this and the monitor defined in PsychoPy has gamma values inputted the results are the same as described above, where the outputs become uncorrected as soon as the bits# is activated. If I do it with the testMonitor and no gamma correction in PsychoPy then it is uncorrected throughout as you might expect.

This leads me to suspect that the issue isn’t with PsychoPy, but that perhaps my Bits# isn’t working as it should?? Any suggestions?

Thanks very much,
Becky