From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Flickering Picture

1) use "Open VI Reference" to get a refernece to VI
2) Use Property node to get reference to panel
3) Use propert node to set/clear "DeferPanUpdts"

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 12 of 26
(1,904 Views)
Hi,

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
t
hen all items in Pcture 1!

It's a bit of 'pizza programming' but it just might work.

Regards,

Wiebe.




"Claudia Brand" wrote in message news:3c3c6945$1@pfaff.ethz.ch...
> For an experimental setup with humans where subjects have to track with
> 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!
>
>
>
0 Kudos
Message 10 of 26
(2,238 Views)
Hi,

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" wrote in message news:a1msig$7n3$1@news1.xs4all.nl...
> Hi,
>
> 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" wrote in message news:3c3c6945$1@pfaff.ethz.ch...
> > For an experimental setup with humans where subjects have to track with
> > 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!
> >
> >
> >
>
>
0 Kudos
Message 13 of 26
(1,904 Views)
Hmm... isn't my image already very simple? If you want, have a look at he
VI, I put it on our web server under
http://www.iha.bepr.ethz.ch/pages/leute/schnoz/balken5.vi

Claudia

> 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.
0 Kudos
Message 14 of 26
(1,904 Views)
Ok, I didn't know there was an onlie example.

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.
0 Kudos
Message 16 of 26
(1,903 Views)
Claudia,
I hope my advises will help you.

1. Try to use the maximum refresh rate of your monitor. Modern monitors use something like 100 Hz, so you don't need to update your picture faster than once a 10 ms.

2.I think you know that in cinema movies are shown with a rate equal to 25 frames per second. In other words human eye can not resolve the processes which are delayed less then 40 ms. So you need to update your picture only each 40 ms. If you try to do this faster you will not see some frames.

3. Use smooth updates.

4. Don't draw lines which are out of the picture region.

I have created an example in LV6. Try this. Try to change the "frames per second" and you will see the effect.

Oleg Chutko.
0 Kudos
Message 11 of 26
(1,904 Views)
Try: Right click on control. Select Advanced..Synchronous display.
0 Kudos
Message 17 of 26
(1,903 Views)
Claudia,

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 Dis
plays. 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.
0 Kudos
Message 18 of 26
(1,903 Views)
....


>
> 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
0 Kudos
Message 19 of 26
(1,903 Views)
Gentlemen

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 ve
rtical 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
0 Kudos
Message 20 of 26
(1,903 Views)