[Octave-bug-tracker] [bug #59731] wrong colorbar length when aspect ratio is manual

[Hg200]

Follow-up Comment #7, bug #59731 (project octave):

I have attached a file to make a colorbar investigation. It is advisable to
run the file once under Octave and then with Matlab and then compare the
output. Danger, many files will be generated!

Some conclusions are:

i.) In Matlab, in a view(3) plot the colorbar is almost as high as the window
size. The colorbar does not seem to depend on the visible image size of the
axes in the plot window. It also looks like it does not depend on whether the
aspect ratio is "auto" or "manual". If we remove the "messy code" from
colorbar.m (see comment #4 and comment #5) then everything becomes better in
Octave. Example code:

++
figure ('position', [50, 100, 300, 600]);
hax = axes ();
[xx, yy] = meshgrid (linspace (-8, 8, 41));
r = sqrt ((xx).^2 + (yy).^2);
zz =  sin (r) ./ r;
surf (xx, yy, zz, 'edgecolor', 'none');
set (gcf, 'color', 'c');
view (3);
daspect ([1, 1, 1]);
hcb = colorbar ('east');
--

ii.) For view(2) plots in Matlab, the colorbar is scaled based on the
width/height of the visible image of the axes in the plot window.  When the
color bar is at the "outside" position, the length exactly matches the size of
the image of the axes. Currently Octave's colorbar.m more or less honors this
behavior. However, this feature breaks if we delete the "messy code" from
colorbar.m. Example plot:

++
figure ('position', [50, 100, 600, 200]);
hax = axes ();
[xx, yy] = meshgrid (linspace (-8, 8, 41));
r = sqrt ((xx).^2 + (yy).^2);
zz =  sin (r) ./ r;
surf (xx, yy, zz, 'edgecolor', 'none');
set (gcf, 'color', 'c');
view (2);
daspect ([1, 1, 1]);
hcb = colorbar('south');
--

iii.) Difficulties: Currently, the Octave colobar algorithm calculates the
position and length of the colorbar based on the bounding box (= hax,
'position'). The problem with this approach is that we cannot easily obtain
the actual width/height of the visible axes image in the plot window,
especially when we are in 3D: The actual aspect ratio of the image is
determined by the opengl projection and view transformation, while the
bounding box size is unaffected, even if we rotate the image. Example: The
following code sequence returns the same bounding box coordinates, regardless
of whether the aspect ratio is set to "manual" or "auto":

++
figure;
hax = axes ();
[xx, yy] = meshgrid (linspace (-8, 8, 41));
r = sqrt ((xx).^2 + (yy).^2);
zz =  sin (r) ./ r;
surf (xx, yy, zz, 'edgecolor', 'none');
set (gcf, 'color', 'c');
set (hax, "units", "pixels");
get (hax, 'position')
daspect ([1, 1, 1]);
get (hax, 'position')
--

References:
https://wiki.octave.org/User:Hg200

iv.) If we switch the aspect ratio in the toolkit gnuplot to "manual", then we
obtain only garbage in the plot window even when there is no colorbar:

++
graphics_toolkit('gnuplot');
sombrero;
daspect ([1, 1, 1]);
--

I would vote to not maintain gnuplot any more, at least concerning this bug
report.

If we want to keep feature ii.), we need some minimal corrections regarding
the "aspect ratio" in "manual mode" when a view(2) plot is created. So we need
to merge some of the "messy code". However, I still don't understand what
exactly happens in "_actual_axis_position_.m".

Anyway, so far my evaluations.





(file #50582)
    _______________________________________________________

Additional Item Attachment:

File name: colbartest.m                   Size:1 KB
    <https://file.savannah.gnu.org/file/colbartest.m?file_id=50582>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59731>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/