Re: Saving And Loading Plots in Octave

[pantxo diribarne]

2012/3/26 Ben Abbott <address@hidden>

On Mar 26, 2012, at 4:15 PM, pantxo diribarne wrote:

> 2012/3/26 Ben Abbott <address@hidden>
> On Mar 26, 2012, at 9:17 AM, pantxo diribarne wrote:
>
> > Hello,
> >
> > I have given a try to this task :
> > wrote two m-files, hdl2struct.m and struct2hdl.m that respectively store a figure data into a structure and build a new figure with the previous structure. It currently doesn't support hggroups (bar, errorbar, contour, quiver, ...), and have limited support for colorbars, legends (positions problems, visibility not supported) and subplots are raw axes (no use of subplot function so no listeners).
> >
> > The structure fields are similar to what I found in a .fig matlab file (handle, type, properties, children, special).
> >
> > I don't know if I do it the right way so I wanted to submit this first attempt (see demos in hdl2struct.m) :
> > - hdl2struct.m recursively stores the figure properties. Colorbars, Legends, xyzlabels, titles are stored as children of the corresponding axes.
> > - struct2hdl.m, the workflow is the following : object is first created with minimal options then its children are created (recursively) and finally its properties are set (some of them are discarded such as deletefcn, ui...). xyzlabels and titles are "special" objects that are created by their parent so only the third step (set properties) is done.
> >
> > Pantxo
> >
> > PS : my config is mac-osx 10.7.3, octave 3.6.1 (Ben Abbott's bundle)
> >
> > <hdl2struct.m><struct2hdl.m>
>
>
> So we don't forget about this, please open a patch on our tracker and upload the files
>
>        https://savannah.gnu.org/patch/?group=octave
>
> As you make progress, you can update the files.
>
> Thanks !
> Ben
>
> Submitted a patch (#7752). I'm interested in any feedback before I go further.
>
> Pantxo

Looks like a good start. The coding looks to be consistent with Octave's standard. I suggest you add a copyobj.m

http://www.mathworks.com/help/techdoc/ref/copyobj.html

And include some tests. That will allow both hdl2struct.m and struct2hdl.m to be tested simultaneously. You can also include tests you know will fail. For those be sure to mark them as expected failures so that the remaining tests will run.

I like how this is organized as handle-to-structure and structure-to-handle. That will permit a figure to be saved by.

       fig = hdl2struct (gcf ());
       save plot.fig -struct fig

When you have time, you may want to add the tex-info doc strings. If you're not familiar with tex-info you can look at some of Octave's functions. Experience with LaTeX will help. Or you can ask for some help on the maintainers list.

Also you may want to include a TODO list in the source of each file so that anyone looking, and inclined to help, out knows what else needs to be done.

I see in the "getprops()" function you list properties to avoid copying. I've thought about this problem myself. I'm not sure if it is best to list those *not* to copy, or list those that *should* be copied. In either case, it looks like there may be some difficulty with maintenance. I don't see any reason to question your choice, but I expect the question to come up. Maybe someone can come up with a way to construct the list automatically?

If there are any specifics you are unsure about, please ask.

Ben

p.s. I'm moving this to the maintainer's mail list. If you're not subscribed to that you can do so at the link below.

https://mailman.cae.wisc.edu/listinfo/octave-maintainers

Ok I will make a copyobj function and include demos (that are currently part of struct2hdl) and tests. 

About the choice to list the *do not copy*(1) or the *to be copied*(2), its consequences are IMO :
(1) most of the properties of the new figure are consistent with the original, but this does not ensure (see legend position in demos) a perfect copy. User defined properties can be copied but I don't know if user-defined listeners can.
(2) this means I first have to determine a consistant set of properties for each kind of object so that I can rebuild the figure only using high level functions. 

The second choice is probably the one I will make if I want to be able to open Matlab figures in which very few properties are stored (and some are not actual object properties but are meant to help rebuild the figure). 

Pantxo