Retrieve legend handles and text

I want to retrieve legend handles and text of an already created figure.

I am getting the desired output by [~,~,plots,txt] = legend(___).

It works fine on my machine but it doesn't work in an another machine (plots and text return empty).

Also, MATLAB also doesn't recommend this because of graphics issues. So my understanding is that there is graphics problem in the other machine.

So is there another way to get legend handles and text?

[Geoff Hayes]

Praveen - is the same version of MATLAB used on both machines?

[Walter Roberson]

What is it that you need to do with the handles? And which MATLAB releases are involved?

[dpb]

As Geoff and Walter note, revisions are significant here altho I note that the same output syntax is supported from as early as R12 thru current. However, with R2014(or thereabouts) handle graphics changed drastically internally from HG to HG2 and if one plot was generated and saved as .fig file on one system and then displayed on another crossing that great divide it's not too surprising (albeit disappointing) that such low-level compatibility has been broken.

Any hope will depend on these issues and what it is, as Walter asks, you really need to do...likely there are coding changes that can be made to the second system to manage to retrieve the data, but it's possible I suppose that the gulf is just too wide...

Answer 1

[Walter Roberson]

You cannot use a call to legend() to return handles to an existing legend. legend() historically always created a new legend. There are now a couple of syntaxes legend('show'), legend('boxon'), legend('boxoff') that do not always create a new legend, but in the cases where the legend already exists, the

[a, b, c, d] = legend(....)

syntax returns b, c, d as empty (at least in current implementations.)

When you use the

[a, b, c, d] = legend(....)

syntax in R2014b or later, the legend gets built differently. It gets created as a legend object, but the ItemText property gets instantiated with the handles to the text objects, whereas otherwise the ItemText property is set empty. (There might be other changes that I overlooked.)

I have not yet found any way to obtain the text handles of an R2014b or later legend that was not created with the [a, b, c, d] = legend() syntax. If there is a way, it would involve fishing through the various listener and callback properties and using functions() to obtain the static workspaces that might contain references to the actual objects.

But if the question is not about restoring from a .fig and is instead just about doing something with the properties of a legend that you just created, then the [a, b, c, d] = legend() syntax is still supported for now, and the question becomes what you want to do with the handles, as the mechanism for whatever it is you are trying to do might have changed.

[dpb]

"I have not yet found any way to obtain the text handles of an R2014b or later legend that was not created with the [a, b, c, d] = legend() syntax."

This penchant TMW has developed of making internals totally opaque, while popular in CSci circles, certainly makes for customization of anything they haven't thought to make a method for either a pit(proverbial)a(ppendage) or just downright impossible. I, for one, truly dislike it to the point if I were deciding to get back int to the consulting game I'd likely choose to not update Matlab at all as I was always running into things (particularly with respect to graphics fine-tuning) that just aren't quite the way they need to be.

As a plus, and in their defense, they did introduce some new features (the ruler object for one) that does ease some longstanding issues such as setting axes numeric formats, but to remove some other things by the change in access whether intentionally or just as a side result seems overall a net loss. A little less effort in being able to fix up something even if took a little more effort before just doesn't seem to make up for other things disappearing entirely.

I just discovered another in interp1 that I have a ton of code that depended heavily upon--no longer does it interpolate columns of an array of Y values given a vector X as an array of interpolated values of that many columns; now you have to write a stinkin' loop and update the X,Y properties for each column each pass thru... :(

[Walter Roberson]

dbp, what you describe for interp1's former working is still documented as being the current behaviour:

"If you have multiple sets of data that are sampled at the same point coordinates, then you can pass v as an array. Each column of array v contains a different set of 1-D sample values."

and testing in R2016a and R2016b confirms it works:

x = 1:20; y = [x;x.^2;x.^3;x.^4].';
interp1(x,y,linspace(3,4,5))
ans =
                       3                         9                        27                        81
                    3.25                     10.75                     36.25                    124.75
                     3.5                      12.5                      45.5                     168.5
                    3.75                     14.25                     54.75                    212.25
                       4                        16                        64                       256

[dpb]

Sorry, I was just a little premature in what has yet apparently occurred; was reacting to the note in local documentation (R2012b) and presumed by now the threat had been followed up on. Maybe there was enough pushback to halt or at least delay this foolishness.

Note:  
... the following syntaxes will be removed or changed in a future release:
...
interp1(x,Y,...) where
x is a vector and Y is an array representing multiple value sets.

The links from there take one to release notes describing the workaround of an explicit loop. Hopefully the delay has turned into a permanent rescission?

ADDENDUM

Well, how 'bout that! Logic seems to have prevailed; although interp1 is sorta' now in the same "red-haired-stepchild" status as textread of being deprecated/discouraged, I see that the latest documentation even highlights the formerly-to-be-removed functionality as a featured example! [ :) ]

Consistency in direction is nothing if not consistently changing; a real difficulty in counting on Matlab in production environment as others have noted. I suppose this one had enough other users besides just me to have survived or they simply decided to stop using resources to modify it with the transition to the gridded interpolant route as primary.

[Walter Roberson]

I just created a service request asking about the status of the change for array Y for interp1()

In current documentation, the use of 'pp' is the only syntax that is recommended against.

[dpb]

Indeed, it'll be interesting to see what tack TMW chooses to respond under... :) There're beginning to be real consequences to the rapid deployment of new features and implementation; they've got the Fortran backwards-compatibility issue in spades of needing to find ways to continue the evolution yet not break too much going forward.

Fortran has chosen to keep the compatibility at almost all cost including just recognizing some potentially desirable features just may not be implementable as one would like. TMW, otoh, has chosen instead to keep adding duplication of functionality (with the hope of eventually, I suppose) deprecating much (on a relative scale) or simply announcing such as here that functionality will change. Sometimes they've kept legacy switches; other times, "not so much".

It's not so bad if one is introduced at some point as new user or if there aren't very long term requirements to maintain an application or the need for QA on results. That functionality can change is the most scary part; it may not be able to be seen that results aren't the same if a version is simply updated and new cases are run going forward without checking a test suite to verify same behavior.

None of this is news to you, of course, simply observations brought to mind by the subject question here where they've made changes that superficially may seem unimportant but for some users may create issues.

[Walter Roberson]

Mathworks replied that using the griddedInterpolant loop is an efficiency matter, but that the results would be the same, and the array Y is not slated for removal.

[dpb]

Interesting they would go to the trouble to provide compiled new routine w/o the facility but force the user to do the looping. interp1 is just an m-file, though, so there may be a speed advantage at the loss of the convenience.

Wonder why they changed their minds, though...altho one presumes if they'd committed to the new routine figured might as well just abandon the other as is as cheapest.

Anyway, thanks for the update/asking the question...

[Walter Roberson]

I did some timing tests and it turns out that using interp1() with the 'extrap' specification is faster than using griddedInterpolant in a loop over columns. interp1() without 'extrap' can be slower than looping griddedInterpolant over columns, but the timing difference is almost entirely due to extra memory copies as interp1 bashes NaN into appropriate placces.

[dpb]

Interesting results, Walter, and thanks a lot for the testing. I've used the idiom with the array quite a lot in some test data collection/analysis routines over the years but the sizes haven't ever been terribly big on individual cases; we had 8 coal pipes on a burner at a given level generally all we were monitoring although there can be as many as eight levels in a larger boiler. That's still not all that big but the compact code makes it worth a little tradeoff anyways as long as it's not a humongous penalty. Of course, prior to the intro of griddedinterpolant it was interp1 or "roll your own", anyways... :)

[Afiq Azaibi]

Starting in R2024b, calling legend with multiple outputs will throw a warning. It will continue to function as it has previously.

[dpb]

@Afiq Azaibi I believe R2024a also made the 'IconColumnWidth' property visible; however, it is a global setting the width of all columns. A posting just a day or so ago <Scatter plot legend with multiple columns> with the need to display the markers without the text illustrates that was shortsighted; the IconColumnWidth should be by column so one could place the two markers as subsets of a given label without the excess blank space left for the non-present text.

Or, alternatively and probably better; have the 'ColumnMarkerWidth' actually control the marker and have a second for the text, say ColumnLabelWidth'.

[Afiq Azaibi]

@dpb, if you can share the post you're referring to, I'd be glad to take note of their use case for an enhancement to the existing feature or a new one.

[Afiq Azaibi]

Thanks for updating the comment to point towards the post. To provide you with a little bit more context, the IconColumnWidth property introduced in R2024b is a step towards giving users more control over the legend appearance. You're right that it doesn't yet offer the detailed level of customization for individual legend icons that you're describing. In efforts to squeeze in incremental enhancements based on user feedback, there have been several updates aimed at improving legend customization over recent releases including controlling the sort order of legend items with the Direction property (23b), setting background transparency with the BackgroundAlpha property (24a), and now the IconColumnWidth (24b). The need for more granular control over legend items is on our radar. Thanks again for your contribution and interest!

[dpb]

I grok; it's been a somewhat rough ride for users away from having access to the underlying axes object and its children's handles from bygone era through a period when it was quite opaque and finally a journey back towards transparency and enhancements...

For other reasons, I've stayed at R2021b so far so some of these things I've just come across here.

Answer 2

[Peter Reinprecht]

in R2014b or later you can extract the line and legend object separately from an already existing figure

Legend object

hLegend = findobj(gcf, 'Type', 'Legend');
%get text
hLegend.String

Line object

hLines = findobj(gcf, 'Type', 'Line');

[Walter Roberson]

The line objects you get this way are not the line objects belonging to the legend. Even if you

findall(gcf, 'type', 'line')

you will not be able to find the sample line that is used for the legend.

[Brandon Ballard]

If you are looking for a way to adjust the length of the lines in an existing legend then I would suggest using the following commands.

hLegend = findobj(gcf, 'Type', 'Legend');
hLegend.ItemTokenSize = [x1,x2];

By default the values for x1 and x2 are 30 and 18 respectively, so reducing the numbers will result in a smaller line in the legend window. However, the line style will remain identical to the lines used in the plot.

This code is only an application of that found in the link below:

https://uk.mathworks.com/matlabcentral/answers/396439-how-to-increase-the-length-of-the-legend-line

Answer 3

[Captain Karnage]

I'll admit that findobj is a quicker, easier way to find the legends, but in case you want a way that kind of shows you the structure and where the legend is at, this works in R2022b (don't know about previous versions):

legendclass = 'matlab.graphics.illustration.Legend';
%Get the currentfigure
thisFigure = gcf;

%Get figure children
theseChildren = thisFigure.Children; %Alternately, gcf().Children works if you don't need a handle to the figure object
numChildren = numel(theseChildren);
for child = 1:numChildren
    thischild = theseChildren(child);
    if ~isa( thischild, legendclass )
        thisLegend = thischild;
    end
end

If you might have multiple legends, you can make thisLegend a cell array and increment an index counter each time a legend is found.

The one advantage here is you can get handles to the various objects in the structure along the way if you need them for other operations.