# bug #61532: "Automatic limits for current axis" button doesn't respect "axis tight"

 Submitter: Philip Nienhuis Submitted: Tue 23 Nov 2021 02:30:08 PM UTC Category: Plotting with OpenGL Severity: 3 - Normal Priority: 5 - Normal Item Group: Matlab Compatibility Status: In Progress Assigned to: None Originator Name: Philip Nienhuis Open/Closed:  * Open Release:  * dev Operating System:  * Any Fixed Release: None Planned Release: None
* Mandatory Fields

Add a New Comment Rich Markup

## Discussion

Sun 06 Feb 2022 05:46:24 PM UTC, comment #25:

@Panxto:
I used the following simple script:

## Step 1
a = rand (10, 10);
b = rand (10, 10);
plot (a(:, 1), a(:, 2), '*r');
hold on
grid on
plot (b(:, 1)+0.5, b(:, 2)+0.2, 'sg');
## Step 2
axis equal
## Step 3
axis tight

Matlab (r2020b):

• After step 1, we have a plot with unequal tick lengths but with "rounded" axes limits
• After step 2, the tick lengths are equal and X-limits are "tight" but not the Y-limits
• After step 3, also the Y-limits are "tight".

Then, when zooming in, the plotbox shape (aspect ratios) remain fixed. So when a zoom rectangle is selected with a shape wider (or taller) than the plot box, Matlab ensures that the X-axis (or Y-axis) fits the plot box width (or height) and increases the limits of the zoom rectangle Y-size (or X-size) so that it fits the plot box Y-axis (or X-axis).
When zoomed in, "axis tight" restores the original figure with the tight and equal axes.
When zooming out, Matlab refuses to zoom out beyond the original plot box.

Octave-8.0.0 (with patch from comment #13):

• After steps 1 & 2, same as Matlab
• After step 3: only the x-axis is "tight" (looks like a bug).

Then, when zooming in, Octave doesn't retain the original plot box ratios but instead accepts those of the zoom rectangle.
In that state, "axis tight" retains the new plot box size and again only makes the X-axis "tight". The Y-axis limits are expanded beyond the original Y-data. That looks like a bug as well, might be the same as above.
Furthermore, Octave happily zooms out beyond the original axis limits. When zooming out too far, it sometimes isn't able to zoom back in again - maybe due to single precision? (wild guess).

Octave-7.0.0 (from early Dec last year) behaves largely the same, be it that "axis tight" after zooming in retores the original figure just like Matlan does.

Just to be sure I've saved variables a and b in a mat file so one can try with the same data.

(file #52815)

Philip Nienhuis <philipnienhuis>
Sun 06 Feb 2022 02:14:27 PM UTC, comment #24:

I tagged the failing test with this bug number here:
https://hg.savannah.gnu.org/hgweb/octave/rev/00db74e19df4

Markus Mützel <mmuetzel>
Sun 30 Jan 2022 01:17:20 PM UTC, comment #23:

Running the first part of the test for `camlookat` in Matlab R2021a, I see the following:

>> [x, y, z] = peaks ();
s3 = surf (x, y, z/5);
hold on
[x, y, z] = sphere ();
s2 = surf (x/2, y/2+1.5, z/2+2);
s1 = mesh (x/2-4, 3*y, z/2 - 1);
axis equal
axis tight
>> get(gca, 'XLim')
ans =
-4.5000    3.0000
>> get(gca, 'YLim')
ans =
-3     3
>> get(gca, 'ZLim')
ans =
-1.5000    2.5000

In Octave hg id 4b367bf5eb16, I see:

>> [x, y, z] = peaks ();
s3 = surf (x, y, z/5);
hold on
[x, y, z] = sphere ();
s2 = surf (x/2, y/2+1.5, z/2+2);
s1 = mesh (x/2-4, 3*y, z/2 - 1);
axis equal
axis tight
>> get(gca, 'XLim')
ans =
-4.5000   3.0000
>> get(gca, 'YLim')
ans =
-3.7500   3.7500
>> get(gca, 'ZLim')
ans =
-3.2500   4.2500

The axes limits (in y- and z-direction) after `axis tight` seem to be much tighter in Matlab than in Octave.

Markus Mützel <mmuetzel>
Wed 26 Jan 2022 07:29:45 PM UTC, comment #22:

Hmm, AFAIK "plotboxaspectratio" nor "dataaspectratio" aren't used anywhere (that is, explicitly) in the (mapping package) scripts used to create the figure. All that happens in the custom script invoking those functions is plotting polygons and markers plus "axis tight", "grid on" and "box on". But I'll have a look just to be sure.
And of course I can set those properties to "auto" (?) and then see what happens in my custom scripts. I'll let you know.

As regards the example code you supplied: when zooming in Matlab changes the aspect ratio property (BTW thanks for the adequate name, I didn't know about it nor the property) but not the actual plot box itself; e.g., when zooming in to a very narrow / high rectangle across the plotted line, the plotboxaspectratio changes (yet X/Y ratio remains constant):

% original figure
>> get (gca, 'plotboxaspectratio')
ans =
2     1     1
>> get (gca, 'dataaspectratio')
ans =
1     1     1

% after zooming into narrow high rectangle
>> get (gca, 'plotboxaspectratio')
ans =
7.8232    3.9116    1.0000
>> get (gca, 'dataaspectratio')
ans =
1     1     1
>>

and the size of the plotbox (shape of the plotted area between the axes) remains a wide rectangle.
Also, Matlab refuses to zoom out further than the original figure, unlike Octave that seems to offer zooming out until infinity.
After "axis tight" and then zooming into a narrow wide rectangle, the plotbox aspectratio also remains the same as for the "axis tight" plotbox.

Philip Nienhuis <philipnienhuis>
Tue 25 Jan 2022 10:12:34 PM UTC, comment #21:

By simple script I did not mean a figure that I don't how you built :-). Anyways, I noticed that your axes have both "plotboxaspectratio" and "dataapsectratio" manual: in theory this fixes the ratio "diff (xlim)/ diff (ylim)" and you thus cannot expect tight limits in both directions unless your data have the exact correct extent. Am I wrong?

Can you reproduce your observations on the following simpler script? If so can you describe what Matlab does differently? How is the pbaspect affected by zooming for example?

figure ();

## An axes with both daspect and pbaspect fixed
axes ("dataaspectratio", [1 1 1], "plotboxaspectratio", [2 1 1])
hold on; box on;
plot (1:10);

Pantxo Diribarne <pantxo>
Tue 25 Jan 2022 09:22:31 PM UTC, comment #20:

I'll attach a "savefig" of the map I mentioned (a compressed an an uncompressed one), to experiment with, plus a simple .m file to calculate the min and max limits of all phenomena plotted in that map.

The explanation below of what I see happening is maybe a little complicated, apologies, it's sometimes hard to exactly describe visual things esp. on a non-native language.

What I see:
After zooming in along some rectangle (wide, or high) and then clicking the "Automatic limits ..." button, the contents are made "tight" relative to just one of the axis and the shape of the figure "rectangle" is retained. So the "tight" property only works on one of the axes, where I had expected the "tight" property to work on both axes.
Apparently the "tight" property of the axes is disabled by the zoom action and isn't preserved, or fully preserved, by the "Automatic limits ..." button.
A manual "axis tight" before your patch restores the original tight axes.
A manual "axis tight" with your latest patch keeps the zoomed-in shape, however.

Checking with Matlab r2022a prerelease, I see that the original shape of the drawing is always retained even when zooming in into a very wide, or very high, rectangle - Matlab apparently ensures that the largest zoom rectangle dimension fits in the picture. Clicking the "Restore original view" button restores the tight axes.

So Octave's behavior differs somewhat from that of Matlab, but TBH I don't care :-) I just expect the "axis tight" setting to survive zooming in and out and be restored by the "Automatic limits" button.

BTW Matlab refused to swallow the saved figure, complaining about compression and/or other issues. Should I enter a bseparate bug report for that or is that a known incampatibility?

(file #52730, file #52731, file #52732)

Philip Nienhuis <philipnienhuis>
Mon 24 Jan 2022 02:05:56 PM UTC, comment #19:

For the example I showed that is a bit hard; several mapping package scripts are involved. (Those scripts merely plot some lines + markers + a grid, but the build-up is complicated).

I'll see if I can cook up a simple example. If that doesn't portray the issues, I can try to make up some .mat file + simple script to do that; hopefully by tomorrow evening I have time for that.

Philip Nienhuis <philipnienhuis>
Mon 24 Jan 2022 12:02:44 PM UTC, comment #18:

@Phillip: For easier testing, can you provide a simple script and steps to reproduce the issues you are experiencing with 2D plots?

Pantxo Diribarne <pantxo>
Mon 24 Jan 2022 11:54:20 AM UTC, comment #17:

With the patch from comment #13, I see a few problems with XY (2D) plots. It may be that these already relate to the patch from comment #7 but I didn't note them till now, I'll check that later today (need to reinstall that Octave build).

• "axis tight" only seems to works for the Y-axis, the X-axis is too wide;
• (Maybe same issue as above?) when zooming in and then clicking the "Automatic limits ..." button, again just the Y-axis is "tight" but otherwise it looks like the shape of the zoomed-in part of the plot is retained. IOW if I zoom in to a rectangular very wide map shape, after the "Automatic limits ..." button click the Y-axis is "tight" but the X-axis is much too wide. Same for a very "high/narrow" zoom-in plot.
• When zooming out, the "Automatic limits for current axes" button doesn't work anymore, i.e., it won't zoom in back to fill the picture;

I've attached a pic (actually a composite map of boreholes and monitoring wells plotted over each other using "hold on") where in the left side the result of "axis tight" is shown and on the right what you get after zooming out (when "Automatic limits ..." doesn't zoom in anymore). In that latter pic you can see the boreholes that should make up the desired outer X,Y limits after "axis tight".

I don't know if it relevant: there is a ginput() call "hanging" on that map, but in earlier Octave builds this had no influence whatsoever on the zoom buttons and plot layouts. Clicking a zoom button simply "suspends" ginput (also in Matlab).

Philip Nienhuis <philipnienhuis>
Sun 23 Jan 2022 11:50:53 PM UTC, comment #16:

@Pantxo: The changes I made were approximately 3 years ago.  At the time, I don't think Matlab even had an axes property "xlimitmethod".  Looking at my own comments, I think Matlab used to switch "xlimmode" to manual when "axis tight" was given and Octave copied that.  I think it is fine to make Octave compatible with current Matlab behavior.

I tested "xlimitmethod" property with the three values "xtickaligned", "tight", "padded" and they work for me.

Rik <rik5>
Sun 23 Jan 2022 07:37:21 PM UTC, comment #15:

@arb: I fixed the typo in the doc here:

http://hg.savannah.gnu.org/hgweb/octave/rev/bf28cc6f2f46

Pantxo Diribarne <pantxo>
Sun 23 Jan 2022 07:29:47 PM UTC, comment #14:

CC'ing Rik.

Pantxo Diribarne <pantxo>
Sun 23 Jan 2022 07:27:54 PM UTC, comment #13:

Don't bother with comment #12. I ran the code in ML online and got approximately the same results in Octave with the attached patch.

@Rik: "hg blame" told me that you you were the one who had made the latest improvements to the "equal" option [1]. In the attached patch, I changed a bit the logic for "axis equal". In particular, I tried to follow ML doc and let the axes take as much space as possible rather than fixing the pbaspect to [1 1 1]. Is that OK?

I checked that none of the numerous bugs your change had fixed had reappeared, except the first one, bug #55619, which has already reappeared in Octave 6.4 for me.

[1] https://hg.savannah.gnu.org/hgweb/octave/rev/a7dfb00d5bf5

(file #52708)

Pantxo Diribarne <pantxo>
Sun 23 Jan 2022 01:54:59 PM UTC, comment #12:

Can someone with access to Matlab attach the two figure files generated by this script?

clf
plot (1:10, (1:10) * 2)
axis equal
print -dpng 2D_equal.png

clf
plot3 (1:10, (1:10) * 2, (1:10) * 3)
axis equal
print -dpng 3D_equal.png

Pantxo Diribarne <pantxo>
Sun 23 Jan 2022 10:33:41 AM UTC, comment #11:

@Panxto:
My apologies, I completely forgot about the follow-up actions for this bug report.
And thanks very much for fixing this; I tried at work (where I hit this the most with all kinds of maps and cross-sections) and it works perfectly now.

Philip Nienhuis <philipnienhuis>
Sat 22 Jan 2022 06:44:40 PM UTC, comment #10:

@arb: Thanks I'll do that.

@Dmitri: Thanks, I'll look into this issue later in the week.

Pantxo Diribarne <pantxo>
Sat 22 Jan 2022 09:50:30 AM UTC, comment #9:

I guess this diff should be applied:

diff -r cedb4046b4fb doc/interpreter/genpropdoc.m
--- a/doc/interpreter/genpropdoc.m      Sat Jan 22 10:47:45 2022 +0100
+++ b/doc/interpreter/genpropdoc.m      Sat Jan 22 10:48:31 2022 +0100
@@ -984,7 +984,7 @@
for the y-axis.  __modemsg__.  @xref{XREFylim, , @w{ylim function}}.";
s.valid = valid_2elvec;

-      case "xlimitmethod"
+      case "ylimitmethod"
s.doc = "Method used to determine the y axis limits when the \
@code{xlimmode} property is @qcode{\"auto\"}.  The default value, \
@qcode{\"tickaligned\"} makes limits align with the closest ticks.  With \
@@ -1031,7 +1031,7 @@
for the z-axis.  __modemsg__.  @xref{XREFzlim, , @w{zlim function}}.";
s.valid = valid_2elvec;

-      case "xlimitmethod"
+      case "zlimitmethod"
s.doc = "Method used to determine the z axis limits when the \
@code{xlimmode} property is @qcode{\"auto\"}.  The default value, \
@qcode{\"tickaligned\"} makes limits align with the closest ticks.  With \

A.R. Burgers <arb>
Sat 22 Jan 2022 12:22:03 AM UTC, comment #8:

It looks like this messed up "test camlookat"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 21 Jan 2022 09:42:26 PM UTC, comment #7:

I went ahead and pushed the patch from comment #5 to default:

http://hg.savannah.gnu.org/hgweb/octave/rev/4c0c02102ba9

Pantxo Diribarne <pantxo>
Mon 29 Nov 2021 10:09:30 PM UTC, comment #6:

Thanks for the prompt actions Panxto.

I'll try the patch somewhere this week.

Philip Nienhuis <philipnienhuis>
Mon 29 Nov 2021 09:50:23 PM UTC, comment #5:

I attached an updated version of the patch. I think the documentation would benefit from being reread by a better english speaker, but apart from that the new feature works well AFAICS.

(file #52389)

Pantxo Diribarne <pantxo>
Fri 26 Nov 2021 05:16:56 PM UTC, comment #4:

I attached a preliminary patch that adds and implements the x(y,z)limitmethod properties. TODO: document the new property and use it in the `axis` function.

(file #52355)

Pantxo Diribarne <pantxo>
Wed 24 Nov 2021 06:22:49 PM UTC, comment #3:

I think this has already been partly discussed in the past, but I can't find the bug report.

For anything other than "axis auto", Octave sets custom "x(y,z)lim" and consequently "x(y,z)limmode" becomes manual. In other words auto limits cannot be tight.

According to Matlab's documentation for axis [1], e.g. the "tight" option should leave "x(y,z)limmode" unchanged and instead change the "x(y,z)limitmethod" property to "tight".

We thus need to add and implement "x(y,z)limitmethod" properties [2] and let the axes graphics object compute limits accordingly.

Changing release to "dev" since this looks like an important change.

[1] https://nl.mathworks.com/help/matlab/ref/axis.html#buk989s-1-style
[2] https://nl.mathworks.com/help/matlab/ref/matlab.graphics.axis.axes-properties.html#budumk7_sep_mw_7623f06d-1795-480f-b113-e08ce76e79d5

Pantxo Diribarne <pantxo>
Tue 23 Nov 2021 05:15:05 PM UTC, comment #2:

Indeed, I missed mentioning "axis tight" after the plot command :-)
Thanks for spotting that.

What I think should happen is s/th along these lines:

• The first time one of the zoom buttons is clicked after any other plot command or button click, the current axis limits are saved somewhere. Then a "tight" or "auto" setting wouldn't matter, just as Matlab does and as -I think- an unwary user would expect;
• Upon (possibly repeatedly) zooming out or upon clicking the "Automatic limits" button, the plot zooms out until the saved axis limits completely fill the (sub)plot box; i.e., the original axis limits are restored.

• Any intermediate axis limits or view setting other than zooming in/out/restore (e.g., axis auto / set (<handle>, xlim, [ ...]) / etc.) wipes or resets the saved axis settings.

As to other properties requiring "stickyness", I currently have no idea except tilting (rotating). Any 2D plot can be tilted (rotated), I can imagine that after a lot of rotations a user loses track of up and down and wants to reset the plot to the original view angle.
I'd hope that once a solution is found for xlim/ylim, "stickyness" for other properties can be tackled in a similar fashion.

There's the old bug #44323 (also by me) about zooming in 3D plots, but for that case I think zooming out (or maybe better: changing camera position) beyond original axis limits could be quite useful for 3D plots.

Philip Nienhuis <philipnienhuis>
Tue 23 Nov 2021 03:39:24 PM UTC, comment #1:

Was an "axis tight" command missing from your "Steps to reproduce"?

axis (H, "auto")

for all axes in the current figure that aren't legends.  What can it do differently to respect the "axis tight" setting?

Should

axis (H, "auto")

by itself just not reset the "tight" setting?  Are there other properties that should also be "sticky"?

John W. Eaton <jwe>
Tue 23 Nov 2021 02:30:08 PM UTC, original submission:

(Admittedly merely cosmetic, but for complicated plots and esp. maps (mapping package) I find Octave's behavior quite annoying)

Steps to reproduce:

Type:
xm = 7; plot (-xm:xm, sin (-xm:xm))
==> Plot shows up

Zoom in somewhere in the plot (isn't even required)

Click "Automatic limits for current axis" button

==> Plot again has "loose" limits.

Same for Octave-5.2.0, so this is an old issue.

Matlab (I tested with r2014a & r2020b) does this "right", or maybe better: "as expected":
r2014a seems to have no "Automatic limits" button, but the "Zoom out" button, clicked often enough, in the end produces the original plot with tight axis limits.
r2020b's "Restore original view" does likewise.

Along the way, noted another incompatibility:
Octave allows zooming out much further than the original axis limits and behaves quite unpredictably at that. Sometimes (when clicking the zoom out button repeatedly) it suddenly zooms back in to original (loose) view, sometimes it zooms out two or three times and only then suddenly zooms back in to original (loose) view.
Matlab consistently zooms out until the original plot size is restored, tight or loose.

I had a look in axis.m, I think the relevant code there looks quite involved. Maybe easier fixed using hidden properties for original axis limits settings? ("original" meaning "before zooming in")

Philip Nienhuis <philipnienhuis>

## Attached Files

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

Attach Files:

Comment:

Attached Files
file #52815:  bug61532_limits_data.mat added by philipnienhuis (4KiB - application/octet-stream)
file #52730:  testmapc.fig added by philipnienhuis (364KiB - application/octet-stream)
file #52731:  testmaplims.m added by philipnienhuis (361B - text/plain)
file #52732:  testmap.fig added by philipnienhuis (1MiB - application/octet-stream)
file #52708:  bug61532_v3.patch added by pantxo (4KiB - text/x-patch)
file #52389:  bug61526-v2.patch added by pantxo (25KiB - text/x-patch)
file #52355:  bug61532.patch added by pantxo (15KiB - text/x-patch)

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List
• -email is unavailable- added by mmuetzel (Posted a comment)
• -email is unavailable- added by rik5 (Posted a comment)
• -email is unavailable- added by pantxo
• -email is unavailable- added by arb (Posted a comment)
• -email is unavailable- added by dasergatskov (Posted a comment)
• -email is unavailable- added by pantxo (Posted a comment)
• -email is unavailable- added by jwe (Posted a comment)
• -email is unavailable- added by philipnienhuis (Submitted the item)
•

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only group members can vote.

## History

Date Changed by Updated Field Previous Value => Replaced by
2022-02-06 philipnienhuis Attached File- Added bug61532_limits_data.mat, #52815
2022-02-06 mmuetzel StatusReady For Test In Progress
2022-01-25 philipnienhuis Attached File- Added testmapc.fig, #52730
2022-01-24 philipnienhuis Attached File- Added bug#61532_jan24#1.png, #52717
2022-01-23 rik5 Item GroupIncorrect Result Matlab Compatibility
2022-01-23 pantxo Carbon-CopyRemoved rik -
2022-01-23 pantxo Attached File- Added bug61532_v3.patch, #52708