bugGNU Octave - Bugs: bug #60897, caxis affected by rectangle and...

 
 

bug #60897: caxis affected by rectangle and patch graphic without scaled color

Submitter:  Ryan Gray <ryangray>
Submitted:  Fri 09 Jul 2021 06:21:56 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 6.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 02 Sep 2021 02:08:15 AM UTC, comment #4: 

Rooting around the source code the best I can (not looked at it before), it seems that the set method for the patch cdata property calls (I think) patch::properties::set_cdata which calls update_cdata and that function has the code that seems to do the clim setting. From graphics.in.h:5131:


    void update_cdata (void)
    {
      update_fvc ();
      update_normals (false);

      if (cdatamapping_is ("scaled"))
        set_clim (m_cdata.get_limits ());
      else
        m_clim = m_cdata.get_limits ();
    }


However, when the patch is created as in the example, the cdata property winds up empty down in __patch__.m when it calls __go_patch__ (which I can't find yet), which is the default value, and so I think it may not call set_cdata in that case when creating the patch, and it doesn't seem to be called indirectly either when the facecolor property is set, which maybe it should or at least have the relevant part from update_cdata. In other words, it seems you could add an update_facecolor method to patch::properties that sets the clim whenever facecolor is set:


    void update_facecolor (void)
    {
      if (cdatamapping_is ("scaled"))
        set_clim (m_cdata.get_limits ());
      else
        m_clim = m_cdata.get_limits ();
    }


And add a "u" to the facecolor property definition in graphics.in.h(4984) to include a call to it when generating graphics.h:


      color_property facecolor u , color_property (color_values (0, 0, 0), radio_values ("none|flat|interp"))


I've not yet tried to go look at older code to see if I can figure out why it worked back in Octave 5.2.

Ryan Gray <ryangray>
Fri 13 Aug 2021 04:32:51 PM UTC, comment #3: 

I have confirmed this bug also affects version 6.3.

Ryan Gray <ryangray>
Tue 20 Jul 2021 09:44:12 PM UTC, comment #2: 


comment #1:

> ... The logic that autoscales the "clim" property of an axis has to look at the color data for each relevant object.  My guess is that empty cdata, '[]', is being equated with 0 rather than having a special case to simply ignore.


That's my guess as well. However, given that reasserting the empty cdata fixes it, I think the check is there, but the bug is that the check is getting skipped when the patch object is first created.

Ryan Gray <ryangray>
Thu 15 Jul 2021 10:53:15 PM UTC, comment #1: 

Confirmed.

I tested on Linux and the same issue is present so I changed the OS to "Any".

The rectangle object in Octave is not a drew graphics primitive, but instead is mimicked with a patch object.  See the file rectangle.m.

Hence, you are correct that this is a general issue related to patches.  The logic that autoscales the "clim" property of an axis has to look at the color data for each relevant object.  My guess is that empty cdata, '[]', is being equated with 0 rather than having a special case to simply ignore.

Rik <rik5>
Group administrator
Fri 09 Jul 2021 06:21:56 AM UTC, original submission:  

In Octave 6.1 and 6.2, adding a rectangle graphic to an imagesc plot, the caxis limits are affected. In Octave 5.2, the limits are unaffected as it is in MATLAB. I have not found anything that mentions this as an intentional change. I have tested this on Windows.


>> figure; imagesc(rand(16)+1);
>> caxis

ans =

   1.0020   1.9928

>> hold on; rectangle('position',[4 4 4 4]);
>> caxis
ans =

        0   1.9928


I would expect the lower value to still be 1.0020.

Adding a patch graphic that doesn't use scaled color also affects the caxis when it shouldn't.


>> figure; imagesc(rand(16)+1);
>> hold on; p = patch([1 4 4]',[1 1 4],'w','edgecolor','c');
>> caxis
ans =

        0   1.9996


Interestingly, if we re-assert the cdata property as empty, it corrects the caxis:


>> get(p,'cdata')
ans = [](0x0)
>> set(p,'cdata',[])
>> caxis
ans =

   1.0003   1.9996


If the rectangle is being drawn with a patch, it's likely why the rectangle has the same problem.

Ryan Gray <ryangray>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 ryangray (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-07-15 rik5 StatusNone Confirmed
        Operating SystemMicrosoft Windows Any

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code