bugGNU Octave - Bugs: bug #41770, Some factory defaults don't...

 
 

bug #41770: Some factory defaults don't conform to matlab values

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Tue 04 Mar 2014 12:45:26 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 13 Apr 2014 03:57:09 PM UTC, comment #11: 

For locale-specific defaults, is it as simple as using the existing site-wide octaverc file to set defaults?

I have 3.8.1 installed in /usr/local and the relevant file is /usr/local/share/octave/3.8.1/m/startup/octaverc.

You could place a bunch of commands like
 

set (0, "defaultaxesunits", "cm");


in that file.

Rik <rik5>
Group administrator
Sun 13 Apr 2014 03:29:25 PM UTC, comment #10: 

We are getting a build failure due to the changes applied so far for this bug:

http://hydra.nixos.org/build/10317330/log/tail-reload

I pushed the following change to fix this error:

http://hg.savannah.gnu.org/hgweb/octave/rev/93d0fc8a5d86

Mike Miller <mtmiller>
Group Member
Sun 13 Apr 2014 08:42:44 AM UTC, comment #9: 

Hello Rik,

Thanks for the review of all those patches.
I checked the properties you mentioned in matlab:


>> version
ans =
7.14.0.739 (R2012a)
>> get (0, 'factoryaxescameraupvector')
ans =
     0     0     0
>> get (0, 'defaultaxescameraupvector')
ans =
     0     0     0
>> plot (1:10)
>> get (gca, 'cameraupvector')
ans =
     0     1     0
>> close all
>> peaks ()
z =  3*(1-x).^2.*exp(-(x.^2) - (y+1).^2) ...
   - 10*(x/5 - x.^3 - y.^5).*exp(-x.^2-y.^2) ...
   - 1/3*exp(-(x+1).^2 - y.^2)
>> get (gca, 'cameraupvector')
ans =
     0     0     1
>> get (0, 'factoryimageAlphaDataMapping')
ans =
none
>> get (0, 'defaultimageAlphaDataMapping')
ans =
none


"cameraupvector" value depends on the type of object (and probably the current axes "view" property), but its factory value is not conform to their documentation.

"alphadatamapping" is not conform to their documentation neither, at least in the version I use for testing.

Coming back to my interrogation, do someone have an idea on a central place to set non factory defaults? E.g. locale specific defaults (papersize, paperunits) could be set there (as a European I'd really be happy to not mess with those esoteric inches :-).

 

Pantxo Diribarne <pantxo>
Group Member
Sat 12 Apr 2014 08:40:23 PM UTC, comment #8: 

Now that image objects have a DisplayName property, they should be supported by legend().  I filed a separate bug report about that feature here https://savannah.gnu.org/bugs/?42103.

Rik <rik5>
Group administrator
Sat 12 Apr 2014 08:31:25 PM UTC, comment #7: 

I modified your patch slightly for Octave coding conventions.  We place the '++' modifier directly next to the variable, e.g., 'C++' rather than 'C ++'.  We also prefer to use the C++ casting standards so I changed


m(col,row) = (double) default_im_data[ii];
TO
m(col,row) = static_cast<double> (default_im_data[i]);


I checked it in here (http://hg.savannah.gnu.org/hgweb/octave/rev/2deed6538c72).

Could you double-check two of the values?

According to www.mathworks.com/help/matlab/ref/image_props.html the default for AlphaDataMapping is 'scaled' (what it was before) rather than 'none'.

According to http://www.mathworks.com/help/matlab/ref/axes_props.html the default CameraUpVector is [0 0 1], rather than [0 0 0].

Rik <rik5>
Group administrator
Sun 06 Apr 2014 04:53:30 PM UTC, comment #6: 

Sorry if it looks like I use the bug tracker to show my drafts but each time I come back to this bug I discover something new.

In ML as in octave you can display all the root defaults using "get (0, 'default')". Matlab result :

>>get (0, 'default')
          defaultFigurePosition: [680 558 560 420]
               defaultTextColor: [0 0 0]
              defaultAxesXColor: [0 0 0]
              defaultAxesYColor: [0 0 0]
              defaultAxesZColor: [0 0 0]
          defaultPatchFaceColor: [0 0 0]
          defaultPatchEdgeColor: [0 0 0]
               defaultLineColor: [0 0 0]
    defaultFigureInvertHardcopy: 'on'
             defaultFigureColor: [0.8000 0.8000 0.8000]
               defaultAxesColor: [1 1 1]
          defaultAxesColorOrder: [7x3 double]
          defaultFigureColormap: [64x3 double]
        defaultSurfaceEdgeColor: [0 0 0]
         defaultFigurePaperType: 'A4'
        defaultFigurePaperUnits: 'centimeters'
         defaultFigurePaperSize: [20.9840 29.6774]


So you can see all the "color" properties I described, but also some run time defaults for figures and axes properties.

In octave the result depends on wether the graphics toolkit (Qt here) is loaded:

## At startup, Qt still not initialized
>> get (0, 'default')
ans =

  scalar structure containing the fields:
## Qt loaded
>> line ();
>> get (0, 'default')
ans =

  scalar structure containing the fields:

    defaultfigure__graphics_toolkit__ = qt
    defaultuicontrolbackgroundcolor =

       0.83922   0.83922   0.83922

    defaultuicontrolforegroundcolor =

       0.12941   0.12941   0.12941

    defaultuipanelbackgroundcolor =

       0.83922   0.83922   0.83922

    defaultuipanelforegroundcolor =

       0.12941   0.12941   0.12941

    defaultuipanelhighlightcolor =

       1   1   1

    defaultuipanelshadowcolor =

       0.69934   0.69934   0.69934


My impression is that, if we want to be reasonably compatible with ML here, there should be a central place where defaults (toolkit specific or not) are set at startup (or after a neww toolkit has been loaded) .

Even if we don't want to follow matlab on every choice (such as the default figure color) it can be usefull to reassemble all non-factory defaults in one place.

Is there a convenient place to do that? Any comment?

Pantxo Diribarne <pantxo>
Group Member
Sun 30 Mar 2014 09:36:04 PM UTC, comment #5: 

I attached a new version of the patch.

I added "octave-default-image.h" in libinterp/corefcn. It contains the octave logo (64x64 char array) indexed against the "Jet" colormap.

Remaining issues:
*'surfaceedgecolor', 'patchedgecolor', 'patchfacecolor', 'linecolor' (see comment #4): if we want to be fully conform with ML factory defaults, those properties values will have to be changed at startup (using e.g. "set (0, "defaultPROPNAME", VAL)").
*'surfacefacelighting', 'patchfacelighting': factory values should be 'flat' instead of 'none' but the current implementation in openGL renders black surfaces/patches. I think we should wait until the bug (bug #42006) is solved before setting the correct values for those properties.


(file #31080)

Pantxo Diribarne <pantxo>
Group Member
Wed 26 Mar 2014 10:09:39 PM UTC, comment #4: 

cdata: should octave logo be loaded (and how) at run time or included from a data header file at compile time?

color:

get (0)   ## returns only root properties as in Octave
get (0, 'defaultlinecolor')  ## returns [0, 0, 0] as in octave but in ML it is a default set at root level
get (0, 'factorylinecolor')  ## returns [1, 1, 1] contrary to octave
reset (0); ## this removes all non factory defaults defined at root level
get (0, 'defaultlinecolor')  ## now returns the factory default [1, 1, 1]
line ();  ## now produces a white line


AFAICS, octave and ML perform pretty much the same (see the diagram in [1]). The thing is for lines ML has to change the line default at run time. Looks like internal cuisine that leads to weird behavior after reset. If it as acceptable to not have the same factory default here, I would not try to mimic this ML behavior.

In ML you can retrieve root level (default && !factory) for a given graphic object type using "get (0, 'defaultOBJTYPE')"  


>> get (0, 'defaultline')
ans =
    defaultLineColor: [0 0 0]
>> get (0, 'defaultpatch')
ans =
    defaultPatchFaceColor: [0 0 0]
    defaultPatchEdgeColor: [0 0 0]
>> get (0, 'defaultsurface')
ans =
    defaultSurfaceEdgeColor: [0 0 0]
>> get (0, 'defaultimage')
ans =
0x0 struct array with no fields.
>> get (0, 'defaulthggroup')
ans =
0x0 struct array with no fields.


Now about "displayname", forget about it: the error message is the same with or without the added property. I did not investigate but it looks like images don't qualify as an "legendable" object. I would add the property, and file a bug report for legend.

Finally, I'll have to rework the patch anyway as I just noticed it breaks "surface ()" default behavior.

[1] http://www.mathworks.fr/fr/help/matlab/creating_plots/setting-default-property-values.html

Pantxo Diribarne <pantxo>
Group Member
Wed 26 Mar 2014 08:21:47 PM UTC, comment #3: 

For cdata, how about just embedding the data for the Octave logo?

For the line color property, do Octave and Matlab behave differently for


get (0)   ## defaultlinecolor does not appear here in Octave
get (0, 'defaultlinecolor')  ## returns [0, 0, 0]


?  Is Octave just not using the defaultlinecolor propertly correctly when drawing lines?  Is this unique to lines, or is it a deeper problem with all default properties?

I'm not sure what to do about the image displayname property.  What's the exact problem with legend?

John W. Eaton <jwe>
Group administrator
Tue 25 Mar 2014 10:45:15 PM UTC, comment #2: 

I see I have missed some of the non conforming factory defaults. I updated the patch but some differences remain.

The main one is in image properties: "cdata" should contain the factory image (double [64x64]) color data. Is there such default image that can be read in octave tree (preferably without requiring GraphicsMagick)? 

Some other minor problems:
 - line: "color" should be [1 1 1] (but then "line ()" returns a white line). In ML black color is set in root "defaultlinecolor" so that if you "reset (0)" you fall back to factory defaults and also obtain white lines.
 - text: "clipping" should be "off" but as it belongs to base_properties it is "on" by default for every graphics objects. Same problem with "color" as for line objects.
 - patch: "facecolor" same color problem
 - image: should have a "displayname" property. Adding this property is easy but then legend fails when there is an image in the axes.




(file #31038)

Pantxo Diribarne <pantxo>
Group Member
Mon 24 Mar 2014 08:43:27 PM UTC, comment #1: 

Pantxo,

I applied your patch and confirmed that all graphics.cc tests pass for me on MacOSX.

Ben Abbott <bpabbott>
Group Member
Tue 04 Mar 2014 12:45:26 PM UTC, original submission:  

I have only investigated defaults returning empty matrices that shouldn't.  This is not a big issue as they are updated when an object is created but querying their factory value doesn't return the expected value as in Matlab (attached matlabfactory.mat file).

You may try the following in octave 3.8 or dev:


load ("-7", "matlabfactory.mat") #load factory defautlts for the following properties

props = {'surfacexdata', 'surfaceydata', 'surfacezdata', ...
'surfacealphadata', 'surfacecdata', ...
'patchfaces', ...
'imagealphadata', ...
'axesview', 'axescameraupvector'};

factorydef = cellfun (@(x) get (0, ["factory" x]), props, "uniformoutput", false);
assert (factorydefml, factorydef)


I also attached a patch that make this test script pass (and all tests in graphics.cc still pass)



Pantxo Diribarne <pantxo>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #30769:  matlabfactory.mat added by pantxo (254B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by pantxo (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-19 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2014-04-12 rik5 Item GroupIncorrect Result Matlab Compatibility
        StatusNone In Progress
    2014-03-30 pantxo Attached File- Added adjust_factorydefaults_v3.patch, #31080
    2014-03-25 pantxo Attached File- Added adjust_factorydefaults_v2.patch, #31038
    2014-03-04 pantxo Attached File- Added matlabfactory.mat, #30769
        Attached File- Added adjust_factorydefaults.patch, #30770

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code