octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #36594] imshow error after changing colormap


From: Rik
Subject: [Octave-bug-tracker] [bug #36594] imshow error after changing colormap
Date: Sun, 23 Feb 2014 16:22:18 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0

Follow-up Comment #4, bug #36594 (project octave):

This is what I thought.  The problem is not in the actual rendering by OpenGL
but in Octave's selection of the axis limits.  Octave gets it right when you
actually call 'image'.  See this code section from image.m


      px = __image_pixel_size__ (h);

      if (xdata(2) < xdata(1))
        xdata = fliplr (xdata);
      elseif (xdata(2) == xdata(1))
        xdata = xdata(1) + [0, columns(img)-1];
      endif
      if (ydata(2) < ydata(1))
        ydata = fliplr (ydata);
      elseif (ydata(2) == ydata(1))
        ydata = ydata(1) + [0, rows(img)-1];
      endif
      xlim = xdata + [-px(1), px(1)];
      ylim = ydata + [-px(2), px(2)];

      ## FIXME -- how can we do this and also get the {x,y}limmode
      ## properties to remain "auto"?  I suppose this adjustment should
      ## happen automatically in axes::update_axis_limits instead of
      ## explicitly setting the values here.  But then what information is
      ## available to axes::update_axis_limits to determine that the
      ## adjustment is necessary?
      set (hax, "xlim", xlim, "ylim", ylim);


__image_pixel_size__ is a C++ routine that, for the test image of 4 pixels,
returns 0.5.  The axis limits are then set to the tight data limits (xdata)
+/- the pixel size which results in limits of [0.5, 4.5].  This is perfect.

'axis image' is equivalent to 'axis tight' followed by 'daspect ([1 1 1])'. 
One quick fix would be to change axis.m to use the same calculation routine
for axis limits as above.  Even better would be to change the
__get_tight_lims__ routine in axis.m so that it would take account of the
graphic object type.  For all object types which were not images (line,
surface, etc.) it could use the limits of the data.  For image types it would
perform the calculation above.

Finally, there is that suspicious FIXME note in the code.  Octave sets the
axis limits manually when doing a call to image().  What does Matlab do?


im=uint8([0 1 2 0; 0 1 2 0; 0 1 2 0; 0 1 2 0]);
map=[0 0 0; 1 0 0; 0 1 0; 0 0 1; 1 1 0; 0 1 1 ; 1 0 1];
im_dbl = double (im) + 1;
colormap (map);

image ([], [], im_dbl);
get (gca, 'xlimmode')
axis tight
get (gca, 'xlimmode')
axis image
get (gca, 'xlimmode')


Is the xlimmode 'manual' or 'auto'?



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36594>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]