Quantcast

Figure handle is very slow, saving impossible

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Figure handle is very slow, saving impossible

esche
Hello,
I'm a very beginner in octave. I want to handle big geotif images and do
multi spectral analysis of the channels. Everything seems to work very
fine but when it comes to visualizing with surfaceplot function the
Figure Window reacts very slow and with poor performance.
is there a possibility to improve this behavior?
And saving the image is not possible it will result in a black image.
Images with a size of 6700 X 7100 will not be displayed at all. Just
smaller Imagesizes will be shown at acceptable velocity (1000X1000).
What are the reasons for that? Is there a possibility to back a more
powerfull imageviewer?
I'm using Debian 8 with compiled libraries of
Graphicsmagick(depth32),
osmesa32,
atlas,
suitesparse,
arpack,
qrupdate.
to compile atlas 64 bit in debian I to needed to do adjustments in the
make.inc file. Building with b 64 (as described in the, very good
documentation) was not enough for me. I will do a new post on that if
someone is interested.
Back to the topic, has anyone experience in visualizing large images in
octave?
greets christoph

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

Kire Pudsje


On Wed, Apr 5, 2017 at 5:12 PM, christoph <[hidden email]> wrote:
Hello,
I'm a very beginner in octave. I want to handle big geotif images and do multi spectral analysis of the channels. Everything seems to work very fine but when it comes to visualizing with surfaceplot function the Figure Window reacts very slow and with poor performance.
is there a possibility to improve this behavior?

As to speed, just think about it, with a 7000^2 dataset of doubles you would need to transfer 400 MB to generate each image.
For data analysis, I can imagine, you would need the resolution,  but for displaying, some decimation would definitely help I think. Your monitor cannot display it anyway. Even when printing, just think about it, when just performing an imagesc, at 300 dpi, you would need to print a poster of 600mm x 600mm (2ft x 2ft). With the added 3d effects of surface, you might need 1 square meter.


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

Francesco Potortì
christoph:
>> I'm a very beginner in octave. I want to handle big geotif images and do
>> multi spectral analysis of the channels. Everything seems to work very fine
>> but when it comes to visualizing with surfaceplot function the Figure
>> Window reacts very slow and with poor performance.
>> is there a possibility to improve this behavior?

Kire Pudsje:
>As to speed, just think about it, with a 7000^2 dataset of doubles you
>would need to transfer 400 MB to generate each image.

If it is b&w.  More if with colours.

Anyway, if an image should be generated ans saved on disk, it's useful
to spare Gnuplot the burden to display it: use

set(gcf, 'visible', 'off');

before generating the plot, and then save it to disk using print

--
Francesco Potortì (ricercatore)        Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

esche

Thank you for your fast answer,

yes I do understand, but 400MB of data should not be of any concern on a modern machine, with a graphic card which has let's say 3 gigabyte of memory?

Concerned my printing problem.

It turns out that my Figure looks like this on the screen.




And after saving it e.g. printing it, like this.


greets christoph


On 2017-04-05 18:23, Francesco Potortì wrote:
set(gcf, 'visible', 'off')


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

Kire Pudsje


On Wed, Apr 5, 2017 at 7:39 PM, christoph <[hidden email]> wrote:

Thank you for your fast answer,

yes I do understand, but 400MB of data should not be of any concern on a modern machine, with a graphic card which has let's say 3 gigabyte of memory?

Concerned my printing problem.

It turns out that my Figure looks like this on the screen.


The amount of memory is not the issue, but for a 'surface' you are constantly sending data from the CPU to the graphics card. Probably the CPU has to do a little work as well, so DMA is probably not happening. The cache will probably be flushed al the time.
Games also still have a problem uploading large amounts of data, but they usually tend to 'hide' this by using (nonskippable) cutscenes

I see that you are not using  the 'perspective' view. then why not use imagesc instead? This should be faster.
Also try 'saving' the image with print -d and try using any of the other devices, pdf, png, or any of the cairo devices, ...

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

esche

Hello,

I tried imagesc and indeed that's way faster then surfplot! Thanks a lot for this advice.  Concerning the print problem.--->>

I tried -dpng and also -djpeg as well as -dpdf all failed, if I have a color(RGB band) picture to print.

But in case of  grascale image(one band) it works properly!

Has this anything to do with osmesa? because test on osmesa failed when I did "make check". I read a thread about a problem with osmesa and nvidia driver. Probably that's the issue? 


cheers christoph


On 2017-04-05 21:01, Kire Pudsje wrote:


On Wed, Apr 5, 2017 at 7:39 PM, christoph <[hidden email]> wrote:

Thank you for your fast answer,

yes I do understand, but 400MB of data should not be of any concern on a modern machine, with a graphic card which has let's say 3 gigabyte of memory?

Concerned my printing problem.

It turns out that my Figure looks like this on the screen.


The amount of memory is not the issue, but for a 'surface' you are constantly sending data from the CPU to the graphics card. Probably the CPU has to do a little work as well, so DMA is probably not happening. The cache will probably be flushed al the time.
Games also still have a problem uploading large amounts of data, but they usually tend to 'hide' this by using (nonskippable) cutscenes

I see that you are not using  the 'perspective' view. then why not use imagesc instead? This should be faster.
Also try 'saving' the image with print -d and try using any of the other devices, pdf, png, or any of the cairo devices, ...


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

Kire Pudsje


On Wed, Apr 5, 2017 at 11:12 PM, christoph <[hidden email]> wrote:

Hello,

I tried imagesc and indeed that's way faster then surfplot! Thanks a lot for this advice.  Concerning the print problem.--->>

I tried -dpng and also -djpeg as well as -dpdf all failed, if I have a color(RGB band) picture to print.

But in case of  grascale image(one band) it works properly!

Has this anything to do with osmesa? because test on osmesa failed when I did "make check". I read a thread about a problem with osmesa and nvidia driver. Probably that's the issue? 


Please prepare a minimal scripts that generates the problem. The following

imagesc(peaks(7000));
print -dpng test.png
print -dpdf test.pdf

works for me

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

esche

Here are my scripts,

Case1:

pic_1=imread("/opt/octave/pics/clipped.tiff")

........

.......

hold "on"
imagesc(pic_1)
plot([CoordsPoints{:}](2,:),[CoordsPoints{:}](1,:),"ro")
hold "off"

print -dpng /opt/octave/pics/test.png ----->>>fails!!

notice:

                      Dimention       class

<<<<pic_1   4800x3600x3  uint8>>>>

Case2:

pic_2=imread("/opt/octave/pics/clipped_grayscale.tiff")

........

.......

hold "on"
imagesc(pic_2)
plot([CoordsPoints{:}](2,:),[CoordsPoints{:}](1,:),"ro")
hold "off"

print -dpng /opt/octave/pics/test.png ----->>>works!!

                      Dimention       class

<<<<pic_2   4800x3600      uint8>>>>




 


On 2017-04-06 01:02, Kire Pudsje wrote:


On Wed, Apr 5, 2017 at 11:12 PM, christoph <[hidden email]> wrote:

Hello,

I tried imagesc and indeed that's way faster then surfplot! Thanks a lot for this advice.  Concerning the print problem.--->>

I tried -dpng and also -djpeg as well as -dpdf all failed, if I have a color(RGB band) picture to print.

But in case of  grascale image(one band) it works properly!

Has this anything to do with osmesa? because test on osmesa failed when I did "make check". I read a thread about a problem with osmesa and nvidia driver. Probably that's the issue? 


Please prepare a minimal scripts that generates the problem. The following

imagesc(peaks(7000));
print -dpng test.png
print -dpdf test.pdf

works for me


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

Kire Pudsje


On Thu, Apr 6, 2017 at 7:53 AM, christoph <[hidden email]> wrote:

Here are my scripts,

Case1:

pic_1=imread("/opt/octave/pics/clipped.tiff")

........

.......

hold "on"
imagesc(pic_1)
plot([CoordsPoints{:}](2,:),[CoordsPoints{:}](1,:),"ro")
hold "off"

print -dpng /opt/octave/pics/test.png ----->>>fails!!

notice:

                      Dimention       class

<<<<pic_1   4800x3600x3  uint8>>>>



I do not experience problems.
I tried to make a self contained version of your script.
The following should fail for you.

sz = [4800,3600];
pic1=peaks(max(sz));
pic1(:,:,2) = pic1';
pic1(:,:,3) = fliplr(pic1(:,:,1));
pic1=pic1(1:sz(1),1:sz(2),:);
imagesc(pic1);
hold on;
plot(sz(2)*rand(100,1), sz(1)*rand(100,1),'ro');
hold off;
print -dpng test.png

Could you verify if it is size related?
What happens if you choose sz = [480,360] ?

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

esche

Hello,

your script works for me as well. So the problem is, printing seems to fail with uint8 class but works well with doubles.

so

pic_1=im2double(pic_1)

has done the job in my case!

I just don't know why?

thank you so much for your help!


On 2017-04-07 18:16, Kire Pudsje wrote:


On Thu, Apr 6, 2017 at 7:53 AM, christoph <[hidden email]> wrote:

Here are my scripts,

Case1:

pic_1=imread("/opt/octave/pics/clipped.tiff")

........

.......

hold "on"
imagesc(pic_1)
plot([CoordsPoints{:}](2,:),[CoordsPoints{:}](1,:),"ro")
hold "off"

print -dpng /opt/octave/pics/test.png ----->>>fails!!

notice:

                      Dimention       class

<<<<pic_1   4800x3600x3  uint8>>>>



I do not experience problems.
I tried to make a self contained version of your script.
The following should fail for you.

sz = [4800,3600];
pic1=peaks(max(sz));
pic1(:,:,2) = pic1';
pic1(:,:,3) = fliplr(pic1(:,:,1));
pic1=pic1(1:sz(1),1:sz(2),:);
imagesc(pic1);
hold on;
plot(sz(2)*rand(100,1), sz(1)*rand(100,1),'ro');
hold off;
print -dpng test.png

Could you verify if it is size related?
What happens if you choose sz = [480,360] ?


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Figure handle is very slow, saving impossible

Kire Pudsje

On Wed, Apr 12, 2017 at 3:57 AM, christoph <[hidden email]> wrote:

Hello,

your script works for me as well. So the problem is, printing seems to fail with uint8 class but works well with doubles.

so

pic_1=im2double(pic_1)

has done the job in my case!

I just don't know why?

Might be related to the cdatamapping property.

please modify e.g. my script to a non-working version and file a bug report if you still think it is an error

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Loading...