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

 
 

bug #54610: imagesc doesn't implement ranges properly

Submitted by:  Brent Baccala <baccala>
Submitted on:  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

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

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>
Project Administrator
Fri 07 Sep 2018 08:56:52 AM UTC, comment #4: 

@Rik: Is the attached patch ok?

(file #44952)

Pantxo Diribarne <pantxo>
Project 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>
Project 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>
Project 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>
Project 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)
  •  

    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 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.5