Swap Screen back'n'forth

1
Hello,

in order to achieve an increase of my monitors black level, I am presenting my stimulus screen and a white screen in a frame-to-frame alternating method on a 150Hz display.
It works quite well for most of the time and I achieve a stable looking 75Hz display. But from time to time I get a flash on the screen, which probably indicates, that timing went wrong at that incident.

Question: Is there a built-in-function, which supports such a procedure? Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP), does anybody have an idea, how I could get rid of the (rare) flashes?

I was scanning the psychtoolbox forum, but couldn't find a hint, why my system does not run my script 'smooth'. VBLSyncTest.m does report a good timing in single-display mode. You can find my code attached below. It's really not a very sophisticated realization of what I want from my computer, so I am happy for any hint, how this can be done well.

Thanks in advance!
Markus

------------------
% Find out how many screens and use largest screen number.
whichScreen = max(Screen('Screens'));

PsychImaging('PrepareConfiguration');
PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
[window winRect] = PsychImaging('OpenWindow', whichScreen);
Screen('FillRect',window,0);
lacer = 0;
Priority(2);
for i=128:64:256
resp = 0;
while ~KbCheck
switch lacer
case 1
Screen('FillRect',window,255);
case 2
Screen('FillRect',window,0);
Screen('FillRect',window,i,[500 300 800 600]);
end
Screen('DrawingFinished', window);
lacer = mod(lacer,2)+1;
Screen('Flip',window);
end
while KbCheck
switch lacer
case 1
Screen('FillRect',window,255);
case 2
Screen('FillRect',window,0);
end
Screen('DrawingFinished', window);
lacer = mod(lacer,2)+1;
Screen('Flip',window);
end
end
cls
-----------------------------
2
How can you increase the black level of a monitor by this method? And why? What's the purpose?

-mario

--- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@...> wrote:
>
> Hello,
>
> in order to achieve an increase of my monitors black level, I am presenting my stimulus screen and a white screen in a frame-to-frame alternating method on a 150Hz display.
> It works quite well for most of the time and I achieve a stable looking 75Hz display. But from time to time I get a flash on the screen, which probably indicates, that timing went wrong at that incident.
>
> Question: Is there a built-in-function, which supports such a procedure? Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP), does anybody have an idea, how I could get rid of the (rare) flashes?
>
> I was scanning the psychtoolbox forum, but couldn't find a hint, why my system does not run my script 'smooth'. VBLSyncTest.m does report a good timing in single-display mode. You can find my code attached below. It's really not a very sophisticated realization of what I want from my computer, so I am happy for any hint, how this can be done well.
>
> Thanks in advance!
> Markus
>
> ------------------
> % Find out how many screens and use largest screen number.
> whichScreen = max(Screen('Screens'));
>
> PsychImaging('PrepareConfiguration');
> PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
> [window winRect] = PsychImaging('OpenWindow', whichScreen);
> Screen('FillRect',window,0);
> lacer = 0;
> Priority(2);
> for i=128:64:256
> resp = 0;
> while ~KbCheck
> switch lacer
> case 1
> Screen('FillRect',window,255);
> case 2
> Screen('FillRect',window,0);
> Screen('FillRect',window,i,[500 300 800 600]);
> end
> Screen('DrawingFinished', window);
> lacer = mod(lacer,2)+1;
> Screen('Flip',window);
> end
> while KbCheck
> switch lacer
> case 1
> Screen('FillRect',window,255);
> case 2
> Screen('FillRect',window,0);
> end
> Screen('DrawingFinished', window);
> lacer = mod(lacer,2)+1;
> Screen('Flip',window);
> end
> end
> cls
> -----------------------------
>
3
PTB doesn't have a dedicated function for what you want, but on OS/X (or Windows if you have an expensive pro graphics card) you could abuse frame-sequential stereomode, as demonstrated by StereoDemo(1), to do this for you -- Reliable automatic flipping between two images at video refresh rate.

Wrt. to your script there's bits of headroom for optimization:

0. Quit any unneeded applications/virus scanners/software updtes/indexing services etc. Disconnect from the network and unneccessary devices. Disable secondary displays if any (single monitor mode).
1. Make sure its a function, not a script.
2. Use the Priority() command to enable realtime priority.
3. Try setting the dontclear flag of Screen('Flip') to a value of 2. then 'flip' will flip forth and back between the front- and backbuffer without clearing to background color inbetween. Fill one buffer with white, flip, fill other buffer with stimulus, flip. then repeat flip's infinitely withour redrawing anything.
4. Screen('Drawingfinished') won't help nor hurt in this case.
5. Don't use PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');

This will add processing overhead of maybe 1 msec or so, which is normally irrelevant, but maybe not insignificant if your whole video refresh cycle is only 6.6 msecs.

On a modern graphics card in combination with some high precision display device like a Video attenuator, the VideoSwitcher or a Bits+ box or similar devices, or even in PseudoGray mode (aka "bitstealing"), that function can provide a large increase in output precision. The AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a large number of output devices/mode we support, as well as color correction/gamma correction and other applications.

The way you use it, it won't help - it doesn't have any benefit for your specific stimulus and you'll end up with a 8 bit framebuffer image. It will just add a bit of extra processing time.

In general, OS/X and Linux have way better realtime timing behaviour than Windows when every millisecond counts. Still your approach doesn't sound like a reliable way of achieving whatever you want to achieve.

But i still fail to see the idea behind this "increasing the blacklevel"? Is this something extraordinary clever i've never heard about? Or the wrong way to get more precision?

Please enlighten me,
-mario


--- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@...> wrote:
>
> How can you increase the black level of a monitor by this method? And why? What's the purpose?
>
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@> wrote:
> >
> > Hello,
> >
> > in order to achieve an increase of my monitors black level, I am presenting my stimulus screen and a white screen in a frame-to-frame alternating method on a 150Hz display.
> > It works quite well for most of the time and I achieve a stable looking 75Hz display. But from time to time I get a flash on the screen, which probably indicates, that timing went wrong at that incident.
> >
> > Question: Is there a built-in-function, which supports such a procedure? Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP), does anybody have an idea, how I could get rid of the (rare) flashes?
> >
> > I was scanning the psychtoolbox forum, but couldn't find a hint, why my system does not run my script 'smooth'. VBLSyncTest.m does report a good timing in single-display mode. You can find my code attached below. It's really not a very sophisticated realization of what I want from my computer, so I am happy for any hint, how this can be done well.
> >
> > Thanks in advance!
> > Markus
> >
> > ------------------
> > % Find out how many screens and use largest screen number.
> > whichScreen = max(Screen('Screens'));
> >
> > PsychImaging('PrepareConfiguration');
> > PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
> > [window winRect] = PsychImaging('OpenWindow', whichScreen);
> > Screen('FillRect',window,0);
> > lacer = 0;
> > Priority(2);
> > for i=128:64:256
> > resp = 0;
> > while ~KbCheck
> > switch lacer
> > case 1
> > Screen('FillRect',window,255);
> > case 2
> > Screen('FillRect',window,0);
> > Screen('FillRect',window,i,[500 300 800 600]);
> > end
> > Screen('DrawingFinished', window);
> > lacer = mod(lacer,2)+1;
> > Screen('Flip',window);
> > end
> > while KbCheck
> > switch lacer
> > case 1
> > Screen('FillRect',window,255);
> > case 2
> > Screen('FillRect',window,0);
> > end
> > Screen('DrawingFinished', window);
> > lacer = mod(lacer,2)+1;
> > Screen('Flip',window);
> > end
> > end
> > cls
> > -----------------------------
> >
>
4
Hi Mario,

Quick questions on on eof your pieces of advice: why does making the
script a function (simply adding a function declaration with no input
arguments atop the script i presume) improve performance?

Thanks for the extra bit of understanding!

Dee

On Sun, Jul 5, 2009 at 11:59 AM, Mario
Kleiner<mario.kleiner@...> wrote:
>
>
> PTB doesn't have a dedicated function for what you want, but on OS/X (or
> Windows if you have an expensive pro graphics card) you could abuse
> frame-sequential stereomode, as demonstrated by StereoDemo(1), to do this
> for you -- Reliable automatic flipping between two images at video refresh
> rate.
>
> Wrt. to your script there's bits of headroom for optimization:
>
> 0. Quit any unneeded applications/virus scanners/software updtes/indexing
> services etc. Disconnect from the network and unneccessary devices. Disable
> secondary displays if any (single monitor mode).
> 1. Make sure its a function, not a script.
> 2. Use the Priority() command to enable realtime priority.
> 3. Try setting the dontclear flag of Screen('Flip') to a value of 2. then
> 'flip' will flip forth and back between the front- and backbuffer without
> clearing to background color inbetween. Fill one buffer with white, flip,
> fill other buffer with stimulus, flip. then repeat flip's infinitely withour
> redrawing anything.
> 4. Screen('Drawingfinished') won't help nor hurt in this case.
> 5. Don't use PsychImaging('AddTask', 'General',
> 'FloatingPoint32BitIfPossible');
>
> This will add processing overhead of maybe 1 msec or so, which is normally
> irrelevant, but maybe not insignificant if your whole video refresh cycle is
> only 6.6 msecs.
>
> On a modern graphics card in combination with some high precision display
> device like a Video attenuator, the VideoSwitcher or a Bits+ box or similar
> devices, or even in PseudoGray mode (aka "bitstealing"), that function can
> provide a large increase in output precision. The
> AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a large
> number of output devices/mode we support, as well as color correction/gamma
> correction and other applications.
>
> The way you use it, it won't help - it doesn't have any benefit for your
> specific stimulus and you'll end up with a 8 bit framebuffer image. It will
> just add a bit of extra processing time.
>
> In general, OS/X and Linux have way better realtime timing behaviour than
> Windows when every millisecond counts. Still your approach doesn't sound
> like a reliable way of achieving whatever you want to achieve.
>
> But i still fail to see the idea behind this "increasing the blacklevel"? Is
> this something extraordinary clever i've never heard about? Or the wrong way
> to get more precision?
>
> Please enlighten me,
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@...>
> wrote:
>>
>> How can you increase the black level of a monitor by this method? And why?
>> What's the purpose?
>>
>> -mario
>>
>> --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@> wrote:
>> >
>> > Hello,
>> >
>> > in order to achieve an increase of my monitors black level, I am
>> > presenting my stimulus screen and a white screen in a frame-to-frame
>> > alternating method on a 150Hz display.
>> > It works quite well for most of the time and I achieve a stable looking
>> > 75Hz display. But from time to time I get a flash on the screen, which
>> > probably indicates, that timing went wrong at that incident.
>> >
>> > Question: Is there a built-in-function, which supports such a procedure?
>> > Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP),
>> > does anybody have an idea, how I could get rid of the (rare) flashes?
>> >
>> > I was scanning the psychtoolbox forum, but couldn't find a hint, why my
>> > system does not run my script 'smooth'. VBLSyncTest.m does report a good
>> > timing in single-display mode. You can find my code attached below. It's
>> > really not a very sophisticated realization of what I want from my computer,
>> > so I am happy for any hint, how this can be done well.
>> >
>> > Thanks in advance!
>> > Markus
>> >
>> > ------------------
>> > % Find out how many screens and use largest screen number.
>> > whichScreen = max(Screen('Screens'));
>> >
>> > PsychImaging('PrepareConfiguration');
>> > PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
>> > [window winRect] = PsychImaging('OpenWindow', whichScreen);
>> > Screen('FillRect',window,0);
>> > lacer = 0;
>> > Priority(2);
>> > for i=128:64:256
>> > resp = 0;
>> > while ~KbCheck
>> > switch lacer
>> > case 1
>> > Screen('FillRect',window,255);
>> > case 2
>> > Screen('FillRect',window,0);
>> > Screen('FillRect',window,i,[500 300 800 600]);
>> > end
>> > Screen('DrawingFinished', window);
>> > lacer = mod(lacer,2)+1;
>> > Screen('Flip',window);
>> > end
>> > while KbCheck
>> > switch lacer
>> > case 1
>> > Screen('FillRect',window,255);
>> > case 2
>> > Screen('FillRect',window,0);
>> > end
>> > Screen('DrawingFinished', window);
>> > lacer = mod(lacer,2)+1;
>> > Screen('Flip',window);
>> > end
>> > end
>> > cls
>> > -----------------------------
>> >
>>
>
>
5
Because Mathwork says so :-)

If a script is a script then Matlab reparses and interprets each statement again when its executed and no optimizations are applied. It is as if you type commands into the matlab window, just typing very fast.

functions are precompiled and optimized by Matlab's JIT compiler at load time, and during execution, so they are faster. One problem of dynamic optimization at runtime ("hot spot optimization") is that loops in your code may execute slower during the first few iterations than in the remaining iterations, because they are optimized during runtime. This is beautiful for most applications, but can create headaches for benchmarking and deterministic timing. The other problem is the lack of documentation and control about this features. The strategies apparently change with each new matlab release, as new optimization features are added under the hood.

This JIT mechanism is what gives Matlab a speed advantage over Octave for poorly written code, whereas there's basically no difference for well written code in most cases. For maximum performance and most deterministic timing it is best to optimize your code yourself as described in Mathworks documentation, so the JIT has to do less guesswork and runtime optimization and you'll get better performance/timing from the start. And of course use ptb's timing functions wisely to immunize your code against such behaviours as much as possible.

-mario



--- In psychtoolbox@yahoogroups.com, "Diederick C. Niehorster" <dcnieho@...> wrote:
>
> Hi Mario,
>
> Quick questions on on eof your pieces of advice: why does making the
> script a function (simply adding a function declaration with no input
> arguments atop the script i presume) improve performance?
>
> Thanks for the extra bit of understanding!
>
> Dee
>
> On Sun, Jul 5, 2009 at 11:59 AM, Mario
> Kleiner<mario.kleiner@...> wrote:
> >
> >
> > PTB doesn't have a dedicated function for what you want, but on OS/X (or
> > Windows if you have an expensive pro graphics card) you could abuse
> > frame-sequential stereomode, as demonstrated by StereoDemo(1), to do this
> > for you -- Reliable automatic flipping between two images at video refresh
> > rate.
> >
> > Wrt. to your script there's bits of headroom for optimization:
> >
> > 0. Quit any unneeded applications/virus scanners/software updtes/indexing
> > services etc. Disconnect from the network and unneccessary devices. Disable
> > secondary displays if any (single monitor mode).
> > 1. Make sure its a function, not a script.
> > 2. Use the Priority() command to enable realtime priority.
> > 3. Try setting the dontclear flag of Screen('Flip') to a value of 2. then
> > 'flip' will flip forth and back between the front- and backbuffer without
> > clearing to background color inbetween. Fill one buffer with white, flip,
> > fill other buffer with stimulus, flip. then repeat flip's infinitely withour
> > redrawing anything.
> > 4. Screen('Drawingfinished') won't help nor hurt in this case.
> > 5. Don't use PsychImaging('AddTask', 'General',
> > 'FloatingPoint32BitIfPossible');
> >
> > This will add processing overhead of maybe 1 msec or so, which is normally
> > irrelevant, but maybe not insignificant if your whole video refresh cycle is
> > only 6.6 msecs.
> >
> > On a modern graphics card in combination with some high precision display
> > device like a Video attenuator, the VideoSwitcher or a Bits+ box or similar
> > devices, or even in PseudoGray mode (aka "bitstealing"), that function can
> > provide a large increase in output precision. The
> > AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a large
> > number of output devices/mode we support, as well as color correction/gamma
> > correction and other applications.
> >
> > The way you use it, it won't help - it doesn't have any benefit for your
> > specific stimulus and you'll end up with a 8 bit framebuffer image. It will
> > just add a bit of extra processing time.
> >
> > In general, OS/X and Linux have way better realtime timing behaviour than
> > Windows when every millisecond counts. Still your approach doesn't sound
> > like a reliable way of achieving whatever you want to achieve.
> >
> > But i still fail to see the idea behind this "increasing the blacklevel"? Is
> > this something extraordinary clever i've never heard about? Or the wrong way
> > to get more precision?
> >
> > Please enlighten me,
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@>
> > wrote:
> >>
> >> How can you increase the black level of a monitor by this method? And why?
> >> What's the purpose?
> >>
> >> -mario
> >>
> >> --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@> wrote:
> >> >
> >> > Hello,
> >> >
> >> > in order to achieve an increase of my monitors black level, I am
> >> > presenting my stimulus screen and a white screen in a frame-to-frame
> >> > alternating method on a 150Hz display.
> >> > It works quite well for most of the time and I achieve a stable looking
> >> > 75Hz display. But from time to time I get a flash on the screen, which
> >> > probably indicates, that timing went wrong at that incident.
> >> >
> >> > Question: Is there a built-in-function, which supports such a procedure?
> >> > Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP),
> >> > does anybody have an idea, how I could get rid of the (rare) flashes?
> >> >
> >> > I was scanning the psychtoolbox forum, but couldn't find a hint, why my
> >> > system does not run my script 'smooth'. VBLSyncTest.m does report a good
> >> > timing in single-display mode. You can find my code attached below. It's
> >> > really not a very sophisticated realization of what I want from my computer,
> >> > so I am happy for any hint, how this can be done well.
> >> >
> >> > Thanks in advance!
> >> > Markus
> >> >
> >> > ------------------
> >> > % Find out how many screens and use largest screen number.
> >> > whichScreen = max(Screen('Screens'));
> >> >
> >> > PsychImaging('PrepareConfiguration');
> >> > PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
> >> > [window winRect] = PsychImaging('OpenWindow', whichScreen);
> >> > Screen('FillRect',window,0);
> >> > lacer = 0;
> >> > Priority(2);
> >> > for i=128:64:256
> >> > resp = 0;
> >> > while ~KbCheck
> >> > switch lacer
> >> > case 1
> >> > Screen('FillRect',window,255);
> >> > case 2
> >> > Screen('FillRect',window,0);
> >> > Screen('FillRect',window,i,[500 300 800 600]);
> >> > end
> >> > Screen('DrawingFinished', window);
> >> > lacer = mod(lacer,2)+1;
> >> > Screen('Flip',window);
> >> > end
> >> > while KbCheck
> >> > switch lacer
> >> > case 1
> >> > Screen('FillRect',window,255);
> >> > case 2
> >> > Screen('FillRect',window,0);
> >> > end
> >> > Screen('DrawingFinished', window);
> >> > lacer = mod(lacer,2)+1;
> >> > Screen('Flip',window);
> >> > end
> >> > end
> >> > cls
> >> > -----------------------------
> >> >
> >>
> >
> >
>
6
Hi Mario,

Thank you for your clear reply.
Not that i've checked if it exists, but if not: there should be a
section on the wiki where this kind of threads with useful knowledge
and tips are linked to with a one-line descriptor. Ideally, more
people will then find them and average code quality would go up a bit.

Idea?

Best,
Dee

On Mon, Jul 6, 2009 at 5:04 AM, Mario
Kleiner<mario.kleiner@...> wrote:
>
>
> Because Mathwork says so :-)
>
> If a script is a script then Matlab reparses and interprets each statement
> again when its executed and no optimizations are applied. It is as if you
> type commands into the matlab window, just typing very fast.
>
> functions are precompiled and optimized by Matlab's JIT compiler at load
> time, and during execution, so they are faster. One problem of dynamic
> optimization at runtime ("hot spot optimization") is that loops in your code
> may execute slower during the first few iterations than in the remaining
> iterations, because they are optimized during runtime. This is beautiful for
> most applications, but can create headaches for benchmarking and
> deterministic timing. The other problem is the lack of documentation and
> control about this features. The strategies apparently change with each new
> matlab release, as new optimization features are added under the hood.
>
> This JIT mechanism is what gives Matlab a speed advantage over Octave for
> poorly written code, whereas there's basically no difference for well
> written code in most cases. For maximum performance and most deterministic
> timing it is best to optimize your code yourself as described in Mathworks
> documentation, so the JIT has to do less guesswork and runtime optimization
> and you'll get better performance/timing from the start. And of course use
> ptb's timing functions wisely to immunize your code against such behaviours
> as much as possible.
>
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Diederick C. Niehorster" <dcnieho@...>
> wrote:
>>
>> Hi Mario,
>>
>> Quick questions on on eof your pieces of advice: why does making the
>> script a function (simply adding a function declaration with no input
>> arguments atop the script i presume) improve performance?
>>
>> Thanks for the extra bit of understanding!
>>
>> Dee
>>
>> On Sun, Jul 5, 2009 at 11:59 AM, Mario
>> Kleiner<mario.kleiner@...> wrote:
>> >
>> >
>> > PTB doesn't have a dedicated function for what you want, but on OS/X (or
>> > Windows if you have an expensive pro graphics card) you could abuse
>> > frame-sequential stereomode, as demonstrated by StereoDemo(1), to do
>> > this
>> > for you -- Reliable automatic flipping between two images at video
>> > refresh
>> > rate.
>> >
>> > Wrt. to your script there's bits of headroom for optimization:
>> >
>> > 0. Quit any unneeded applications/virus scanners/software
>> > updtes/indexing
>> > services etc. Disconnect from the network and unneccessary devices.
>> > Disable
>> > secondary displays if any (single monitor mode).
>> > 1. Make sure its a function, not a script.
>> > 2. Use the Priority() command to enable realtime priority.
>> > 3. Try setting the dontclear flag of Screen('Flip') to a value of 2.
>> > then
>> > 'flip' will flip forth and back between the front- and backbuffer
>> > without
>> > clearing to background color inbetween. Fill one buffer with white,
>> > flip,
>> > fill other buffer with stimulus, flip. then repeat flip's infinitely
>> > withour
>> > redrawing anything.
>> > 4. Screen('Drawingfinished') won't help nor hurt in this case.
>> > 5. Don't use PsychImaging('AddTask', 'General',
>> > 'FloatingPoint32BitIfPossible');
>> >
>> > This will add processing overhead of maybe 1 msec or so, which is
>> > normally
>> > irrelevant, but maybe not insignificant if your whole video refresh
>> > cycle is
>> > only 6.6 msecs.
>> >
>> > On a modern graphics card in combination with some high precision
>> > display
>> > device like a Video attenuator, the VideoSwitcher or a Bits+ box or
>> > similar
>> > devices, or even in PseudoGray mode (aka "bitstealing"), that function
>> > can
>> > provide a large increase in output precision. The
>> > AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a large
>> > number of output devices/mode we support, as well as color
>> > correction/gamma
>> > correction and other applications.
>> >
>> > The way you use it, it won't help - it doesn't have any benefit for your
>> > specific stimulus and you'll end up with a 8 bit framebuffer image. It
>> > will
>> > just add a bit of extra processing time.
>> >
>> > In general, OS/X and Linux have way better realtime timing behaviour
>> > than
>> > Windows when every millisecond counts. Still your approach doesn't sound
>> > like a reliable way of achieving whatever you want to achieve.
>> >
>> > But i still fail to see the idea behind this "increasing the
>> > blacklevel"? Is
>> > this something extraordinary clever i've never heard about? Or the wrong
>> > way
>> > to get more precision?
>> >
>> > Please enlighten me,
>> > -mario
>> >
>> > --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@>
>> > wrote:
>> >>
>> >> How can you increase the black level of a monitor by this method? And
>> >> why?
>> >> What's the purpose?
>> >>
>> >> -mario
>> >>
>> >> --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@>
>> >> wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > in order to achieve an increase of my monitors black level, I am
>> >> > presenting my stimulus screen and a white screen in a frame-to-frame
>> >> > alternating method on a 150Hz display.
>> >> > It works quite well for most of the time and I achieve a stable
>> >> > looking
>> >> > 75Hz display. But from time to time I get a flash on the screen,
>> >> > which
>> >> > probably indicates, that timing went wrong at that incident.
>> >> >
>> >> > Question: Is there a built-in-function, which supports such a
>> >> > procedure?
>> >> > Other than getting a faster GPU/CPU or maybe switching the OS(I use
>> >> > WinXP),
>> >> > does anybody have an idea, how I could get rid of the (rare) flashes?
>> >> >
>> >> > I was scanning the psychtoolbox forum, but couldn't find a hint, why
>> >> > my
>> >> > system does not run my script 'smooth'. VBLSyncTest.m does report a
>> >> > good
>> >> > timing in single-display mode. You can find my code attached below.
>> >> > It's
>> >> > really not a very sophisticated realization of what I want from my
>> >> > computer,
>> >> > so I am happy for any hint, how this can be done well.
>> >> >
>> >> > Thanks in advance!
>> >> > Markus
>> >> >
>> >> > ------------------
>> >> > % Find out how many screens and use largest screen number.
>> >> > whichScreen = max(Screen('Screens'));
>> >> >
>> >> > PsychImaging('PrepareConfiguration');
>> >> > PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
>> >> > [window winRect] = PsychImaging('OpenWindow', whichScreen);
>> >> > Screen('FillRect',window,0);
>> >> > lacer = 0;
>> >> > Priority(2);
>> >> > for i=128:64:256
>> >> > resp = 0;
>> >> > while ~KbCheck
>> >> > switch lacer
>> >> > case 1
>> >> > Screen('FillRect',window,255);
>> >> > case 2
>> >> > Screen('FillRect',window,0);
>> >> > Screen('FillRect',window,i,[500 300 800 600]);
>> >> > end
>> >> > Screen('DrawingFinished', window);
>> >> > lacer = mod(lacer,2)+1;
>> >> > Screen('Flip',window);
>> >> > end
>> >> > while KbCheck
>> >> > switch lacer
>> >> > case 1
>> >> > Screen('FillRect',window,255);
>> >> > case 2
>> >> > Screen('FillRect',window,0);
>> >> > end
>> >> > Screen('DrawingFinished', window);
>> >> > lacer = mod(lacer,2)+1;
>> >> > Screen('Flip',window);
>> >> > end
>> >> > end
>> >> > cls
>> >> > -----------------------------
>> >> >
>> >>
>> >
>> >
>>
>
>
7
Hi Mario,

And done. I posted your message almost verbatim (it was good quality
and needed no context) in the relevant section, and made a section
with some links to a few good information sources.

http://www.psychtoolbox.org/wikka.php?wakka=FaqPerformanceTuning1

Best,
Dee

On Mon, Jul 6, 2009 at 10:50 AM, Mario
Kleiner<mario.kleiner@...> wrote:
>
>
> Hi Diederick
>
> Indeed, that was roughly the idea in having a user edittable Wiki, as
> described in the intro to the forum
> <http://psychtoolbox.org/wikka.php?wakka=PsychtoolboxForum>: That users who
> find answers/info useful will clean up and place that content on the Wiki in
> a more organized form. E.g., the FAQ section or Tutorial section. There's
> e.g., a FAQ entry about code optimization which one could extend.
>
> So i guess you just volunteered, right?
>
> cheers,
>
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Diederick C. Niehorster" <dcnieho@...>
> wrote:
>>
>> Hi Mario,
>>
>> Thank you for your clear reply.
>> Not that i've checked if it exists, but if not: there should be a
>> section on the wiki where this kind of threads with useful knowledge
>> and tips are linked to with a one-line descriptor. Ideally, more
>> people will then find them and average code quality would go up a bit.
>>
>> Idea?
>>
>> Best,
>> Dee
>>
>> On Mon, Jul 6, 2009 at 5:04 AM, Mario
>> Kleiner<mario.kleiner@...> wrote:
>> >
>> >
>> > Because Mathwork says so :-)
>> >
>> > If a script is a script then Matlab reparses and interprets each
>> > statement
>> > again when its executed and no optimizations are applied. It is as if
>> > you
>> > type commands into the matlab window, just typing very fast.
>> >
>> > functions are precompiled and optimized by Matlab's JIT compiler at load
>> > time, and during execution, so they are faster. One problem of dynamic
>> > optimization at runtime ("hot spot optimization") is that loops in your
>> > code
>> > may execute slower during the first few iterations than in the remaining
>> > iterations, because they are optimized during runtime. This is beautiful
>> > for
>> > most applications, but can create headaches for benchmarking and
>> > deterministic timing. The other problem is the lack of documentation and
>> > control about this features. The strategies apparently change with each
>> > new
>> > matlab release, as new optimization features are added under the hood.
>> >
>> > This JIT mechanism is what gives Matlab a speed advantage over Octave
>> > for
>> > poorly written code, whereas there's basically no difference for well
>> > written code in most cases. For maximum performance and most
>> > deterministic
>> > timing it is best to optimize your code yourself as described in
>> > Mathworks
>> > documentation, so the JIT has to do less guesswork and runtime
>> > optimization
>> > and you'll get better performance/timing from the start. And of course
>> > use
>> > ptb's timing functions wisely to immunize your code against such
>> > behaviours
>> > as much as possible.
>> >
>> > -mario
>> >
>> > --- In psychtoolbox@yahoogroups.com, "Diederick C. Niehorster"
>> > <dcnieho@>
>> > wrote:
>> >>
>> >> Hi Mario,
>> >>
>> >> Quick questions on on eof your pieces of advice: why does making the
>> >> script a function (simply adding a function declaration with no input
>> >> arguments atop the script i presume) improve performance?
>> >>
>> >> Thanks for the extra bit of understanding!
>> >>
>> >> Dee
>> >>
>> >> On Sun, Jul 5, 2009 at 11:59 AM, Mario
>> >> Kleiner<mario.kleiner@> wrote:
>> >> >
>> >> >
>> >> > PTB doesn't have a dedicated function for what you want, but on OS/X
>> >> > (or
>> >> > Windows if you have an expensive pro graphics card) you could abuse
>> >> > frame-sequential stereomode, as demonstrated by StereoDemo(1), to do
>> >> > this
>> >> > for you -- Reliable automatic flipping between two images at video
>> >> > refresh
>> >> > rate.
>> >> >
>> >> > Wrt. to your script there's bits of headroom for optimization:
>> >> >
>> >> > 0. Quit any unneeded applications/virus scanners/software
>> >> > updtes/indexing
>> >> > services etc. Disconnect from the network and unneccessary devices.
>> >> > Disable
>> >> > secondary displays if any (single monitor mode).
>> >> > 1. Make sure its a function, not a script.
>> >> > 2. Use the Priority() command to enable realtime priority.
>> >> > 3. Try setting the dontclear flag of Screen('Flip') to a value of 2.
>> >> > then
>> >> > 'flip' will flip forth and back between the front- and backbuffer
>> >> > without
>> >> > clearing to background color inbetween. Fill one buffer with white,
>> >> > flip,
>> >> > fill other buffer with stimulus, flip. then repeat flip's infinitely
>> >> > withour
>> >> > redrawing anything.
>> >> > 4. Screen('Drawingfinished') won't help nor hurt in this case.
>> >> > 5. Don't use PsychImaging('AddTask', 'General',
>> >> > 'FloatingPoint32BitIfPossible');
>> >> >
>> >> > This will add processing overhead of maybe 1 msec or so, which is
>> >> > normally
>> >> > irrelevant, but maybe not insignificant if your whole video refresh
>> >> > cycle is
>> >> > only 6.6 msecs.
>> >> >
>> >> > On a modern graphics card in combination with some high precision
>> >> > display
>> >> > device like a Video attenuator, the VideoSwitcher or a Bits+ box or
>> >> > similar
>> >> > devices, or even in PseudoGray mode (aka "bitstealing"), that
>> >> > function
>> >> > can
>> >> > provide a large increase in output precision. The
>> >> > AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a
>> >> > large
>> >> > number of output devices/mode we support, as well as color
>> >> > correction/gamma
>> >> > correction and other applications.
>> >> >
>> >> > The way you use it, it won't help - it doesn't have any benefit for
>> >> > your
>> >> > specific stimulus and you'll end up with a 8 bit framebuffer image.
>> >> > It
>> >> > will
>> >> > just add a bit of extra processing time.
>> >> >
>> >> > In general, OS/X and Linux have way better realtime timing behaviour
>> >> > than
>> >> > Windows when every millisecond counts. Still your approach doesn't
>> >> > sound
>> >> > like a reliable way of achieving whatever you want to achieve.
>> >> >
>> >> > But i still fail to see the idea behind this "increasing the
>> >> > blacklevel"? Is
>> >> > this something extraordinary clever i've never heard about? Or the
>> >> > wrong
>> >> > way
>> >> > to get more precision?
>> >> >
>> >> > Please enlighten me,
>> >> > -mario
>> >> >
>> >> > --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@>
>> >> > wrote:
>> >> >>
>> >> >> How can you increase the black level of a monitor by this method?
>> >> >> And
>> >> >> why?
>> >> >> What's the purpose?
>> >> >>
>> >> >> -mario
>> >> >>
>> >> >> --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@>
>> >> >> wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> >
>> >> >> > in order to achieve an increase of my monitors black level, I am
>> >> >> > presenting my stimulus screen and a white screen in a
>> >> >> > frame-to-frame
>> >> >> > alternating method on a 150Hz display.
>> >> >> > It works quite well for most of the time and I achieve a stable
>> >> >> > looking
>> >> >> > 75Hz display. But from time to time I get a flash on the screen,
>> >> >> > which
>> >> >> > probably indicates, that timing went wrong at that incident.
>> >> >> >
>> >> >> > Question: Is there a built-in-function, which supports such a
>> >> >> > procedure?
>> >> >> > Other than getting a faster GPU/CPU or maybe switching the OS(I
>> >> >> > use
>> >> >> > WinXP),
>> >> >> > does anybody have an idea, how I could get rid of the (rare)
>> >> >> > flashes?
>> >> >> >
>> >> >> > I was scanning the psychtoolbox forum, but couldn't find a hint,
>> >> >> > why
>> >> >> > my
>> >> >> > system does not run my script 'smooth'. VBLSyncTest.m does report
>> >> >> > a
>> >> >> > good
>> >> >> > timing in single-display mode. You can find my code attached
>> >> >> > below.
>> >> >> > It's
>> >> >> > really not a very sophisticated realization of what I want from my
>> >> >> > computer,
>> >> >> > so I am happy for any hint, how this can be done well.
>> >> >> >
>> >> >> > Thanks in advance!
>> >> >> > Markus
>> >> >> >
>> >> >> > ------------------
>> >> >> > % Find out how many screens and use largest screen number.
>> >> >> > whichScreen = max(Screen('Screens'));
>> >> >> >
>> >> >> > PsychImaging('PrepareConfiguration');
>> >> >> > PsychImaging('AddTask', 'General',
>> >> >> > 'FloatingPoint32BitIfPossible');
>> >> >> > [window winRect] = PsychImaging('OpenWindow', whichScreen);
>> >> >> > Screen('FillRect',window,0);
>> >> >> > lacer = 0;
>> >> >> > Priority(2);
>> >> >> > for i=128:64:256
>> >> >> > resp = 0;
>> >> >> > while ~KbCheck
>> >> >> > switch lacer
>> >> >> > case 1
>> >> >> > Screen('FillRect',window,255);
>> >> >> > case 2
>> >> >> > Screen('FillRect',window,0);
>> >> >> > Screen('FillRect',window,i,[500 300 800 600]);
>> >> >> > end
>> >> >> > Screen('DrawingFinished', window);
>> >> >> > lacer = mod(lacer,2)+1;
>> >> >> > Screen('Flip',window);
>> >> >> > end
>> >> >> > while KbCheck
>> >> >> > switch lacer
>> >> >> > case 1
>> >> >> > Screen('FillRect',window,255);
>> >> >> > case 2
>> >> >> > Screen('FillRect',window,0);
>> >> >> > end
>> >> >> > Screen('DrawingFinished', window);
>> >> >> > lacer = mod(lacer,2)+1;
>> >> >> > Screen('Flip',window);
>> >> >> > end
>> >> >> > end
>> >> >> > cls
>> >> >> > -----------------------------
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
8
--- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@...> wrote:
>
> PTB doesn't have a dedicated function for what you want, but on OS/X (or Windows if you have an expensive pro graphics card) you could abuse frame-sequential stereomode, as demonstrated by StereoDemo(1), to do this for you -- Reliable automatic flipping between two images at video refresh rate.
>

Thanks for the tip with StereoDemo(1). I was able to integrate the idea of the code into my own script.

> Wrt. to your script there's bits of headroom for optimization:
>
> 0. Quit any unneeded applications/virus scanners/software updtes/indexing services etc. Disconnect from the network and unneccessary devices. Disable secondary displays if any (single monitor mode).
> 1. Make sure its a function, not a script.
> 2. Use the Priority() command to enable realtime priority.
> 3. Try setting the dontclear flag of Screen('Flip') to a value of 2. then 'flip' will flip forth and back between the front- and backbuffer without clearing to background color inbetween. Fill one buffer with white, flip, fill other buffer with stimulus, flip. then repeat flip's infinitely withour redrawing anything.
> 4. Screen('Drawingfinished') won't help nor hurt in this case.
> 5. Don't use PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');

Thanks a lot! I achieved very high precision now, thanks to your hints. Timing errors are now close to not existent (>3 during a 10 minute duration).

>
> This will add processing overhead of maybe 1 msec or so, which is normally irrelevant, but maybe not insignificant if your whole video refresh cycle is only 6.6 msecs.
>
> On a modern graphics card in combination with some high precision display device like a Video attenuator, the VideoSwitcher or a Bits+ box or similar devices, or even in PseudoGray mode (aka "bitstealing"), that function can provide a large increase in output precision. The AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a large number of output devices/mode we support, as well as color correction/gamma correction and other applications.
>

THAT was what I was looking for in particular! I am now thinking of purchasing one of the listed devices - my favourite is Bits+box so far.

> The way you use it, it won't help - it doesn't have any benefit for your specific stimulus and you'll end up with a 8 bit framebuffer image. It will just add a bit of extra processing time.
>
> In general, OS/X and Linux have way better realtime timing behaviour than Windows when every millisecond counts. Still your approach doesn't sound like a reliable way of achieving whatever you want to achieve.
>

For now the realtime timing behavior of Windows does suffice. But after the last month's experience, I'll switch to a linux system, as soon as I have the time for a system switch.

> But i still fail to see the idea behind this "increasing the blacklevel"? Is this something extraordinary clever i've never heard about? Or the wrong way to get more precision?
>
> Please enlighten me,

Well it was just my way (as a non-engineer) of phrasing something, that anybody working in the field of contrast detection is interested in:

Having a limited amount of greyscales (so far 256 for me) troubles the measurement of contrast sensitivity. While having detected the step size of contrast, which is visible to a subject (just noticable difference JND), we want to investigate how changes in the periphery can manipulate this detection threshold. Having 256 grey values spread between 5 - 260 cd/m^2, does mean I can only measure contrast sensitivity as coarse as ~1 cd/m^2. If I can have the 256 values spread between 100 - 163 cd/m^2, I can accomplish a much finer measurement, that is ~0.25cd/m^2 per step. In my language that was 'increasing the black level' from 5 to 100.

Again, thanks for your extended answers, they have helped me a lot. I am still working out the hints you gave me and I'll post here the final solution I got.

>
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@> wrote:
> >
> > How can you increase the black level of a monitor by this method? And why? What's the purpose?
> >
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@> wrote:
> > >
> > > Hello,
> > >
> > > in order to achieve an increase of my monitors black level, I am presenting my stimulus screen and a white screen in a frame-to-frame alternating method on a 150Hz display.
> > > It works quite well for most of the time and I achieve a stable looking 75Hz display. But from time to time I get a flash on the screen, which probably indicates, that timing went wrong at that incident.
> > >
> > > Question: Is there a built-in-function, which supports such a procedure? Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP), does anybody have an idea, how I could get rid of the (rare) flashes?
> > >
> > > I was scanning the psychtoolbox forum, but couldn't find a hint, why my system does not run my script 'smooth'. VBLSyncTest.m does report a good timing in single-display mode. You can find my code attached below. It's really not a very sophisticated realization of what I want from my computer, so I am happy for any hint, how this can be done well.
> > >
> > > Thanks in advance!
> > > Markus
> > >
> > > ------------------
> > > % Find out how many screens and use largest screen number.
> > > whichScreen = max(Screen('Screens'));
> > >
> > > PsychImaging('PrepareConfiguration');
> > > PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
> > > [window winRect] = PsychImaging('OpenWindow', whichScreen);
> > > Screen('FillRect',window,0);
> > > lacer = 0;
> > > Priority(2);
> > > for i=128:64:256
> > > resp = 0;
> > > while ~KbCheck
> > > switch lacer
> > > case 1
> > > Screen('FillRect',window,255);
> > > case 2
> > > Screen('FillRect',window,0);
> > > Screen('FillRect',window,i,[500 300 800 600]);
> > > end
> > > Screen('DrawingFinished', window);
> > > lacer = mod(lacer,2)+1;
> > > Screen('Flip',window);
> > > end
> > > while KbCheck
> > > switch lacer
> > > case 1
> > > Screen('FillRect',window,255);
> > > case 2
> > > Screen('FillRect',window,0);
> > > end
> > > Screen('DrawingFinished', window);
> > > lacer = mod(lacer,2)+1;
> > > Screen('Flip',window);
> > > end
> > > end
> > > cls
> > > -----------------------------
> > >
> >
>
9
If you only need high resolution luminance output then the VideoSwitcher of Xiangrui Li et al. is a relatively cheap option:

<http://lobes.usc.edu/VideoSwitcher>

Supported (for maximum ease of use preferrably on the most recent NVidia or ATI GPU's), but in principle on any graphics card with some compromise in perfomance and ease of use by the PsychVideoSwitcher driver.

The device can also send out a single electronic trigger pulse on stimulus onset. Worked quite well during testing. The downside is their awkward procedure of ordering and paying the device. Most german university / research institute administrations would have huge headaches placing an order the way they want it under the conditions they want it. (Scientists, duh!)

The Bits+ is probably a bit more expensive, but it can also create RGB color stimuli with 14 bpc, output trigger signals, and comes from a company with a properly working sales & support department.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@...> wrote:
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@> wrote:
> >
> > PTB doesn't have a dedicated function for what you want, but on OS/X (or Windows if you have an expensive pro graphics card) you could abuse frame-sequential stereomode, as demonstrated by StereoDemo(1), to do this for you -- Reliable automatic flipping between two images at video refresh rate.
> >
>
> Thanks for the tip with StereoDemo(1). I was able to integrate the idea of the code into my own script.
>
> > Wrt. to your script there's bits of headroom for optimization:
> >
> > 0. Quit any unneeded applications/virus scanners/software updtes/indexing services etc. Disconnect from the network and unneccessary devices. Disable secondary displays if any (single monitor mode).
> > 1. Make sure its a function, not a script.
> > 2. Use the Priority() command to enable realtime priority.
> > 3. Try setting the dontclear flag of Screen('Flip') to a value of 2. then 'flip' will flip forth and back between the front- and backbuffer without clearing to background color inbetween. Fill one buffer with white, flip, fill other buffer with stimulus, flip. then repeat flip's infinitely withour redrawing anything.
> > 4. Screen('Drawingfinished') won't help nor hurt in this case.
> > 5. Don't use PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
>
> Thanks a lot! I achieved very high precision now, thanks to your hints. Timing errors are now close to not existent (>3 during a 10 minute duration).
>
> >
> > This will add processing overhead of maybe 1 msec or so, which is normally irrelevant, but maybe not insignificant if your whole video refresh cycle is only 6.6 msecs.
> >
> > On a modern graphics card in combination with some high precision display device like a Video attenuator, the VideoSwitcher or a Bits+ box or similar devices, or even in PseudoGray mode (aka "bitstealing"), that function can provide a large increase in output precision. The AdditiveBlendingForLinearSuperpositionTutorial demo demonstrates a large number of output devices/mode we support, as well as color correction/gamma correction and other applications.
> >
>
> THAT was what I was looking for in particular! I am now thinking of purchasing one of the listed devices - my favourite is Bits+box so far.
>
> > The way you use it, it won't help - it doesn't have any benefit for your specific stimulus and you'll end up with a 8 bit framebuffer image. It will just add a bit of extra processing time.
> >
> > In general, OS/X and Linux have way better realtime timing behaviour than Windows when every millisecond counts. Still your approach doesn't sound like a reliable way of achieving whatever you want to achieve.
> >
>
> For now the realtime timing behavior of Windows does suffice. But after the last month's experience, I'll switch to a linux system, as soon as I have the time for a system switch.
>
> > But i still fail to see the idea behind this "increasing the blacklevel"? Is this something extraordinary clever i've never heard about? Or the wrong way to get more precision?
> >
> > Please enlighten me,
>
> Well it was just my way (as a non-engineer) of phrasing something, that anybody working in the field of contrast detection is interested in:
>
> Having a limited amount of greyscales (so far 256 for me) troubles the measurement of contrast sensitivity. While having detected the step size of contrast, which is visible to a subject (just noticable difference JND), we want to investigate how changes in the periphery can manipulate this detection threshold. Having 256 grey values spread between 5 - 260 cd/m^2, does mean I can only measure contrast sensitivity as coarse as ~1 cd/m^2. If I can have the 256 values spread between 100 - 163 cd/m^2, I can accomplish a much finer measurement, that is ~0.25cd/m^2 per step. In my language that was 'increasing the black level' from 5 to 100.
>
> Again, thanks for your extended answers, they have helped me a lot. I am still working out the hints you gave me and I'll post here the final solution I got.
>
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "Mario Kleiner" <mario.kleiner@> wrote:
> > >
> > > How can you increase the black level of a monitor by this method? And why? What's the purpose?
> > >
> > > -mario
> > >
> > > --- In psychtoolbox@yahoogroups.com, "tschainies" <markusgoldbach@> wrote:
> > > >
> > > > Hello,
> > > >
> > > > in order to achieve an increase of my monitors black level, I am presenting my stimulus screen and a white screen in a frame-to-frame alternating method on a 150Hz display.
> > > > It works quite well for most of the time and I achieve a stable looking 75Hz display. But from time to time I get a flash on the screen, which probably indicates, that timing went wrong at that incident.
> > > >
> > > > Question: Is there a built-in-function, which supports such a procedure? Other than getting a faster GPU/CPU or maybe switching the OS(I use WinXP), does anybody have an idea, how I could get rid of the (rare) flashes?
> > > >
> > > > I was scanning the psychtoolbox forum, but couldn't find a hint, why my system does not run my script 'smooth'. VBLSyncTest.m does report a good timing in single-display mode. You can find my code attached below. It's really not a very sophisticated realization of what I want from my computer, so I am happy for any hint, how this can be done well.
> > > >
> > > > Thanks in advance!
> > > > Markus
> > > >
> > > > ------------------
> > > > % Find out how many screens and use largest screen number.
> > > > whichScreen = max(Screen('Screens'));
> > > >
> > > > PsychImaging('PrepareConfiguration');
> > > > PsychImaging('AddTask', 'General', 'FloatingPoint32BitIfPossible');
> > > > [window winRect] = PsychImaging('OpenWindow', whichScreen);
> > > > Screen('FillRect',window,0);
> > > > lacer = 0;
> > > > Priority(2);
> > > > for i=128:64:256
> > > > resp = 0;
> > > > while ~KbCheck
> > > > switch lacer
> > > > case 1
> > > > Screen('FillRect',window,255);
> > > > case 2
> > > > Screen('FillRect',window,0);
> > > > Screen('FillRect',window,i,[500 300 800 600]);
> > > > end
> > > > Screen('DrawingFinished', window);
> > > > lacer = mod(lacer,2)+1;
> > > > Screen('Flip',window);
> > > > end
> > > > while KbCheck
> > > > switch lacer
> > > > case 1
> > > > Screen('FillRect',window,255);
> > > > case 2
> > > > Screen('FillRect',window,0);
> > > > end
> > > > Screen('DrawingFinished', window);
> > > > lacer = mod(lacer,2)+1;
> > > > Screen('Flip',window);
> > > > end
> > > > end
> > > > cls
> > > > -----------------------------
> > > >
> > >
> >
>
10
> Well it was just my way (as a non-engineer) of phrasing
> something, that anybody working in the field of contrast
> detection is interested in:
>
> Having a limited amount of greyscales (so far 256 for me)
> troubles the measurement of contrast sensitivity. While
> having detected the step size of contrast, which is visible
> to a subject (just noticable difference JND), we want to
> investigate how changes in the periphery can manipulate this
> detection threshold. Having 256 grey values spread between 5
> - 260 cd/m^2, does mean I can only measure contrast
> sensitivity as coarse as ~1 cd/m^2. If I can have the 256
> values spread between 100 - 163 cd/m^2, I can accomplish a
> much finer measurement, that is ~0.25cd/m^2 per step. In my
> language that was 'increasing the black level' from 5 to 100.

At least under windows you can do something like that with the gamma ramp,
if you have a 10 bit dac (any ATI radeon made in the last 5-8 years) and a
CRT. I get ~.15cd/m2 per step on my machine, centered around 50cd/m2. I
wrote some code for this under PTB 2.54, but haven't tried to port to 3.x
yet. A tool to set the gamma ramp can be found here, under the linearization
toolkit:

http://csclab.ucsd.edu/~alan/vision/matlab_code/
11
Afaik all ATI's and all NVidia's starting with GF 8000 have 10 bit DAC's and setting such gamma tables via the Screen('LoadNormalizedGammaTable') command should work on all operating systems, so if you can do with a subset of 256 levels (8 bit framebuffer) out of the 1024 possible levels of the DAC, that's an option.

Your toolkit would probably be trivial to port to PTB-3. The tool to set the gamma ramp inside your toolkit does just the same as PTB's Screen('LoadNormalizedGammaTable') command or Screen('LoadCLUT') command, so you'd just need to slightly tweak your M-file code.

best,
-mario

--- In psychtoolbox@yahoogroups.com, "Alan Robinson" <robinson@...> wrote:
>
>
> > Well it was just my way (as a non-engineer) of phrasing
> > something, that anybody working in the field of contrast
> > detection is interested in:
> >
> > Having a limited amount of greyscales (so far 256 for me)
> > troubles the measurement of contrast sensitivity. While
> > having detected the step size of contrast, which is visible
> > to a subject (just noticable difference JND), we want to
> > investigate how changes in the periphery can manipulate this
> > detection threshold. Having 256 grey values spread between 5
> > - 260 cd/m^2, does mean I can only measure contrast
> > sensitivity as coarse as ~1 cd/m^2. If I can have the 256
> > values spread between 100 - 163 cd/m^2, I can accomplish a
> > much finer measurement, that is ~0.25cd/m^2 per step. In my
> > language that was 'increasing the black level' from 5 to 100.
>
> At least under windows you can do something like that with the gamma ramp,
> if you have a 10 bit dac (any ATI radeon made in the last 5-8 years) and a
> CRT. I get ~.15cd/m2 per step on my machine, centered around 50cd/m2. I
> wrote some code for this under PTB 2.54, but haven't tried to port to 3.x
> yet. A tool to set the gamma ramp can be found here, under the linearization
> toolkit:
>
> http://csclab.ucsd.edu/~alan/vision/matlab_code/
>