Flickering Picture
Claudia Brand
their eyes a moving object that is projected to the wall with a beamer, I
wrote a programme with LabView using the functions "Draw Multiple Lines.vi"
and "Picture Out". However the result is not satisfying - the moving picture
(two vertical squares) seems to be updated in several blocks, from bottom to
top, and flickers. This happens even with slow movement.
We've tried out different output devices (normal CRT screen, TFT display,
beamer), graphic cards, screen update rates, colour depths and update rates
within the LabView loop but all configurations look similar. I wonder if it
is a synchronisation problem between LabView and Windows.
Configuration: PentiumIII PC, Windows2000, LabView 6.0
If someone has a hint - thanks very much for helping!
Labviewguru
I believe that this issue does in fact revolve around reliance upon
the operating system by LabVIEW to perform graphical updates.
I suspect that a much different solution should be explored. I would
believe that you would benefit from a seperate graphics driver that is
perhaps raster based, driving a completely different video output.
Windows tends to do things the way that it wants to.
Unfortunately, I cannot advise you as to a specific setup. I recommend
finding an output device, such as a projector or monitor, that can be
driven by an instrument, which you can program with LabVIEW. Instead
of outputting to the front panel, you would move your output (objects)
to the external instrument. This would solve your problem with the
updating.
I am sure that there is someone out there that knows what a good
instrument/driver is.
If the objects are in fact simple rastor images, a simple laser
scanner can function quite well, and are, as I believe, relatively
inexpensive, although a bit difficult to find (they are woefully out
of date).
Good luck, and please let us all know how you fare.
Enrique
Try the following. Right-click the picture indicator and select "Data
Operations -> Smooth Updates"
(please remove the x when responding )
When your program is running, right-click over the picture indicator
and select 'smooth updates'
Also ensure that there are no overlaping objects on the indicator
Regards,
Peter
Ben
Have you tried using the defer front panel updates property?
Set the property to true before writing to the picture.
As soon as you are done writing to the picture, set the property to
false.
Also, are you using the driver recomended by the manufacturer of the
"beamer"?
How is your CPU performance while this is happening? If it is busy you
might be missing some delays in loops.
I hope this gives you some ideas.
Ben
Claudia Brand
fix the problem
Labviewguru:
Using an external device is a good suggestion but we'd have to search and
buy one, which is an option I will consider when everything else fails (it
sounds like a lot of time and money)
Enrique and Peter:
"Smooth Update" was checked by default (unchecking makes the whole thing
even worse)
Ben:
(1) Where can I set the "defer front panel updates property"?
(2) There's no recomendation for a specific driver for the beamer (beamer is
a "PLUS U2-1130"), but following your suggestion I tried to adjust its clock
frequency and clock phase manually instead of automatically, which didn't
help (flicker occurs also on normal CRT or TFT displays)
(3) CPU performance is at 50% (or lower on a different, faster PC which I
tried out) and memory usage is about 53MB
Greetings
C. Brand
PdB_Serenity_nl
output device. You could off-line send bitmaps to it.
Playing in sequence produced an animation.
It was to become the building-block of big LED-panels, but
developments are now paused caused by lack of customer's interests.
It is extremely low-ress (16 x 16) and probably unuseful for your
application. And yes expensive.
But it was outputting what you wanted at the exact moment.
And not surprisingly, I used LabVIEW to build the PC-part.
Patrick de Boevere (p...@serenity.nl)
Serenity systems design
Enrique
I understand, you are projecting a LabVIEW VI, which (seems to)
consist of only a big picture indicator.
Are you observing the flickering problem only in the picture indicator
or the whole screen? Did the flickering occur only when you run the LV
program? Is there no flickering at all in the computer monitor? If you
project any other application, does it flickers too?
Is the picture you are projecting changin rapidly to "opposite colors"
(like from all black to all white)? Have you try it using a different
computer?
Also, an idea on how your vi generate the pictures can be of help too.
Sorry for the amount of questions. The idea is to attempt to isolate
the problem. If your applications looks similar to giving a
presentation (like a PowerPoint presentation), then it is a little
hard for me to think the problem is within LabVIEW.
Regards;
Enrique
AIR
Maybe the displaying of the image (1 frame) takes to long. There are several
ways to resolve this.
1) optimize the LabVIEW code. All the image vi's are build for simple usage,
not performance. E.g. in almost every vi, the brush color is set (to the
same color?). All this data adds up, so it might take to long to build up
the image.
2) Another way to overcome this is an old trick called 'frame buffering'
(among other names). An image is drawn in a buffer, and when finished it is
copied to screen.
In your application this might do the trick:
> Create a Invoke Node 'Get Picture' of the current picture (Picture 1)
> Use 'Draw Flattend Pixmap.vi' to draw it in a picture control (Picture 2)
Picture 2 contains a bitmap of Pcture 2. This should be a lot faster to draw
then all items in Pcture 1!
It's a bit of 'pizza programming' but it just might work.
Regards,
Wiebe.
"Claudia Brand" <nospam> wrote in message news:3c3c6945$1...@pfaff.ethz.ch...
Claudia Brand
look at the VI. It is on our web server under the address
http://www.iha.bepr.ethz.ch/pages/leute/schnoz/balken5.vi
> I have simple questions to help in understand your situation: For what
> I understand, you are projecting a LabVIEW VI, which (seems to)
> consist of only a big picture indicator.
Right
> Are you observing the flickering problem only in the picture indicator
> or the whole screen?
Only in the picture indicator
> Did the flickering occur only when you run the LV program?
Yes
> Is there no flickering at all in the computer monitor? If you project any
other application, does it flickers too?
No flickering in other applications
> Is the picture you are projecting changin rapidly to "opposite colors"
(like from all black to all white)?
No, the colour does not change
> Have you try it using a different computer?
Yes, on a fast laptop
> Also, an idea on how your vi generate the pictures can be of help too.
The picture moves from left to right and back to the left in a sinusoidal
way at different speeds. In a loop, I calculate the new co-ordinates of the
two rectangles and draw them with the "Draw multiple lines.vi". The loop
update rate is 1ms; I tried to reduce it to fit the graphic card update
rate, but this didn't help.
The application isn't yet finished; once the flickering problem is solved
(and when I know I will definitely stay with LabView for this experiment) I
will complete it with data logging (body/head movement and electromyography
over a National Instruments A/D card).
Regards, greetings, thanks!
Claudia Brand
AIR
I've build a simulation vi that reproduces the problems you have. Copying
the picture helps...
If you want the vi, let me know.
Regards,
Wiebe.
"AIR" <a...@air.nl> wrote in message news:a1msig$7n3$1...@news1.xs4all.nl...
Claudia Brand
VI, I put it on our web server under
http://www.iha.bepr.ethz.ch/pages/leute/schnoz/balken5.vi
Claudia
Ben
2) Use Property node to get reference to panel
3) Use propert node to set/clear "DeferPanUpdts"
Ben
AIR
the problem is two fold...
First the eye is fooled. The movement you send the boxes to is not 'time
synchronized'. Instead of using 'i' in the while loop as a counter, use the
start time minus the current time. This looks better.
Second, use Draw Rect.vi , this is faster. Or draw a 2d array as a bitmap.
you can even build the entire picture as a bitmap, using array opperations,
and draw it in a picture as a bitmap.
Good luck,
Wiebe.
eh
Labviewguru
My sincerest apologies. I got my Vectors and Rastors mixed up. The
problem, it sounds like, is that you are using a rastor based imaging
system to display vector based graphics. I did a search for "vector
image projector for windows" in Yahoo and found several good hits.
The first one: http://usa.electrosonic.com/vector.asp looks like a
very good place to start. I highly recommend checking out this
option. Your solution, it seems to me, calls for a completely
different way of displaying the images. Not only that, but when you
are done, you get a nice toy for parties and shows...
Good luck. Please post your results (I hope you succeed, this sounds
like fun.)
PS: I did some more checking, and I think you should also check out
Laser Displays. These are the devices used at trade shows and other
events to display images on walls using a laser. I have been 'out of
the loop' on these since my laser training in the 80's, and it seems
they have taken off a lot since then (we used supermaket scanners to
make our lightshows...fun, but limited.)
I hope this helps.
Greg McKaskle
>
> If someone has a hint - thanks very much for helping!
First lets make a few measurements. I placed a sequence around your
picture control terminal, added a frame before and another after the
terminal. In each of these, add a Tick Count function. Outside the
sequence, you can subtract and display the time spent redrawing the
picture control. On my computer I see about 50ms being spent drawing
the picture and around 1ms being spent computing the points and calling
the drawing functions.
This means that each loop iteration takes about 50ms, which makes 20Hz
while my monitor updates at more like 80 Hz. That means that while the
picture control is updating one time, the screen updates about four
times. With smooth updates turned on, the new image is prepared in a
bitmap and the bitmap is drawn in one command straight to the screen.
Unfortunately, this one update command is what is taking the 50ms. This
means that the monitor will show four partial updates and the human
eye sees it as the jagged edge on the rectangles.
With the Smooth updates turned off, the screen only takes about 5ms to
update. This means that the picture control updates about 2.5 times
each time the monitor redraws. This allows the boxes to jump around
more than you probably intended, not moving very smoothly.
Additionally, you still get aliasing because now the picture is all
drawn to the screen. That means it is erased, then one rectangle is
drawn, then the other. If some of the monitor updates catch the picture
control when it is erased without rectangles drawn, then this will cause
lots of flashing between the background and the rectangle color. You
can slow the updates down by placing a delay in the loop. Putting about
a 12ms delay really smooths it out, but you will see the flashing moving
more slowly with the edges looking really smooth. If we could
completely synchronize the picture draw with the monitor draw, it would
get rid of the rest of the flicker and look great, but I'm afraid that I
don't know of a way to do this without resorting to gaming
APIs like DirectDraw. It might be worth your time to look at DirectDraw
and see if this is possible.
Another approach is to use the Smooth Updates, but try to improve the
speed to get closer to 12ms or the time for a monitor update. This will
still allow the edge to be a bit jagged, but much less than when it is
as far out of synch as when it started. One thing that you might try is
to change your monitor depth. Moving from True color to thousands of
colors will likely speed up the picture control. It all depends on the
video driver and the video card. On my computer it sped up to 25ms.
Getting pretty close.
To speed it up a bit more, I turned off the Erase First option, then
erase the rectangles myself by redrawing them with the background color.
To do this, I drop two additional Draw Multiple Lines VIs, wire up the
color to match the background of the picture control. To copy the color
more accurately, you can use the eye dropper tool to copy the color from
the picture control and paste it into a color numeric. Next, wire the
computed points into the VIs, send the picture into the right side of a
shift register. Wire the left shift register into the existing Draw
Multi VIs. This will take the rectangle from the previous iteration and
redraw with the background color, then draw the new rectangles in the
new location. This sped my updates up to about 18ms. It looks pretty
good on the screen.
I could probably speed it up a bit more by recognizing that we are
drawing most of the rectangle area twice and erasing just the trailing
edge and drawing the leading edge. Unfortunately this will not gain me
more than about 1ms. This is easy to test by shrinking the rectangle
size using the slider at the bottom of the page.
It probably isn't hard to find a computer video card faster than mine.
Add the timing code and see if you can get the update speed pretty close
to the monitor refresh rate. There may still be a little aliasing, but
it will be much less noticable.
One final way to affect the update rate is to adjust the size of the
picture control. The update speed is directly proportional to the
number of pixels to redraw. When using Smooth Updates, this is the size
of the control. I know that you want this to be large, but you might be
able to change the monitor resolution and make the picture control
smaller and gain lots of speed that way as well.
Long winded, but I hope this will help. If you have further questions,
fire away.
Greg McKaskle
Claudia Brand
Thanks to you all for the help - especially Greg for his extended
contribution! Now, what I did today is (I've not been in from Friday till
Tuesday morning):
First I played with update rates as proposed by Greg. Turning smooth update
off and synchronising the update rate with the screen update, comes out
quite neat, but not neat enough. System colour reduction to 256 was already
set before. Where I did not succeed was in erasing (drawing with the
background colour) the rectangles before an update - I simply didn't manage
to write into the same "picture out" from both frames of a sequence
structure. You see, I'm not yet a LabView guru.
What I did then was to split the two rectangles into smaller sub-rectangles
of 50 px height and 30 px vertical distance, as illustrated below:
_ _
_ _
_ _
_ _
_ _
_ _
This irritates the eyes less than the normal rectangles with the given
update problem, and is no disadvantage for the subjects (who have to track
their head with a mounted laser pointer pointing somewhere between the two
rectangles. The reason for using two long rectangles is for the subjects to
have free choice in their vertical head position.)
To Wiebe:
Using the time instead of the counter is a good idea, this way I can also
check the actually spent time. If you want to show me your simulation, you
can send it to me (replace AT by @) : claudia_brand AT gmx.net
Using an external displaying device is still an option which also has the
advantage we'd not have to reserve the group's beamer all the time. But
there's not too much money around for buying new things. I'll keep my eyes
open.
OK for today, thanks again
Claudia
mel
I am also trying to do human behavioral studies using LabView on a
small budget. I share your pain. Unfortunately I invested a lot of
time and effort in my labview6 program only to come up against the
same obstacles you have. Part of my study involves subjects moving a
cursor connected to a pot to track a moving target on the screen. I
have tried all of the suggestions the gurus gave you, all to no avail.
(I refresh the screen at 60Hz, but things still look bad if the cursor
moves fast enough.) I was wondering if any of the gurus know how we
could easily employ ActiveX for our displays. It seems that the
cursor in Windows2000 always looks good, no matter how fast it moves.
--Melinda
Greg McKaskle
I'm sorry to hear that we have failed you, but if you are willing to
write the SW the right way, you can make it work. Active X will
probably not help that much. I'm not familiar with every control out
there, but what you really need to do is use lower level HW access, like
the cursor is doing. The LV graphics are done on top of Windows using
what is know as the GDI or graphics device interface. It helps to make
lots of video and printers work roughly the same, but it is sort of
primitive and sort of old. It doesn't expose enough control to be able
to reduce the flicker that you are talking about, because what you
really have to do is to synchronize the drawing with the monitor's
refresh. If they aren't in synch, then you get a jumpy update or you
get jagged graphics edges. It is much like setting up a strobe light.
You need to synchronize the other things in your experiment to the
strobe or everything gets out of whack.
As I said in my earlier post, I think the best way to accomplish this
flicker-free graphics is to use DirectDraw. It is part of DirectX and
is how many of the PC games are written. You may be able to do the
synchronization through OpenGL, but when we last checked, it was not in
the implementation that we wanted to use. Specifically what you want to
use is what is called double-buffering or back-buffering. It is where
two screens or windows worth of memory are set aside, and when a frame
of your drawing is complete, you schedule to have the buffers flipped.
This flipping will not occur while the CRT is tracing the screen, but
will wait until the next ~60HZ tick when it can swap pointers so that
the next trace will come from the complete buffer. This is really the
only way to guarantee that no flicker takes place because the image the
user sees is always complete, no partial images with old and new or
erased but still drawing.
I know that this sounds like something that should be more simple, but
it is one of those things that game SW deals with all the time and other
SW really doesn't need, therefore normal graphics APIs don't support it.
FYI, the poor man's method of doing this is to use a bitmap to draw the
graphics and copy the bitmap to the screen when everything is ready.
This is what LV does to provide smooth updates or offscreen drawing. It
gets rid of most flicker, but not all.
Sorry that there isn't a simpler solution.
Greg McKaskle
alberto
I am going to try a different approach to your problem: I'll try to
use the IMAQ functions to create a moving rectangle in a pixmap and
display it in an IMAQ window. I think this should work, the only draw
back is that it needs the IMAQ functions toolkit.
Just give me some time and I'll let you know.
Alberto
VI Guy
of the object, you could just move a control around the front panel.
They dont suffer from the flickering of redraw. Put a old style flat
boolean, create a property node and wire your already calculated 'top'
and 'left' values to its position property.
If the dynamic attribute changes are what you are after, this solution
wont help much because the controls cant be resized at run-time (most
controls you can recolor though).
My 2 cents.
mel
instead of updating a picture control, but it still flickers at the
rate I'm moving it. Also, I'm doing continuous analog acquisition
during all of this and for some reason moving around a boolean with a
property node creates a lot of memory overhead and my scan backlog
ramps up. The same is true for the bitmap suggestion made earlier --
so far using an invoke node to make the bitmap (the easiest way I can
think of to do it) creates a lot of overhead also. I have 512K of
RAM...maybe I need to kill other processes. Anyway, the problem isn't
that big of a deal...it's just annoying because my software will be
used to study the brains of old people and I'd like to minimize the
distractions.
I really appreciate all of your help with this hairy problem.
--Melinda (Please note that I'm new to this list and am not the
original question submitter.)