Can't save plots of larger matrices

[Stephan Paukner]

When I plot a 100x100 matrix I can save the plot by calling
    octplot_command ('print', 'testimg5.ps')
or
    print -deps testimg5.ps
but e.g. for a 480x480 matrix I get an error message repeated every second:
    GL2PS info: OpenGL feedback buffer overflow

I have to kill octplot and also octave because I don't get back to the prompt. How can I grant the saving routine more memory? Or what exactly could be the reason?

Thanks

Stephan

[Shai Ayal]

Stephan,

octplot tries to increase it's memory in steps of 1MB every time you see the message.
Can you track octplot's memory usage? (in linux, try top, than press "M") see how large it gets.
ALso, please can you tell us your OS and what octplot/octave version you are using, also are they self compiled or pre-compiled?

Shai

[Stephan Paukner]

I use Debian Etch and its packages octave2.9 (2.9.9-8etch1) and octave2.9-forge (2006.07.09+dfsg1-8), octplot is a self-compiled 0.3.9.
When printing a 'pcolor' plot of a 240x240 matrix, the message raises 5 times, after few minutes the VIRT (virtual memory) raises to >270M, and the resulting PNG image file size is 50.4K.
For a 480x480 matrix, the message raises 20 times, VIRT reaches 1024M after 15 minutes and the system starts to swap (I have 1G mem and 3G swap). I continue watching for another 15 minutes until I kill octplot at a VIRT of 1515M.

It isn't quite useful to have such a system usage for just having labeled axis at the image border or a colorbar. If I do an 'imagesc' of the same 480x480 matrix and save the bare image with the launched image viewer, this takes only one second and results in a filesize of 66.5K. Is there a better way to save octplot's plots?

[Shai Ayal]

The process that happens when you print to a PNG:
first a postscript file is created by octplot. then the postscript is converted to png using ghostscript with the requested resolution (chaged by the -r parameter to print, default 150 dpi).
postscript is not very good at compressing bitmaps and would need a few lines of text for each square so that should give you ~ 100*240*240/1024=5MB postscript file or ~22MB for the 480x480 matrix. The next step of converting to PNG might be very memory intensive since the resulting file might be very high resolution.

Can you please try the and report the outcome of the following:
1) the resolution of the 50.4K PNG file produced from the 240x240 matrix
2) make a ps file: print("-dps","test.ps") and report it's size
3) try making a lower resolution png print("-dpng","-r75",test.png")

Thanks
Shai

[Stephan Paukner]

Hi, sorry for late reply.

> img=rand(240);
> pcolor(img)
> tic; print("-dps","test.ps"), toc
GL2PS info: OpenGL feedback buffer overflow [5 times]
Elapsed time is 108.418144 seconds.
--> 12.3MB

> tic; print("-dpng","test.png"), toc
GL2PS info: OpenGL feedback buffer overflow [5 times]
Elapsed time is 118.973335 seconds.
--> 112.4kB, 833x681 pixels

@3:
> tic; print("-dpng","-r75","test2.png"), toc
GL2PS info: OpenGL feedback buffer overflow [5 times]
Elapsed time is 118.008553 seconds.
--> 124.7kB, 417x341 pixels

So there isn't that much difference in the computing time between PS and PNG.

[Shai Ayal]

So, the problem lies in creating the 12MB ps file. I'm afraid I have no immediate solution for you. This problem is a consequence of me focusing on making good quality vector "hardcopy" so that line plots will appear good.

This means that the octplot object tree is converted to a vector ps file (made from 240x240 rectangles + stuff for the axes), which takes up a lot of disk space.
Then, if you request a png or jpeg file, the ps file is rasterized to a bitmap and compressed. This process also has the additional drawback of the pixels in the png file not corresponding directly to the original pcolor pixels.

I actually have no idea on how to solve this ...

Sorry,
Shai