bugGNU Octave - Bugs: bug #54610, imagesc doesn't implement ranges...

 
 

bug #54610: imagesc doesn't implement ranges properly

Submitter:  Brent Baccala <baccala>
Submitted:  Fri 31 Aug 2018 09:50:09 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.4.1 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 07 Sep 2018 03:53:28 PM UTC, comment #5: 

@Pantxo: I pushed your patch to the stable branch here (https://hg.savannah.gnu.org/hgweb/octave/rev/9578af67a0d4).  Very minor modifications like changing "two element vector" to "2-element vector" and using two spaces after a perio which ends a sentence.

Closing report.

Rik <rik5>
Group administrator
Fri 07 Sep 2018 08:56:52 AM UTC, comment #4: 

@Rik: Is the attached patch ok?

(file #44952)

Pantxo Diribarne <pantxo>
Group Member
Thu 06 Sep 2018 04:34:11 AM UTC, comment #3: 

I'm not sure it is worth the trouble.  This is already an edge case, so maybe just document that it is abnormal.

Rik <rik5>
Group administrator
Sun 02 Sep 2018 08:29:52 PM UTC, comment #2: 

I requested some code to be run in Matlab (see http://octave.1599824.n4.nabble.com/Re-Request-for-test-in-Matlab-tp4689265.html) and my conclusion is that the current Octave behavior is odd but not as much as Matlab's


h = imagesc (1:10);
get (h, 'ydata')


This returns a scalar value 1 while Octave returns [1 1]. We should probably do the same and document what a scalar value means for ydata and also that a two element vector indicates the coordinates of the centers of corner pixels.


imagesc([-1,1], [-5, 5], 1:10)


Matlab renders the image as if the horizontal boundaries where at [-15 15] while Octave renders between [-5.5 and 5.5]. We surely don't want to copy Matlab here, but I'd be in favor of rendering between [-5 5] and documenting this corner case where for 1 pixel high images, 'ydata' indicates the coordinates of the boundaries, not the centers. Thoughts?

Pantxo Diribarne <pantxo>
Group Member
Sat 01 Sep 2018 07:20:20 PM UTC, comment #1: 

Yes it is a bit odd case. The x and y arguments in image and imagesc functions are supposed to be equivalent to setting the image object's "xdata" and "ydata" respectively. The ML doc says

>> imagesc('XData',x,'YData',y,'CData',C) specifies the image location. This syntax is the low-level version of imagesc(x,y,C).


Now "xdata" and "ydata" are supposed to be two element vectors that indicate the position of the center of the pixels at the corners of the image.

In the original example, setting a two element vector for a one pixel high image makes no sense (there is only one center in the the y direction). It would be interesting to know if Matlab produces an error or interprets the [ymin ymax] as the coordinates of the boundaries (and puts the center at (ymin+ymax)/2).

Pantxo Diribarne <pantxo>
Group Member
Fri 31 Aug 2018 09:50:09 PM UTC, original submission:  

The `imagesc` documentation states:

The axis values corresponding to the matrix elements are specified in x and y, either as pairs giving the minimum and maximum values for the respective axes, or as values for each row and column of the matrix img.

`imagesc` doesn't seem to be properly respecting the limits when they're given as pairs.  For example,


figure()
xlim([-1,1])
ylim([-1,1])
imagesc([-1,1], [-0.5, 0.5], 1:10)


What I expect is a colored band in the middle of the figure, since I specified the y range as a pair giving -0.5 and 0.5 as the minimum and maximum values, respectively, yet the figure's y limits go from -1 to 1.

What I get is a colored band that fills the entire figure.  I've tested this with Octave 4.4.1 on Ubuntu 18.04.

I've looked at the code, and I think the problem is at lines 3665-3667 in gl-render.cc (4.4.1 release).

My first question, though, is am I understanding the documentation and the intent correctly?  Do we agree that this is a bug?


Brent Baccala <baccala>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #44952:  image_data_doc.patch added by pantxo (5KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by baccala (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.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-07 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2018-09-07 pantxo Attached File- Added image_data_doc.patch, #44952
        StatusConfirmed Patch Submitted
    2018-09-02 pantxo StatusNone Confirmed
        Operating SystemGNU/Linux Any

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code