I’ve got some time to look into this over the next few days. Hopefully I make some progress (if only to realise that the scope of the challenge is beyond me).
I have a couple of requests from my reading so far:
A script showing the current canonical use of a Bits#?
Looking through the API, there are a few deprecated methods. For example, the
visual.Window class contains a deprecated
bitsMode, who’s entry now says
DEPRECATED in 1.80.02. Use BitsSharp class from pycrsltd instead.
However, I can’t see the
pycrsltd library being loaded anywhere. Instead, there’s the
hardware.crs.BitsSharp class within
psychopy/hardware/crs/bits.py. The example for this class shows
from psychopy import visual
from psychopy.hardware import crs
# we need to be rendering to framebuffer
win = visual.Window([1024,768], useFBO=True)
bits = crs.BitsSharp(win, mode = 'mono++')
# You can continue using your window as normal and OpenGL shaders
# will convert the output as needed
Is that the current canonical method for using Bits#?
Ultimately I’d like to emulate something like this for the VIEWPixx, but this week I think I’d be content to get a high-bitdepth greyscale out.
The VPIXX python library
VPIXX software tools, available from here (may require a user account), contains a Python interface library
pypixxlib. This is currently version 1.5, and seems quite full-featured in terms of hardware interface. The documentation for this is here.
Using their class-oriented API allows you to do things like this:
from pypixxlib.viewpixx import VIEWPixx3D
# viewpixx and VIEWPixx3D would need to be replaced by the appropriate devices.
my_device = VIEWPixx3D() # Opens and initiates the device
my_device.setVideoMode(’M16’) # Set the right video mode
my_device.updateRegisterCache() # Update the device
which enables high-bitdepth greyscale mode on a VIEWPixx 3D. VPIXX write:
If you create an object that instantiates a class for a device you have connected, all possible functions attached to the object are guaranteed to work and to be applied on the correct device, assuming the operations are permitted.
That seems simple, but I expect it would then be difficult to pass this to PsychoPy’s Window class in a way that it would understand (e.g. LUT and gamma tables correct, correct passing of bits in special modes). I haven’t checked this yet (not in the lab right now) but I should have more info tomorrow.
There is also a lower-level wrapper module
_libdpx. VPIXX write:
If you are programming for something more permissible or if you do not know which device will be used, you can use the _libdpx Wrapper Module, which does not guarantee the functions will work, but does guarantee all the functions will be called on the correct devices if you provide the appropriate commands.
These decisions aside, it seems to me that using the VPIXX
pypixxlib is probably the best way to interface to the hardware. Then we can rely on VPIXX for maintaining low-level functionality.
A question here: how should I include a dependency to
pypixxlib within PsychoPy? Obviously we don’t want this to be required for all users, but rather we would like the system to check for it if the VPIXX hardware is used. How should I implement that in an
Could someone check my high-level summary of how MonitorCenter is working? My understanding is that you have a monitorCentre GUI, which wraps around the functionality in
calibTools.py. A monitor object is created and saved, that can contain calibration data if run. When an experiment script is run with a monitor name specified, the calibration data and other information is loaded for that monitor, and gamma correction is applied via that.
Does this description differ in any important way for the Bits#? I have read a bit about the difficulty of finding the identity LUT but haven’t examined that carefully yet.
I’m basically hoping to start with a really simple calibration script that would allow me to test high-bitdepth modes, but I want to keep the monitorcenter in mind as an eventual goal for integration.
Hopefully more info later this week.