question re GetImage - drawbuffer vs frontbuffer

1
Hi Mario,

I'm testing my stimuli to see if they behave as expected, and I've noticed something odd. If I read back via GetImage with 'drawBuffer', I get the values I expect, but if I use 'frontBuffer', I appear to get only 8 bits precision (e.g. values between 0 and 1/256 appear as 0). My understanding from the GetImage help is that 'drawBuffer' gives values before they have been processed by the Imaging Pipeline, while 'frontBuffer' gives the values as they actually appear on the screen. So frontBuffer would be the ones I want to get right! Are you aware of a reason why frontBuffer would not work?

Here's an example of what I mean

% Get started:
PsychImaging('PrepareConfiguration');
% I want 32-bit precision:
PsychImaging('AddTask', 'General', 'FloatingPoint32Bit');
% Am using my DATAPixx:
PsychImaging('AddTask', 'General', 'EnableDataPixxM16Output');
% - for testing, don't mess with my numbers!
PsychImaging('AddTask', 'FinalFormatting', 'DisplayColorCorrection', 'ClampOnly');
% Open our window.
w = PsychImaging('OpenWindow', 1,0);
% Fill the whole screen with gray:
Screen('FillRect', w, 0.5); Screen('Flip',w);
% Let's read back what got sent to the GPU:
im=Screen('GetImage',w,[],'drawBuffer',1,1);
% See what's in the middle of the screen (arbitrary location)
im(300,400)
% this returns 0.5000000000000000 as one would hope -- Hurrah!
im=Screen('GetImage',w,[],'frontBuffer',1,1);
im(300,400)
% this returns 0.498039215803146, i.e. it appears to be close to 127/255 -- Boo!

Am I right to be worried by this? It looks to me as if I must inadvertently be telling the imaging pipeline to do something that converts 0.500 into 0.498. But what???

I should add that this is with PTB revision 1799. Normally I would update before posting here, but my Linux machine is currently over in a hospital where it's not allowed to be connected to the network, and I don't have another machine running Centos over here to update and put on a memory stick. So if by any chance this is a known bug that was fixed, I apologise for wasting your time!

Many thanks,

Jenny



--
Jenny C. A. Read
Royal Society University Research Fellow Mobile 0756 151 6988
Institute of Neuroscience Office +44 191 222 7559
Newcastle University, NE2 4HH www.staff.ncl.ac.uk/j.c.a.read
2
--- In psychtoolbox@yahoogroups.com, Jenny Read <j.c.a.read@...> wrote:
>
> Hi Mario,

Hi again,

>
> I'm testing my stimuli to see if they behave as expected, and I've > noticed something odd. If I read back via GetImage with > 'drawBuffer', I get the values I expect, but if I use 'frontBuffer', I appear to get only 8 bits precision (e.g. values between 0 and 1/256 appear as 0). My understanding from the GetImage help is that 'drawBuffer' gives values before they have been processed by the Imaging Pipeline,

Yes. Basically as you painted them.

while 'frontBuffer' gives the values as they actually appear on the screen. So frontBuffer would be the ones I want to get right! Are you aware of a reason why frontBuffer would not work?
>

... not quite. The real transformed content in the framebuffer. These are the values as they are sent through gpu's gamma tables, ditherers and then out of the display connector. In your case, as the gamma tables and ditherer don't have an effect, the values as sent to the Datapixx. These are in the 8 bit RGB pixels in the special encoding required by the Datapixx. The box will decode them into the final values to drive the DAC's. If you read out the frontbuffer as you do below, you'll get the content of the red channel, which encodes the 8 most significant bits of the luminance, but first converted to a float value between 0 and 1. So you end up with what you end up with. If you read out the values as "normal" 8 bit integers and you get the green channel as well, you can undo the transformation:

lum16 = 256 * red + green;
lumf = lum16 / (2^16 - 1);

I think there you should see lumf == 0.5 aka the value in 'drawBuffer', unless you have more post processing enabled, e.g., gamma correction, in which case you'd see the transformed result of drawbuffer.

This is what the BitsPlusImagingPipelineTest script tests: If it inputs a floating point drawbuffer into both the gpu pipeline and into the matlab reference code, do the final results match? For all conceivable 2^16 values? Otherwise the test would fail.

So not much reason to worry, this is expected.

best,
-mario


> Here's an example of what I mean
>
> % Get started:
> PsychImaging('PrepareConfiguration');
> % I want 32-bit precision:
> PsychImaging('AddTask', 'General', 'FloatingPoint32Bit');
> % Am using my DATAPixx:
> PsychImaging('AddTask', 'General', 'EnableDataPixxM16Output');
> % - for testing, don't mess with my numbers!
> PsychImaging('AddTask', 'FinalFormatting', 'DisplayColorCorrection', 'ClampOnly');
> % Open our window.
> w = PsychImaging('OpenWindow', 1,0);
> % Fill the whole screen with gray:
> Screen('FillRect', w, 0.5); Screen('Flip',w);
> % Let's read back what got sent to the GPU:
> im=Screen('GetImage',w,[],'drawBuffer',1,1);
> % See what's in the middle of the screen (arbitrary location)
> im(300,400)
> % this returns 0.5000000000000000 as one would hope -- Hurrah!
> im=Screen('GetImage',w,[],'frontBuffer',1,1);
> im(300,400)
> % this returns 0.498039215803146, i.e. it appears to be close to 127/255 -- Boo!
>
> Am I right to be worried by this? It looks to me as if I must inadvertently be telling the imaging pipeline to do something that converts 0.500 into 0.498. But what???
>
> I should add that this is with PTB revision 1799. Normally I would update before posting here, but my Linux machine is currently over in a hospital where it's not allowed to be connected to the network, and I don't have another machine running Centos over here to update and put on a memory stick. So if by any chance this is a known bug that was fixed, I apologise for wasting your time!
>
> Many thanks,
>
> Jenny
>
>
>
> --
> Jenny C. A. Read
> Royal Society University Research Fellow Mobile 0756 151 6988
> Institute of Neuroscience Office +44 191 222 7559
> Newcastle University, NE2 4HH www.staff.ncl.ac.uk/j.c.a.read
>
3

Hi Mario,

 

Argh! That was spectacularly stupid of me. I do know how the Datapixx works so I have no idea why I suffered such a mental blank there. What a relief though that there’s no horrible problem! OK, have now done im = (255*red + green) / 256 and everything is hunky-dory.

 

Many thanks for rescuing me once again!

 

All the best,

 

Jenny

 

--

Jenny C. A. Read

Royal Society University Research Fellow   Mobile 0756 151 6988

Institute of Neuroscience                  Office +44 191 222 7559

Newcastle University, NE2 4HH           www.staff.ncl.ac.uk/j.c.a.read

 

From: psychtoolbox@yahoogroups.com [mailto:psychtoolbox@yahoogroups.com] On Behalf Of Mario
Sent: 27 October 2010 23:20
To: psychtoolbox@yahoogroups.com
Subject: [psychtoolbox] Re: question re GetImage - drawbuffer vs frontbuffer

 

 



--- In psychtoolbox@yahoogroups.com, Jenny Read <j.c.a.read@...> wrote:

>
> Hi Mario,

Hi again,

>
> I'm testing my stimuli to see if they behave as expected, and I've >
noticed something odd. If I read back via GetImage with > 'drawBuffer', I get the values I expect, but if I use 'frontBuffer', I appear to get only 8 bits precision (e.g. values between 0 and 1/256 appear as 0). My understanding from the GetImage help is that 'drawBuffer' gives values before they have been processed by the Imaging Pipeline,

Yes. Basically as you painted them.

while 'frontBuffer' gives the values as they actually appear on the screen. So frontBuffer would be the ones I want to get right! Are you aware of a reason why frontBuffer would not work?
>

... not quite. The real transformed content in the framebuffer. These are the values as they are sent through gpu's gamma tables, ditherers and then out of the display connector. In your case, as the gamma tables and ditherer don't have an effect, the values as sent to the Datapixx. These are in the 8 bit RGB pixels in the special encoding required by the Datapixx. The box will decode them into the final values to drive the DAC's. If you read out the frontbuffer as you do below, you'll get the content of the red channel, which encodes the 8 most significant bits of the luminance, but first converted to a float value between 0 and 1. So you end up with what you end up with. If you read out the values as "normal" 8 bit integers and you get the green channel as well, you can undo the transformation:

lum16 = 256 * red + green;
lumf = lum16 / (2^16 - 1);

I think there you should see lumf == 0.5 aka the value in 'drawBuffer', unless you have more post processing enabled, e.g., gamma correction, in which case you'd see the transformed result of drawbuffer.

This is what the BitsPlusImagingPipelineTest script tests: If it inputs a floating point drawbuffer into both the gpu pipeline and into the matlab reference code, do the final results match? For all conceivable 2^16 values? Otherwise the test would fail.

So not much reason to worry, this is expected.

best,
-mario

> Here's an example of what I mean
>
> % Get started:
> PsychImaging('PrepareConfiguration');
> % I want 32-bit precision:
> PsychImaging('AddTask', 'General', 'FloatingPoint32Bit');
> % Am using my DATAPixx:
> PsychImaging('AddTask', 'General', 'EnableDataPixxM16Output');
> % - for testing, don't mess with my numbers!
> PsychImaging('AddTask', 'FinalFormatting', 'DisplayColorCorrection',
'ClampOnly');
> % Open our window.
> w = PsychImaging('OpenWindow', 1,0);
> % Fill the whole screen with gray:
> Screen('FillRect', w, 0.5); Screen('Flip',w);
> % Let's read back what got sent to the GPU:
> im=Screen('GetImage',w,[],'drawBuffer',1,1);
> % See what's in the middle of the screen (arbitrary location)
> im(300,400)
> % this returns 0.5000000000000000 as one would hope -- Hurrah!
> im=Screen('GetImage',w,[],'frontBuffer',1,1);
> im(300,400)
> % this returns 0.498039215803146, i.e. it appears to be close to 127/255
-- Boo!
>
> Am I right to be worried by this? It looks to me as if I must
inadvertently be telling the imaging pipeline to do something that converts 0.500 into 0.498. But what???
>
> I should add that this is with PTB revision 1799. Normally I would update
before posting here, but my Linux machine is currently over in a hospital where it's not allowed to be connected to the network, and I don't have another machine running Centos over here to update and put on a memory stick. So if by any chance this is a known bug that was fixed, I apologise for wasting your time!
>
> Many thanks,
>
> Jenny
>
>
>
> --
> Jenny C. A. Read
> Royal Society University Research Fellow Mobile 0756 151 6988
> Institute of Neuroscience Office +44 191 222 7559
> Newcastle University, NE2 4HH
href="http://www.staff.ncl.ac.uk/j.c.a.read">www.staff.ncl.ac.uk/j.c.a.read
>

4
It's good to question things and test carefully. Better than missing a real bug that could be hidden somewhere in the implementation and lurk there for a long time. Even better if you don't find a bug and it increases trust the current implementation ;-)

thanks,
-mario

--- In psychtoolbox@yahoogroups.com, Jenny Read <j.c.a.read@...> wrote:
>
> Hi Mario,
>
> Argh! That was spectacularly stupid of me. I do know how the Datapixx works so I have no idea why I suffered such a mental blank there. What a relief though that there's no horrible problem! OK, have now done im = (255*red + green) / 256 and everything is hunky-dory.
>
> Many thanks for rescuing me once again!
>
> All the best,
>
> Jenny
>
> --
> Jenny C. A. Read
> Royal Society University Research Fellow Mobile 0756 151 6988
> Institute of Neuroscience Office +44 191 222 7559
> Newcastle University, NE2 4HH www.staff.ncl.ac.uk/j.c.a.read<http://www.staff.ncl.ac.uk/j.c.a.read>
>
> From: psychtoolbox@yahoogroups.com<mailto:psychtoolbox@yahoogroups.com> [mailto:psychtoolbox@yahoogroups.com]<mailto:[mailto:psychtoolbox@yahoogroups.com]> On Behalf Of Mario
> Sent: 27 October 2010 23:20
> To: psychtoolbox@yahoogroups.com<mailto:psychtoolbox@yahoogroups.com>
> Subject: [psychtoolbox] Re: question re GetImage - drawbuffer vs frontbuffer
>
>
>
>
> --- In psychtoolbox@yahoogroups.com<mailto:psychtoolbox%40yahoogroups.com>, Jenny Read <j.c.a.read@<mailto:j.c.a.read@>> wrote:
> >
> > Hi Mario,
>
> Hi again,
>
> >
> > I'm testing my stimuli to see if they behave as expected, and I've > noticed something odd. If I read back via GetImage with > 'drawBuffer', I get the values I expect, but if I use 'frontBuffer', I appear to get only 8 bits precision (e.g. values between 0 and 1/256 appear as 0). My understanding from the GetImage help is that 'drawBuffer' gives values before they have been processed by the Imaging Pipeline,
>
> Yes. Basically as you painted them.
>
> while 'frontBuffer' gives the values as they actually appear on the screen. So frontBuffer would be the ones I want to get right! Are you aware of a reason why frontBuffer would not work?
> >
>
> ... not quite. The real transformed content in the framebuffer. These are the values as they are sent through gpu's gamma tables, ditherers and then out of the display connector. In your case, as the gamma tables and ditherer don't have an effect, the values as sent to the Datapixx. These are in the 8 bit RGB pixels in the special encoding required by the Datapixx. The box will decode them into the final values to drive the DAC's. If you read out the frontbuffer as you do below, you'll get the content of the red channel, which encodes the 8 most significant bits of the luminance, but first converted to a float value between 0 and 1. So you end up with what you end up with. If you read out the values as "normal" 8 bit integers and you get the green channel as well, you can undo the transformation:
>
> lum16 = 256 * red + green;
> lumf = lum16 / (2^16 - 1);
>
> I think there you should see lumf == 0.5 aka the value in 'drawBuffer', unless you have more post processing enabled, e.g., gamma correction, in which case you'd see the transformed result of drawbuffer.
>
> This is what the BitsPlusImagingPipelineTest script tests: If it inputs a floating point drawbuffer into both the gpu pipeline and into the matlab reference code, do the final results match? For all conceivable 2^16 values? Otherwise the test would fail.
>
> So not much reason to worry, this is expected.
>
> best,
> -mario
>
> > Here's an example of what I mean
> >
> > % Get started:
> > PsychImaging('PrepareConfiguration');
> > % I want 32-bit precision:
> > PsychImaging('AddTask', 'General', 'FloatingPoint32Bit');
> > % Am using my DATAPixx:
> > PsychImaging('AddTask', 'General', 'EnableDataPixxM16Output');
> > % - for testing, don't mess with my numbers!
> > PsychImaging('AddTask', 'FinalFormatting', 'DisplayColorCorrection', 'ClampOnly');
> > % Open our window.
> > w = PsychImaging('OpenWindow', 1,0);
> > % Fill the whole screen with gray:
> > Screen('FillRect', w, 0.5); Screen('Flip',w);
> > % Let's read back what got sent to the GPU:
> > im=Screen('GetImage',w,[],'drawBuffer',1,1);
> > % See what's in the middle of the screen (arbitrary location)
> > im(300,400)
> > % this returns 0.5000000000000000 as one would hope -- Hurrah!
> > im=Screen('GetImage',w,[],'frontBuffer',1,1);
> > im(300,400)
> > % this returns 0.498039215803146, i.e. it appears to be close to 127/255 -- Boo!
> >
> > Am I right to be worried by this? It looks to me as if I must inadvertently be telling the imaging pipeline to do something that converts 0.500 into 0.498. But what???
> >
> > I should add that this is with PTB revision 1799. Normally I would update before posting here, but my Linux machine is currently over in a hospital where it's not allowed to be connected to the network, and I don't have another machine running Centos over here to update and put on a memory stick. So if by any chance this is a known bug that was fixed, I apologise for wasting your time!
> >
> > Many thanks,
> >
> > Jenny
> >
> >
> >
> > --
> > Jenny C. A. Read
> > Royal Society University Research Fellow Mobile 0756 151 6988
> > Institute of Neuroscience Office +44 191 222 7559
> > Newcastle University, NE2 4HH www.staff.ncl.ac.uk/j.c.a.read<http://www.staff.ncl.ac.uk/j.c.a.read>
> >
>