octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getframe() alternatives


From: Philip Nienhuis
Subject: Re: getframe() alternatives
Date: Wed, 05 Oct 2011 19:45:46 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

Ben Abbott wrote:

On Oct 5, 2011, at 9:07 AM, PhilipNienhuis wrote:

While porting a ML script that creates a video clip to Octave I stumbled upon
the lack of getframe().
The OF video package (or should it be: the image package) still lacks that.

The reason I ask on Maintainers is that I seek for coding advice.

For now I have the following clumsy solution for adding successive screen
images (plots) to an avi stream:

Alternative 1
==========
<for ...>
  <...create plot with filled contours, pimp it...>
  print ("tmp.fig", "-dppm");
  HH = im2double (imread ("tmp.fig"));
  aviobj = addframe (aviobj, HH);
<endfor>

...which works. But of course, very slowly.
(FYI: im2double() (OF image pkg) converts to double and scales to [0..1]
just as addframe() (OF video pkg) requires.)


Alternative 2
==========
I figured (but I may be wrong) that skipping the disk write/read portions
may save considerable amounts of time. So would it be possible to have
print() write to a pipe rather than file, and imread() read from a pipe
rather than file? That might be the most platform-independent "kludge".


Alternative 3
==========
Obviously a genuine binary getframe() solution is preferable. Apart from
skipping disk I/O it would avoid double graphics format conversion as well
and simply transfer the screen image representation in video memory into a
bitmap in the form of a 3D array.

On Windows (where I work on for this ML script) this should be a breeze once
the screen API graphics handle is available. FLTK would be the way to go
then; Gnuplot is a separate prog so access to its internals is probably a
bit hard.
Over a decade ago I once made something like that for a screen grab routine
in assembly language; however yesterday a google search turned up dozens of
much better designed examples in C / C++ / C# etc.
However I have no idea where to search for the graphics handle in the
Octave/FLTK sources. Or is it hidden in the FLTK libs and never used
directly by Octave?

On Linux I wouldn't know how to proceed, but I presume graphics handles are
also used there.

Is there any advice on how to most efficiently get a bitmap/3D array out of
an Octave graphics handle? perhaps even code snippets?

Thanks,

Philip

I expect the fastest approach would be to capture the image data directly from 
OpenGL. That would create mean the gnuplot backend wouldn't work for 
getframe(), but I think that is ok in the long run.

Unfortunately, I don't know enough about the OpenGL internals to be of any help 
in how to grab the image data. But I did dig up the link below which Jordi 
posted to the list in 2010.

        http://www.opengl.org/resources/faq/technical/miscellaneous.htm#misc0050

Looks like a good place to start?

Yes this looks helpful, thank you very much.

Of course there's more to it, like finding out what params glReadPixels() needs and first of all the extent of the OpenGL pixel map. Hmmm google is my friend here...

Well, something to sort out in the next weeks.

Philip


reply via email to

[Prev in Thread] Current Thread [Next in Thread]