Panel

Like subplot, but easier, and WYSIWYG export to file. Also fixes dashed/dotted lines in export.

Description

Panel is an alternative to Matlab's "subplot", providing easier control over layout (particularly, easy elimination of whitespace). It also fixes dashed/dotted lines during export to image files (both vector and bitmap formats).

If you find the layouts generated by subplot() have too much space and not enough axis, try Panel. If you find it tedious to construct subplot layouts that are more complex than a simple grid, try Panel. If you always resort to other software to prepare your final figures for publication because you can't get the appearance you want from Matlab, try Panel.

Panel was designed to produce output for print publications directly from Matlab. Layouts are, by default, in physical units (mm, by default), and exporting to a graphics file targets print columns directly. However, it performs equally well if the end goal is digital display, providing easy control over use of screen real estate.

Panel incorporates features suggested by several Matlab Central users, as well as some code - see the documentation for details.

Questions? Please see the http://www.mathworks.co.uk/matlabcentral/fileexchange/20003-panel/content/docs/faq.html first.

• MATLAB release: MATLAB 7.10 (R2010a)
• Other requirements: Requires a version of Matlab that supports the "classdef" syntax. I understand that means R2008a or higher.

[Alex]

 

[Iman Ansari]

 

[Ben Mitch]

Release 2.10 will appear shortly. This release is significant, since the optimisation approach to layout has been replaced by a procedural approach. This should mean no more poor performance for users without the optimisation toolbox (Per Nordlöw, I hope this helps you at least :D). The 'defer' flag should now be obsolete (it will continue to be supported).

This release also adds support for panels of fixed physical size, which obviates the need for the inelegant workaround suggested in the comments below. see the new "help panel/pack" for details. This has led to a change of recommended syntax to the pack() function, as follows:

OLD: p.pack([0.2 0.3 -1])
NEW: p.pack({0.2 0.3 []})

The old syntax is still supported, and there are no plans to withdraw support, but new code should use the new syntax (swap -1 for [], and [] for {}). To pack a panel of fixed physical size, simply enclose your size in a cell array, for example:

p.pack({0.2 {50} []})

NB: This is a fairly major rework - mission critical users (ha!) might stick with 2.9 until June, in case of any issues.

[Ben Mitch]

PS. I've added this to a nascent FAQ, since it's been asked twice :)

[Ben Mitch]

Hi Bahaa

Thanks for your comments. The workaround for semilogx() etc. is covered further down this page.

Cheers
Ben

[Bahaa]

Hi Ben,

this is an amazing work ... thank you for sharing.

I have one comment on it ... when using 'semilogx' or 'loglog' for plotting in the selected panel. the plot axis remains in linear scale... is there a way to change it to be in log scale.

regards,

Bahaa

[Ben Mitch]

Release 2.9 will appear shortly. Only minor updates, no need to upgrade. Release log has details.

[Ben Mitch]

Release 2.8 will appear shortly. panel.plot() is withdrawn, and replaced by panel.fixdash(), which simplifies use and improves performance. See demopanelI (the updated version) for suggested usage. It's pretty neat, now, actually, do please try it out and let me know what you think :).

[Ahmed A. Selman]

Very nice function, elegantly written.

[Ben Mitch]

Release 2.7 will appear shortly. It adds a demonstration of how to do inset plots (tx Ann Hickox), but more interestingly adds panel.plot(), an integrated function for plotting dashed and dotted lines that works around the poor rendering of these in bitmap exported images.

NB: In this release, setCallback() is renamed to addCallback(), to support the new plot() function - if you use setCallback() you will need to search/replace.

[Ben Mitch]

hi Elliot

Firstly, the answer is inelegant, and it would be nice if Panel offered packing at a fixed size rather than only at relative size. Perhaps in a future version. However, you can work around as follows (and yes, the callback was the right idea). First, you'll have to edit panel.m itself to allow yourself access to the "packpos" property, add these lines:

case 'packpos'
out = p.packpos;

round about line 2289, just under case 'figure'. Restart Matlab. Now, the key features you need are:

1) attach the callback to "p", the root panel. this is a bit more intuitive, though you can achieve the same thing your way too.

2) access p in the callback through "p = data.panel". then you have p.figure, p(2).object (which is "u2"), get(p(2).object, 'children') (which is "tab"), etc.

Now, calculate the correct packing size for p(2), check if it's the current packing size (i.e. check if it's equal to p(2).packpos) and, if not, p(2).repack() it.

Phew, what a pain. Works, though. So yeah, one item on the to-do list for next version is to allow fixed size packing.

The full code is at goo.gl/A1vnu and it's not something I'm proud of.

Cheers
Ben

[Elliot]

I'm having a little trouble setting up the layout I want, that includes a plot above and a data table below. The two main goals are:

1. Let the plot take up as much space as possible without cutting off any of the table
2. When the window is resized, resize the plot but leave the height of the table fixed.

Below is what I have so far, but I have to fudge the height of the table, and the resizing doesn't work because I don't know how to access the properties of my uipanel and uitable from inside a callback function.

Can anyone please provide some guidance?

-----------------

% Create some data and a table
X = randn(100,3);
tableData = [mean(X,1); std(X,[],1)];

% Set up the figure
clf
set(f, 'units', 'normalized');

% Create the uipanels
u1 = uipanel('units', 'normalized', 'position', [0 0 1 1], 'backgroundcolor', [1 1 1]);
u2 = uipanel();

% Create the uitable and get the relevant sizes
tab = uitable('Parent', u2, 'Data', tableData, 'units', 'normalized', 'position', [0 0 1 1]);
pos = get(u2, 'position');
ext = get(tab, 'extent');
set(u2, 'position', [pos(1:3) ext(4)]);

% Set up the panel
p = panel(u1);
p.margin = [5 5 5 5];

% Pack two subpanels, with the bottom panel's height fixed (to hold the
% uitable)
% Can I automatically account for the margins without having to add a
% buffer like this?
p.pack([-1 ext(4)+0.02]);

% Add the plot
p(1).select();
plot(X);

% Add u2
p(2).select(u2);

% Get rid of the scrollbars
jtab = findjobj(tab);
set(jtab, 'VerticalScrollBarPolicy', 21);
set(jtab, 'HorizontalScrollBarPolicy', 31);

% If I set up a call back, how do I access the position of u2 and the
% extent of tab from the 'data' argument?
%p(2).setCallback(@callbacktest);

[Pio Nonus]

Thanks. It works perfectly.

[Chris Betters]

 

[Ben Mitch]

Hi Tim - thanks for the feedback :)

Yes, indeed, that will work, as will any of the other things you can do with figures (at least, I hope so). Panel should interact well with anything else you want to do with a figure, so please let me know if there are any compatibility problems.

Cheers

[Tim]

Ben - Great submission!
using;
figure('units','normalized','outerposition',[0 0 1 1])
rather than the usual figure command makes the created figure full screen. Thanks.

[farhan]

 

[Ben Mitch]

hi Kate - not sure, probably. I've not used copyobj before. If you figure it out, please send me a demo for the collection :)

cheers

[Kate]

Is it possible to open a saved figure, then insert everything in that figure into a subplot of a Panel? Similar to what is possible using copyobj and subplot. I did not see a relevant demo, but perhaps I just missed it? Thanks for any pointers!

[Wyllian]

Very powerfull tool. Suitable for graphics professionals.

[Ben Mitch]

...and Release 2.6, now available, also adds export to SVG and includes a documentation update.

[Ben Mitch]

info: the release on 23 Jul 2012 is unlabelled, but is Release 2.5.

[Ben Mitch]

hi Kuo-Hsien

think you're probably trying to do this...? in terms of layout:

p = panel();
p.pack(2);
p(2).pack('h', 2);

that is - rather than including those scalar dimensions, use 'h' to switch to horizontal packing for the second pack command. the way you had it does work just fine, but it makes the references rather complex (e.g. p(2,1,1,1)). try p.select('all'), p.identify(), to see what you've ended up with.

next, to make what is now p(2,1) packed at 2/3, you should change the last line to:

p(2).pack('h', [2/3 -1]);

note that -1 means "stretch to fit". see demopanel4 for a full example.

hope that helps
cheers, ben

[Kuo-Hsien]

How to let p(2,1,1) occupy 2/3 of the area of p(2, 1).pack(1, 2) ??

Here is my code:
p = panel();
p.pack(2, 1);
p(2, 1).pack(1, 2);

[Ben Mitch]

Brendan - see release 2.5 for management of multiple axes (see demopanelG).

Please note that this release (2.5) may, possibly, have bugs, after this rather significant change - please revert to 2.4 if you have problems, and report them here. Thanks :)

[Ben Mitch]

Glad it's a help to you, Karl, thanks for the comments :)

[Karl]

Great function. Super-useful-- I may never have to touch up another figure in Illustrator. Incredibly well documented, and the demos are invaluable.

[Karl]

 

[Ben Mitch]

Brendan-

I've had a look through, and it looks like it will be possible to manage two or more axes per panel, no problem. However, it's going to take a little time to go through step by step and try not to make any bugs, so I'll have to do this another time. I will try and get to it next week.

cheers, ben

[Ben Mitch]

Dan-

I've tracked this down, now. Panel sets the "NextPlot" property of automatically created axes to "replacechildren", whereas the default is "replace". This is to protect modifications to axis labelling due to panel (i.e. fonts, i think). A side effect is that the high-level plotting functions semilogx/semilogy do not change the scale of the axis. It doesn't look like there's any way to control these things separately, so I guess we're stuck with that. However, it suggests an alternative way round the problem to that which I suggested, above. You can use the following to create the axis before asking panel to manage it - the effect is that the axis gets created with the appropriate scale, and then gets handed to panel for position and font management. either approach ends up with the same result, so whichever you find more intuitive.

cheers, ben

---

>> figure; p = panel;
>> semilogy(x,y,'r','linewidth',2.5);
>> p.select(gca);

[Ben Mitch]

Hi Jesper

I don't know if it's related to the EPS thing...

google "matlab export dashed eps"

In any case, I doubt it's related to panel. panel uses "print" to export, so try using the print function directly and see how that goes. get back to me if it does seem to be panel-related.

cheers

ps. you might try a different renderer on the figure, see if that helps. each of the renderers has something it doesn't do well, though.

[Jesper]

Hi, I have a problem, when exporting figures with dashed or dotted lines. They almost appear as solid lines when I use -rh and -rp resolution. Is there a solution? Rendering?
Thanks

[Ben Mitch]

this comments page is really annoying, the way it swallows questions! i've just noticed that my answer to Eric was swallowed too. d'oh.

Eric - the brief answer is that when you set p(1).de.margintop to 50, you're setting all p(1) (the left column) 's descendants to a 50mm top margin, for a total 250mm of margin to be found in the vertical dimension. this is unlikely to fit on your screen, hence the warning and the hidden panels. perhaps you are looking to set just the topmargin of p(1), i.e. p(1).margintop = 50?

cheers

[Ben Mitch]

Hi Brendan - your question seems to have disappeared. I'll briefly answer it anyway - since ax1 is managed and ax2 is not, they will get out of sync whenever the window is resized (in your example, they may never be sized, because you use 'defer' but do not make a call to refresh() at the end). it would be nice, i suppose, if panel managed both ax1 and ax2. i'll look into this when i get back from travelling, it should be easy, and will post a new version probably (in about a week). in the meantime, you can always use set(ax2, 'position', get(ax1, 'position')) to re-sync the two axes, but that's not a viable solution for exporting. thanks for picking that up, i think that will be a useful fix.

cheers

[Brendan Sullivan]

 

[Ben Mitch]

(note that that last example, p(1).rightmargin, is specific to the layout used in demopanel6, i.e. two columns, rather than being a general rule!)

[Eric Bryant]

Ben, thanks very much for this contribution. There are a couple of things I don't understand about margins, however. For example:

>> demopanel6
>> p(1).de.margintop=50;
Warning: a panel had zero size, and the managed object was hidden ...
>> p(1).de.margintop=0;
>> p(2).de.margintop=50;
[No warning]

Looked at your documentation. Again, much appreciated,

[Ben Mitch]

Hi Dan, thanks for the comments. I'm not sure quite why a panel axis does not respond to semilogy as it should, I'll look into it if it ever needs a broader update. In any case, semilogy() just sets the value "yscale", so you can use:

plot(x, y, etc.)
set(gca, 'yscale', 'log')

I think that amounts to the same thing.

Cheers

[Dan]

Ben, great code and thanks for providing. I've been using it a lot lately. I'm trying to use the semilogy function in one of my panels, but the figure then just shows a normal y-axis. Here is sample code:

semilogy(x,y,'r','linewidth',2.5)

Is there a way to use semilogy with panel.m?

Thanks,
Dan

[Derek Nokes]

Thanks Ben!

[Ben Mitch]

hi Derek

see demopanel4, or try the following:

p = panel();
p.pack([70 30], [80 20]);
p(1, 1).select(); plot(y1);
p(1, 2).select(); plot(y2);
...

that should put you in the same space,

cheers
ben

[Derek Nokes]

In a previous version of panel I used to do something like this:

p = panel(gcf, [2 2], [70 30],[80 20]);
select(p{1}); plot(y1)
select(p{2}); plot(y2)
select(p{3}); hist(y1,100)
select(p{4}); hist(y2,100)

How do I do something simple like this in the newest version of panel?

[Derek Nokes]

 

[Ben Mitch]

hi Per

i) if you have the opt toolbox installed, now:

on my machine linprog takes about 80ms for demopanel1. if your linprog is taking 1 sec, and it's the mathworks version, i guess that's just a cost to using LP to do the layout. i might try and optimise the definition of the problem at some point, but i'm not sure if it's possible, i think i tried that last year.

ii) if you don't:

the included linprog solver isn't optimised, and runs slow. if you can track down a faster, freely available, solver, i'd gladly trial it for inclusion in a future release.

on my machine, demopanel1 takes 1.25s. of this, 0.45s is the plotting code. once this is snipped out, most of the rest is sluggish property referencing and function nesting, which is frankly embarassing, but i'm afraid i just don't have time right now to work on optimising this (maybe in april :)). to be fair, demopanel1 is a complex layout; in my everyday use (one to six panels in a grid, say), i don't notice any overhead. but as ever - your mileage may vary.

cheers

[Per Nordlöw]

The performance is still close to unacceptable to me. Running demopanel1.m takes 1.8 seconds out of which 1 second for the linprog code. Why so long? I'm sitting on a pretty descent laptop, Dual-Core 4 Gb memory, DELL PRECISION M6400 with MATLAB 2011b.

[Ben Mitch]

A note: On 2008b, and possibly later versions I haven't tested, the fact that the resizeCallback() and closeCallback() are private makes things not work. You can fix this by removing the "Access = Private" modifier on that section of "methods". It works fine in later versions, they must have changed the access rules I guess.

[Imran]

 

[Ben Mitch]

[edited email exchange with "Steffen"]

>> I was wondering: Is it possible to set the background color of the exported figure? I tried
>>
>> set(gcf,'Color',[0,0,0])
>>
>> In the matlab window the background is black. But after p.export the background is white again.
>>
>> What am I doing wrong :?

> set(gcf, 'Color', [0 0 0], 'InvertHardcopy', 'off')
>
> cheers
> ben

[Ben Mitch]

Hi Jesper

Forgive me, I was just using Panel myself today and noticed strange behaviour with respect to smoothing and import into Word. Suddenly clicked that I was seeing what you were flagging up the other day. Sorry, I did do some testing before and thought I'd got to the bottom of what you were seeing. Clearly, not - but I understand now :).

This is fixed now for PNG and TIF filetypes which now import correctly whether smoothed or not. Looks like JPEG does not include a DPI setting at all, or at least not one that I can make work. JPEG's not very useful, here, anyway. Next release of Panel will include the fix.

Thanks for the heads up :)
Ben

[Mukhtar Ullah]

Thanks Ben. That is the kind of an answer I was expecting. I had this wrong perception that I can only access methods from an instance p, but you saved me!

Best regards

[Ben Mitch]

Hi Mukhtar, did you try...

p = panel.recover(gcf);

?

Cheers

[Mukhtar Ullah]

Sorry, I forgot one line. Following is the correct code I use

cvars = who;
foundpanel = false;
for i=1:numel(cvars)
try
foundpanel = evalin('base', ['isa(' cvars{i} ',''panel'')']);
catch erri
end
if foundpanel
break;
end
end

[Ben Mitch]

Hi Jesper

Yeah, that's right. By scaling it you're overriding the default DPI either set in the file or assumed by Word.

Some image formats can include a resolution setting (TIFF, PNG, also JPEG?). However, these settings don't propagate to the image file through Matlab's print() function (at least, not to my testing). Panel does not attempt to fix up this information after print() is called because, well, because you're the first person who's flagged it up :). I use Latex for documents, which ignores image DPI, so I'd not noticed.

Erm... It would require either binary hacking or a time-consuming imread()/imwrite() cycle, I guess, to fix it. And Matlab's imwrite() appears not to provide access to these fields for JPEGs. Potentially this could be done, would it make a big difference to you? In any case, I won't prioritise it since the scaling is easy enough.

If you're using PNG (looks like it), you could add it yourself as a read/write step after p.export(), something like:

function set_png_dpi(filename, dpi)

im = imread(filename);
dpm = dpi / 25.4 * 1000;
imwrite(im, filename, ...
'XResolution', dpm, ...
'YResolution', dpm, ...
'ResolutionUnit', 'meter');

Inefficient as hell, but would do what you want. If anyone has a smarter solution, I'll gladly consider adding it to Panel.

Cheers
Ben

[Jesper]

Thanks Ben, I get 4016x2482 in both cases. But the un-smoothed figure fits directly into a A4 Word document, while the smoothed one needs to be down-scaled to fit...
Cheers
-Jesper

[Ben Mitch]

Hi Jesper - thanks for your feedback.

That command produces an image size of 4019 by 2486 pixels on my machine. Without the smoothing, i.e. '-rp', it is 4019 by 2487 (i.e. only one pixel different). What sizes do you get?

Note that this is "170x105mm" only in the sense that, if you print/display that bitmap file at 600 DPI (as chosen by "p"), it will be 170x105mm in size, and the fonts, lines and symbols in the image will be at the point sizes you used when you created them. That meta-information (600 DPI) is _not_ encoded in the image file, as it can be, I believe, in a jpeg file. Thus, if you open it in something like photoshop, you may be surprised at the size it is displayed at, but that is only a matter of zoom level.

Hope that helps
Ben

[Jesper]

Hey, this seems to be quite good! But I have a problem with exporting.
I was expecting a 170x105mm figure with:
p.export('myfig' '-rp/2')
But it turns out to be much bigger. Without the smoothing it is as expected. Am I missing something?

[Mukhtar Ullah]

Thanks Ben Mitch for the update. I hope others find that useful too.

[Ben Mitch]

Have just uploaded a new version (2.2) with the flag you need, Mukhtar. Cheers.

[Mukhtar Ullah]

 

[Mukhtar Ullah]

Dear Ben, thank you for a prompt reply. Commenting out those lines does solve the problem as you guessed. Yes, it would be useful if you add that flag. The reason I need to use different fonts for different text objects is because text objects having math formulas are better in a roman font instead of the default Arial which only suits pure text only.
Cheers,
Mukhtar

[Ben Mitch]

Hi Mukhtar. Thanks for your comments.

Yes, Panel handles fonts (face, size) globally for each panel layout. So, whenever you do anything that causes the panel layout to be re-rendered (e.g. change a margin on a panel for which redrawing is not deferred, as in your case), all fonts of all managed objects will be set back to the default for the layout. It didn't cross my mind that somebody might want to use different fonts for different objects, I'm afraid. Now... what to do about it.

One way would be to provide another flag to the constructor, to turn off font management for that layout, so that the user can do it themselves (fonts would revert to being managed by Matlab, and you could do what you are trying to do). You could trial this by commenting out lines 3010 to 3015 (assuming you are using version 2.1). Does this then do what you want? If so, I'll add this flag and publish a new version.

Cheers
Ben

[Mukhtar Ullah]

Dear Ben Mitch, this problem is arising again and I think I found the reason why. It depends on whether you set panel margins before or after plotting. So wheraas the following works
p = panel();p.pack(2, 2);
p.de.margin = 2;
p(1).marginbottom = 10;
p.margin = [10 8 2 8];
% your plotting commands some of which % change the fontname property

But the following will give you the problem:

p = panel();p.pack(2, 2);
% your plotting commands some of which % change the fontname property
p.de.margin = 2;
p(1).marginbottom = 10;
p.margin = [10 8 2 8];

It is driving my nerves crazy. Would be nice if you could fix this. Thanks.

[Mukhtar Ullah]

I have to take my comment back. The culprit was another piece of code.

[Mukhtar Ullah]

This function is very useful. One thing, however, could be fixed by the author: it does not respect font specification on an individual basis. Though it is possible to specify a global FontName property, it does not respect the specification for a particular text object. For example, the following will not give the expected result:
xlabel('X(t)', 'FontName', 'Times-Roman');

[Ben Mitch]

Hi Per. Yes, it's slow without the opt toolbox installed, unfortunately. At some point I may find time to incorporate a fast solver for the layout; until then this will be a problem for complex layouts without that toolbox. If you are using panel for producing final figures, you can use the "defer" argument (see "doc panel/panel"), and the layout will only be computed when you call export. Not ideal, I know.

For the padding (margins), have you looked through the examples in the docs? Particularly, see "demopanel5". Or, try "p.de.margin = 0" as a starting point, then increase margins on individual panels or parent panels until you get the layout you need.

Hope that helps.

[Per Nordlöw]

Idea is good. However, for some reason the performance becomes unusable bad for grids containing around 20 axeses. I have to around 10 seconds for a redraw. I do not have Opt Toolbox installed. I'm using Linux and HW OpenGL on an Nvidia-equipped Dell Precision M6400. I also find it hard to pad axeses grids in an optimal way so that titles and labels are displayed without covering each other. If these things are fixed I will rate this as a five-star product.

[georg]

one of my posts got lost, that's why the last message doesn't make sense ... anyway, everything is working now

[georg]

sorry, I was wrong. I was just wondering how you did the recover after the figure was closed, so I stumbled upon the persistent variables and the mlock call. But the mlock isn't in the dispatcher anyway, so that has got nothing to do with it ...

[Ben Mitch]

hi georg, i've looked into this. the long and short is, if you call "clf" whilst a panel is managing the figure, you pull out the rug from under panel, and there's no way i can see to detect this. i've updated the code so that the resulting "invalid handle" errors are hidden, rendering this condition harmless, but still it seems that calling "clf" in this way is not the "right" thing to do. do any of these alternatives suit you?

1) if you want to build a fresh set of panels from scratch, just do so (call "p=panel" to create the root). any existing panels will be deleted automatically (though see "demopanelE").

2) if you want to clear the figure and plot into it again without using panel, use "delete(p)", where "p" is your root panel. the figure is now clear of any panels and panel axes. if you left some other stuff in there, you can call "clf" afterwards to clean this up.

let me know if these alternatives make sense. i can see that the expected behaviour on clf would be to delete all associated panels, as well as all graphics handle objects. i wonder if there is any way to do it, though. if anyone knows a way to detect a call to clf, please do pass it on.

regards

[Ben Mitch]

hi georg. yeah you're right, there's something up there. it is supposed to disengage itself following a clf call; i must have been messing around and left things untidy. i'll look into it when i get a chance. cheers.

[georg]

Great! love it, especially the print functionality. Though, I think there is a problem with the delete function. I keep getting errors in case I use clf and reset the Figure position afterwards. (I am trying to reuse the same figure multiple times but have different numbers of subplots in it.) Suggestion: either provide a panel.clf() function or unregister the callback functions from the parent handle (and anything else that my belong to the panel)

[Ben Mitch]

hi Warwick - i think this must be a problem with your local "linprog", since the one provided with panel is not named the same. try "which linprog" or "edit linprog" to see what it resolves to, and delete it or move it as necessary. panel should then start working.

[georg]

 

[Warwick]

Trying to run demopanel1, etc.

keep getting error.
"Error: File: linprog.m Line: 27 Column: 4
A BREAK statement appeared outside of a loop. Use RETURN instead."

[Ben Mitch]

Ian - Sorry, I haven't had time to look at this. In the meantime, you can make this call to disable the layout process following a resize:

set(p.figure, 'ResizeFcn', [])

Technically a hack, but I can't think why it would cause any side effects. Cheers.

[Ben Mitch]

Hi Stewart - extract it anywhere, and just add the file "panel.m" to your Matlab path (using "addpath", or "pathtool"). Cheers

[Stewart Wiseman]

Newbie question! I downloaded Panel, where do I extract it to? Thanks..

[Ian]

I remove all space and ticks and thus 15x15 actually works well on a decent monitor! 15x15 is probably an upper limit though (more because it takes ages to record data from large matrices) :-P

Yes, I do resize a lot - I use Matlab as an online display for data coming in from neuronal recordings, and resize given other programs and the size of the current data grid. Again, if it remains slow, I'll just know *not* to resize, but being able to turn the physical sizing on/off would be great!

[Ben Mitch]

15x15! wow, you're just to crazy to be real, such large numbers computers just can't handle! seriously, does that really fit on screen?

errr... yeah well there might be a bit more to squeeze out of it. but the resize thing - since panel performs layout to a physical size, it needs to remake the layout when the physical size of the window changes. subplot uses relative units, so there is no re-layout necessary on resize. it would be easy enough, for panel, to provide a flag that turned off physical sizing on resize, or that turned off physical sizing for the figure window (letting it operate only on export). would that be useful for you? do you resize windows a lot, then? :)

i may have to make an interim release with these mods - it's taking a while to get this linprog license sorted out.

[Ian]

I was getting about 4.8 seconds with original panel and about 1.5-2 secs with subplot. Note subplot seems to do a lot of property enumeration too...

I'd normally not be worried, but I'm using panel to display data as it comes in in real time and long plotting times cause matlab to freeze enough that I lose my data sync (I saw this with 15x15 matrix)...

Has resizing the figure performance also improved now?

[Ben Mitch]

Got it down to only 25-30% slower now. I'm getting about 2.45 secs for a 9x9 layout using subplot, and 3.15 secs for the 9x9 using panel. Are these numbers comparable to what you're seeing, Ian?

[Ben Mitch]

Ian - dunno what happened there, think I overwrote my own first comment. In any case, the comment above tells the end result, even if it reads a bit funny :). Cheers.

[Ben Mitch]

Ach, I had a quick look since you brought it up. I used demopanel2(N=9) as a test case, as you suggested. Bit of code tidying has got the speed down from 3x longer than subplot to 1.6x longer. That line you highlighted _is_ an overhead, but preallocation doesn't seem to help.

In any case, at only 60% longer than subplot, I'm not too concerned, but I'll probably have another look, as I said, later in the year. The profiler suggests we could get another 10-15% speedup by more efficient property resolution, which would put us pretty closely in line with subplot. Might be able to avoid most of the calls to control fonts, as well, when the user hasn't specified different fonts. With all that, would probably be getting times not dissimilar to those from subplot.

Cheers

[Ian]

Hi Ben, when I increase the number of axes to manage, panel starts to get very slow. To reproduce, change demopanel2 to use 9 x 9 axes, panel starts to take substantially longer than subplot. Profiling, the largest time taken is calling this line (839 times):

p.state.lin(dim).A = [p.state.lin(dim).A; a];

Wonder if preallocating wouldn't help? Resizing the figure I think also triggers this (called 2264 times).

[Prakash Manandhar]

 

[Nate Jensen]

I like it. I'd like to throw some constructive criticism in here, but I haven't played around with it enough to do that yet. So far so good. Keep it up.

[Ben Mitch]

thanks - my matlab does not document the -dpdf option, or else i couldn't find it.

ok, have done that, seems to work fine. this will appear in the next release (just waiting for permission to include linprog...).

[Joshua]

my usual print command is this:

figname='test';
wh=[2 3]; % width and height of page to print on
set(gcf,'PaperSize',wh,'PaperPosition',[0 0 wh],'Color','w');
print('-dpdf',figname)

i often have problems with font sizes, in that the axis-labels get partially cut off. i'm hoping that panel will somewhat alleviate this issue (in addition to all the other nice features that it has).

anyway, is that what you were looking for?

[Ben Mitch]

Hi Joshua - I'd be happy to include pdf support. Perhaps you can point me at how to export a figure to pdf using the command line? I looked at the docs for the "print" function and I can't see any mention.

[Joshua]

this looks great! before i could adopt it, however, i would need to export to pdf. i modified the code a bit to do it, but it wasn't perfect (paper size needed to be updated too). anyway, i might do it for me. if the code was hosted somewhere like github, it'd be super easy for you to see my changes. but i imagine you could do it better, and quicker. any thoughts?

-- jovo

ps - the reason i want pdf over ps/eps is that on a mac, pdf viewer is nice and built-in, so i always store vector graphics as a pdf.

[Daniel]

gotta thank you for your extensive work :)

[Ben Mitch]

Thanks Daniel - this does indeed do the job. I'm just liaising with the author about licensing, will hopefully release a repack that doesn't need the opt toolbox soon. Thanks for the heads up :).

[Daniel]

There is a function called linprog in the FEX (see http://www.mathworks.com/matlabcentral/fileexchange/97-linprog). But the inputs are different to the optimtool linprog. Maybe you'll find a solution with that..

[Ben Mitch]

Hi Daniel. Uh-oh - that never even crossed my mind. Err... does everyone in the world have the optimization toolbox...?

Well, the LP problem is pretty straightforward. Wonder how difficult it is to program an LP solver, probably not too tough. Or perhaps there's some source code knocking around on the interweb... Any pointers appreciated...

In the meantime, Daniel is right, you'll need the optimization toolbox. Sorry.

[Daniel]

seems to require optimization toolbox (linprog()). have we got workarounds for that?

[Ian]

The V2.0 update for panel is wonderful, very well documented code (including lots of demonstrations), refactored into a single classdef, and as it now works within uipanels can now be used as subplot. Panel is wonderfully flexible, and controlling super labels, fonts, and margin management elegantly with very intuitive class methods.

Thanks Ben, this is a really excellent contribution!

[Ian]

Ben, thanks for adding this to your TODO! I'm also really looking forward to the handle class version of this -- hope it is a single classdef m file for easy install for the lazy :)

Cheers, Ian

[Ben Mitch]

Hi Ian

I'm just preparing a new version of Panel now (handle class based). I'll put this on the TODO list before the release. Sounds straighforward, doesn't it? I wonder if there's anything else that someone might want to use as a parent of panel...

Incidentally, you can probably do what you want with the existing version. Set panel on the whole figure, then pack it with a child with absolute positioning, with position equal to that of the uipanel. Not quite as slick, but i think it would work. e.g...

u = uipanel;
set(u, 'position', pp)
p = panel;
q = p.pack(pp);
r = q.pack( ... etc.)

cheers

[Ian]

What would be great is if we could attach this not only to a figure, but a panel within a figure. I have an existing UI using subplot setting the Parent as a uipanel. This allows me to have a set of UI buttons etc in one panel and my plots in another. I'd love to use panel, but trying to force it to use a uipanel as a parent fails...

[Ben Mitch]

Hi Niko - I did as you suggested, was a good idea. Do please try the update, when it comes through, and let me know if you have any problems.

[Ben Mitch]

Hi Niko - thanks. You mean, I think, so that the xlabel/ylabel were positioned as if the four (say) sub-panels were all one axis. That's a good idea, yeah. I guess another possibility is that you might want to set all the xlabels/ylabels of all the sub-panels through a single command. Both things are possible, but the first sounds particularly useful. I'll look into it.

Thanks for the feedback.

[Niko]

Very useful tool.

It would be nice to be able to easily add a panel-wide xlabel/ylabel spanning multiple children.

[Renay]

Thanks for the prompt reply Ben, but I should have read your manual! The following is what I needed:

set(p.figure,'visible','off')

This turns the screen updating off. Thanks for a great package.

[Ben Mitch]

Invisible? Not sure what you mean - can you explain further?

Regards

[Renay]

Thanks for the great package.

How would I make the process of exporting a panel 'invisible'.

Regards

[Ben Mitch]

just for info - the latest release incorporates two of suggestions above. you can now use p = panel(gcf, [2 2]) to return a 2x2 (or whatever) grid of panels (further arguments control sizing - see screenshot above). handling of xlabel, xtick and xticklabel is now seamless with the corresponding matlab functions (i think, anyway :). thanks for the feedback :).

[ethan reddick]

 

[Ben Mitch]

Hi - Thanks for comments.

yes you can change xtick labels. use p.xticklabel = {1 2 ...} where p is a panel. should work just the same as set(gca, 'xticklabel', {1 2 ...}) i think. unfortunately, this didn't find its way into the docs, sorry. next release will have this documented.

yeah, p = panel(2, 2) would be ok i suppose wouldn't it, so long as you just wanted a regular grid layout which i guess we often do. i'll see about adding that. additional pars for sizing... hmmm i'll look into it.

implement using a HANDLE class: yeah, well this was written back in the dark days when such things weren't possible. i do fancy reimplementing at some point, would be slicker. if i ever get the time :)

re the defaults idea, yeah i see what you mean. i'll stick it on the todo list.

cheers

[Heeten Choxi]

Is there a way to change the values of the xtick labels? I tried doing it with set(axis,'XTickLabel', [new values]) which used to work when I used subplot but doesn't seem to work with panel.

Thanks,
Heeten

[LP]

This appears to have good potential but some suggestions;

* Should have a similar interface to subplot
e.g. p = panel(2,2);
which would return a (2,2) array of panel objects
and perhaps some additional parameters for the relative sizing of each subpannel a-la the input for 'pack'

* Implement using a HANDLE class inheritance

* Allow margins to be set individually so that defaults remain
e.g. axismargin(10,[],[].10);

Good luck!