Matrox MED3mp-DVI¶

In our vision lab we have a special monitor: The EIZO Radiforce GS320. This monochrome (black-and-white) monitor was especially designed for medical (X-ray) diagnostics. We bought the recommended graphics card: Matrox MED3mp-DVI for this monitor, but were not able to measure 1024 shades of gray.

After collecting some data we found a rather persistent tendency for subjects to judge stimuli presented on the left brighter than stimuli presented on the right. At first we were convinced that the luminance of the monitor was inhomogeneous. After several days of measurements and all kinds of tests it became obvious that even if the photometer might not measure the exact same luminance at every given point, there is just no way that this should be perceivable by subjects (differences of about \(0.3\,\frac{\mathrm{cd}}{\mathrm{m}^2}\) for stimuli of \(50\,\frac{\mathrm{cd}}{\mathrm{m}^2}\)).

We then noticed a kind of weird ‘blinking’ when stimuli vanished after their presentation. It became obvious that the vertical retrace was not synchronized. Here is a video that shows what you see when you switch between black and white screens quickly. (This is a test implemented in the psychtoolbox for MATLAB by Mario Kleiner. Very useful.)

After some diagnoses we realized that the OpenGL standard supported by our Matrox graphics card was 1.3. Psychopy (which we use to present our stimuli) needs (at least) OpenGL 2.0 to run properly. This is the reason why the vertical blank (or retrace) of our monitor was not synchronized with the display. The graphics card is only able to handle static pictures. We were also not able to get 10 bits (1024 gray tones) with this graphics card. Of course, the above mentioned distortions when presenting stimuli are even worse.

NVidia FX 1800¶

We bought a new graphics card: NVidia Quadro FX 1800.

Right after setting it up and installing the drivers the first problems emerged (of course). The graphics card was able to see both monitors just fine: the EIZO GS320 for stimulus presentation and a monitor used to start experiments and do our programming on. However, it recognized the native resolution for our EIZO monitor as \(1024\times 1536\) when it really was \(2048\times 1536\). The effect was that the monitor was split into two screens. They showed exactly the same thing except that the right half was a lot darker. The solution was to open up the monitor dialogue. (Not the regular dialogue box that changes brightness etc. but the one that changes monitor settings like data format and orientation—coincidentally found in the manual: Press the on/off button, keep it pressed and then press mode. This opens the dialogue box.) We switched the data format from packed pixel to standard. This made one side of the split monitor disappear and after a restart the graphics card finally recognized the native resolution as \(2048\times 1536\). Now we measured the depth of the monitor and could again only get 256 shades of gray (8 bits as opposed to the promised 10 bits). After some more research we realized that for getting the full 10 bit we definitely needed the packed pixel format. The graphics card supports packed pixel. We made sure of that before we bought it. But the screen was still split into two whenever we switched from standard to packed pixel.

With the packed pixel format we actually manage to get 10 bits, but we have to use a work around while presenting the stimuli. After some more research and a chat with one of our technicians and some coincidental playing around with the color settings, we realized that the left half of the screen used 8 bits of the green color channel + 2 bits from the blue color channel. The right side of the screen uses 8 bits of the red color channel + 2 bits of the blue color channel.

We can now present stimuli on the left and the right side of the monitor that have the exact same shade of gray by handing over a color triple to the graphics card that consists of (r,g,b); e.g. (250,250,16). The next section describes what we did to actually find the missing 2 blue bits.

The monitor now runs with a resolution of \(1024\times 1536\) and \(60\,\mathrm{Hz}\) refresh rate (\(\sim 16.7\,\mathrm{ms}\) duration of one frame).

How We Found the Missing 2 Bits¶

In order to find the last two bits, we measured the eight different colors with our photometer once on the right side of the monitor and once on the left side of the monitor and plotted the results (color against luminance). The resulting plots revealed the missing two bits. For the left side they were stored in the 5th and 6th bit of the blue channel and for the right side in the 1st and 2nd bit of the blue channel.

To encode a color for the use in our experiments we wrote a small python module which contains an encoding function:

>>> def encode_color(grey_left, grey_right):
>>>    """
>>>    encodes two grey values from two corresponding pixels in
>>>    one color value.
>>>    """
>>>    # store most significant bits of grey_left in green
>>>    green = np.uint8(grey_left/4)
>>>    # store most significant bits of grey_right in red
>>>    red = np.uint8(grey_right/4)
>>>    # store least significant two bits in correct blue bits
>>>    # for left it has to be in the 5th and 6th bit
>>>    # for right it has to be in the 1st and 2nd bit
>>>    blue = np.uint8((grey_left % 4)*16 + (grey_right % 4)*1)
>>>    return( (green, red, blue) )