Tue 26 Sep 2017 06:34:27 AM UTC, comment #12:
The OCTread_FIG.m function isn't as good as the modified OpenMatlabFigureInOctave.m.
I don't know about the license issue. Perhaps you can contact the owner of the github repository (https://github.com/rsnape/OpenMatlabFigureInOctave).
|
Mon 25 Sep 2017 05:09:10 PM UTC, comment #11:
An ?original? version of the file seems to be here, w/o a license:
https://github.com/carangorango/color-categorization-games/blob/master/OCTread_FIG.m
I think we cannot accept files w/o a license.
|
Mon 25 Sep 2017 11:38:57 AM UTC, comment #10:
Just to mention that the function OpenMatlabFigureInOctave.m found at https://github.com/rsnape/OpenMatlabFigureInOctave works pretty well for opening a fig file in Octave.
The title, labels, legend, etc. are usually kept. I've seen some issues in complicated figures, but usually this function is better than the openfig.m provided here.
Perhaps, this function could be integrated to Octave?
|
Tue 26 Jul 2016 03:58:08 PM UTC, comment #9:
I just wanted to bring my portion of the discussion over from a duplicate bug I had created. That commentary is available in the linked "duplicate" bug, but I am reposting here to keep it in the same discussion.
As there have been various discussions on the maintainers mailing list about a method support a GUI builder, it made me start thinking about how I like the fact that the Matlab GUIDE only requires a FIG file and an associated M file as the underlying file format. Some people were in favor of the QTCreator ui files, which I am fine if that is the decision, but decided to try and get FIG files generated by Matlab to load in Octave.
I found a great website called undocumentedmatlab.com that explains that FIG files are just a MAT file that contains the figure information (see http://undocumentedmatlab.com/blog/fig-files-format). I think someone within Octave must have already known this because the hdl2struct and struct2hdl functions already are almost identical in underlying structure to the structure contained within a FIG file.
However, for the life of me I couldn't get struct2hdl to work for me in trying to load a Matlab-generated FIG file to load. There seemed to be a couple problems:
1) too many places where Octave's struct2hdl would fail if the FIG file struct didn't have properties named exactly the same as Octave was expecting.
2) struct2hdl wasn't handling the reading of the title, xlabel, ylabel, zlabel correctly. In the FIG struct, they are listed as children, but in the resulting axes handle these text handles need to be assigned to the corresponding property in the axes handle, rather than just added as children. It seems that Matlab does not add them as children, but does assign the handle to the appropriate axes property. It seems that Octave both adds them as children and assigns the handle to the appropriate axes property. The mapping for these non-regular children is handled with the "special" field of the axes sub-struct.
So, I wrote a fairly simple script that seems to be loading simple FIG files generated from Matlab into Octave. It recursively depth-first traverses the FIG struct, creates an object based on the handle type (not all are supported yet), and assigns any properties from the FIG struct that exist in the Octave handle. In the case where some of the children are irregular, the special field of the struct is used to determine the mapping from children to properties.
Is suspect the the Octave struct2hdl and hdl2struct are self-consistent, it is just that they don't handle the conversion from Matlab FIG struct to an Octave handle. I think the right approach is to try to fix up the existing struct2hdl and hdl2struct to be compatible with the FIG struct from Matlab, but am wondering if that will break a bunch of other people's code or existing figures that have been saved as structs in MAT files using the current Octave hdl2struct.
(file #38031, file #38032)
|
Tue 26 Jul 2016 11:19:54 AM UTC, comment #8:
@Guillaume: First of all I won't be able to work on this during the coming month, so feel free to test and propose modifications. Also could you attach a few ML figs (and the script you used to produce them) for testing ui* features but also regular plot/errorbar/log ...
>> figure: properties do not seem to be taken into account (Position, Name, MenuBar, ...).
Odd, I'll look into this
>> uicontrol: if an element does not have a style property, the default is "pushbutton" (see below).
Ok
>> uicontrol: for compatibility, a uicontrol frame could be changed into a uipanel (see below).
Or wait for frame to be implemented. There are already many ugly hacks in struct2hdl so unless the change uipanel/frame is transparent I'd prefer to avoid this solution.
>> uicontrol: each element is first displayed with default position (bottom left of the figure) then moved to its final location, which is slow.
Yes that is how most object are constructed. The reasoning behind this is that some children objects (I think of images in particular) may change the properties of their parent, so we first build a default parent object, build its children, and only then set its definite properties.
|
Tue 26 Jul 2016 10:30:31 AM UTC, comment #7:
Thanks Pantxo, I just tried struct2hdl on a .fig file and it did work quite well. I have a few remarks:
- figure: properties do not seem to be taken into account (Position, Name, MenuBar, ...).
- uicontrol: if an element does not have a style property, the default is "pushbutton" (see below).
- uicontrol: for compatibility, a uicontrol frame could be changed into a uipanel (see below).
- uicontrol: each element is first displayed with default position (bottom left of the figure) then moved to its final location, which is slow.
Here are the small changes I made to the createui() subfunction:
|
Tue 26 Jul 2016 07:51:34 AM UTC, comment #6:
Hi Guillaume,
I attached the modified hdl2struct/struct2hdl.m. Unfortunately I had started from old versions (hg id: e766f7f86c68) and didn't have time to rebase and ensure I did not reintroduce some fixed bug.
We those functions:
- the format of figure structures is modified to be ML compatible: this probably means we should have two versions of each, one for reading/writing the old format, one for the new. For example the old version could be renamed _hdl2struct40_.m, the new _hdl2struct44_.m and then hdl2struct.m would be a wrapper around those.
- support for ui* objects has been enabled
- the simplest Matlab figures (plot, loglog, bar) can be open in Octave. Even though legends and colorbars are displayed correctly, like with Octave figures, they actually behave has independent axes (not very useful).
- copyobj is 30% faster in some cases.
Testing against ML figure is as simple as:
(file #38024, file #38025)
|
Fri 15 Apr 2016 11:36:28 AM UTC, comment #5:
Hi Pantxo, do you have any updates on the hgload() front? I've been happily using my implementation of openfig() for a while now but it would be good to rely on your code. You mentioned that you already had a preliminary cset available - would you be able to find and share it?
|
Tue 31 Mar 2015 05:43:18 PM UTC, comment #4:
You're welcome to rename this bug report - my suggested implementation is far from clean and I'm sure building on struct2hdl is the way forward.
In the meantime I tried openfig with other .fig files and made some further adjustments (see new attachment), just in case it might be useful at some point. That made me notice two things that I reported elsewhere:
- #44679 : segmentation fault with some .fig files when loading them in Octave
- #44672 (point 5): accepting structures for property/value in GUI functions.
(file #33499)
|
Tue 31 Mar 2015 04:18:34 PM UTC, comment #3:
We don't want to duplicate efforts and that's why we implemented a structure similar (same fields) to Matlab one in the hope that struct2hdl would be able to handle both Octave and Matlab figures. Unfortunately I misinterpreted the "special" field and the current version is not compatible with Matlab figures.
I think I am the one who proposed the .ofig extension, maybe to avoid bug reports from users trying to open Matlab figs while we know we are not able to render them properly. You are right that the name of the variable in the structure is enough to know where the figure comes from and we should not restrict the extension (as we do with "run" function).
Would you agree if I retitle this bug report "hgload can't open Matlab figures" then we see what can be done/merged from your implementation of openfig?
|
Tue 31 Mar 2015 03:04:42 PM UTC, comment #2:
Thanks for your comment. I came across hgload and struct2hdl not long after sending my initial comment...
If hgload can open a MATLAB .fig file then, yes, openfig could simply be a wrapper around it.
Looking at hgload, why using a new file extension .ofig instead of .fig? I thought it could be handled in the same way than .mat files, which can be MATLAB-compatible or not. Fields 's_oct40' vs 'hgS_070000' already specify software-specific content.
|
Tue 31 Mar 2015 06:33:43 AM UTC, comment #1:
Hi,
Can you explain the difference between "openfig" function and "hgload". The latter is already implemented for use with Octave figure structures. It is currently not "allowed" to open Matlab .fig files as there are differences in the way the "special" field is handled in Octave and Matlab, but I have a preliminary cset somewhere in my computer that brings Octave in line with Matlab in this regard.
Also legend/colorbars and any object that has listeners on other parts of the figure won't work properly (this is also true for pure Octave figures).
|
Mon 30 Mar 2015 04:25:41 PM UTC, original submission:
This is an initial attempt to implement the "openfig" function:
http://mathworks.com/help/matlab/ref/openfig.html
It is not complete but works for the *.fig files I am working with.
|