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