bugGNU Octave - Bugs: bug #58001, All points in plot sent to output...

 
 

bug #58001: All points in plot sent to output resulting in very large files

Submitted by:  None
Submitted on:  Mon 16 Mar 2020 05:46:54 PM UTC  
 
Category:  Plotting Severity:  1 - Wish
Priority:  1 - Later Item Group:  Matlab Compatibility
Status:  Wont Fix Assigned to:  None
Originator Name:  ADAM MAJEWSKI Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 20 Sep 2020 03:01:07 PM UTC, comment #3: 

I agree this should be a won't fix, at least for default behavior. But it is a nice wish list item for a plot option or maybe separate function to "intelligently" dedensify plot data.  is there an existing routine out there that could do this?  Something that would check for e.g, data on a line to a "won't move any pixels" degree, and trim those out, etc.  It would be hard without an integrated plot routine like MATLAB has, where the routines could "talk" to know what target pixel size was based on the print details. But maybe if you're calling the function its enough to just specify a desired resolution.

Background-
I ran into a similar thing very recently when putting a figure heavy document based on data in MS Excel (yes I know). The data was generated in SPICE for a nonlinear circuit, and was set to save all data points (that software seems has default plot data compression that meets the "intelligent" description above, butit was off for generating this data and it's not open software).  At startup and nonlinear transitions the 30s long simulation would have a couple thousand points at ~1e-7s time steps.  I usually export excel plots as EMF vector graphics to avoid pixellation, but excel keeps the full dataset, including data outside the plot range. Even compressed each figure was adding a couple MB to the MS Word filesize.  The plot scale was large enough and most regions smooth enough that an intelligently chosen 1-200 points would likely have been indistinguishable.  BUT a blind uniform spacing would have lost shape in key areas. After the easy manual data trimming, which still took forever, I'm currently working with a 60MB word doc that if all pics were replaced with PNG would probably be <5MB guessing by the sizes in the docx container.

Nicholas Jankowski <nrjank>
Tue 17 Mar 2020 05:49:52 PM UTC, comment #2: 

This is known Octave behavior.  Whether you want to want to call it a bug or a feature is down to interpretation.  The same behavior is also exhibited onscreen.  The number of points that Matlab passes through their plotting pipeline to OpenGL for rendering is based on the resolution and zoom level of the screen.  Octave takes the easy approach and just plots everything.  The same thing happens for printing (since it is based on the plot).  If you have a lot of points then every one will get sent to the eventual plot.

Many Octave users prefer control over ease of use.  With that frame of mind, it is prefered to filter the number of points in a manner that is most appropriate for your data, rather than relying on an sort of automated algorithm which can't be best for all datasets.

Tentatively marking as "Won't Fix".

Rik <rik5>
Project Administrator
Tue 17 Mar 2020 08:06:51 AM UTC, comment #1: 

The data vector you pass to the plot command has 5 million points. If the resulting file has 78 MB, this means you have about 16 bytes per point: a space, a comma, two decimal points, leaves you 6 significant digits per coordinate. This is very reasonable.

On the other hand, the matlab file (which seems to have only 15.9 kB on my side) has first used the most aggressive white space, comma, and leading zero elimination conceivable (I hadn't known that svg allows that, but it really does) making it quite hard to read and a small nightmare to parse the points back (I really do that sometimes). I don't know if I think that a good idea, but in any case this would give you savings on the order of 25%. No, matlab has also decided that you need only one data point per quarter of a nominal pixel horizontal distance (where your figure is 560 pixels wide) apart from the vertical maxima and minima, and has deleted all points in between. You could have achieved exactly the same result (apart from the whitespace ... elimination mentioned above) by two lines of preprocessing your data:

x=0.0:0.000001:5.0;
y=sin(exp(x));
ind=unique([find(y(2:end-1)>y(3:end)&y(2:end-1)>=y(1:end-2))+1 find(y(2:end-1)<y(3:end)&y(2:end-1)<=y(1:end-2))+1 (1:2500:length(y))]);
plot(x(ind),y(ind));

gives me a 34.2 kB file. And very probably there are free online out there that you can pass your svg files to and that remove redundant data points, optimally even with a specified tolerance. But I would not want such a thing to happen automatically -- is there an option to turn this off, or is it impossible in matlab to generate an svg file with the exact nodes that you specify?

Michael Leitner <mleitner>
Mon 16 Mar 2020 05:46:54 PM UTC, original submission:  

Hi
I have made svg file :
https://commons.wikimedia.org/wiki/File:Graph_of_sin(exp(x))_function.png

using code:
x=0.0:0.000001:5.0;
plot(x,sin(exp(x)));
xlabel("x");
ylabel("sin(exp(x))");
title("Graph of function sin(exp(x))");
print -dsvg "a.svg"

The size of svg file is 78.0 MB

Using matlab code :

print('-dsvg',strcat('Graph of sin(exp(x)) function','.svg'))

it is 41 KB large
https://commons.wikimedia.org/wiki/File:Graph_of_sin(exp(x))_function.svg

https://github.com/scour-project/scour/issues/238

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mleitner (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-03-17 rik5 Severity3 - Normal => 1 - Wish
        Priority5 - Normal => 1 - Later
        StatusNone => Wont Fix
        Release4.2.2 => dev
        Summaryto big size of svg => All points in plot sent to output resulting in very large files

    Back to the top


    Powered by Savane 3.5