how to extract data to table or matrix from .fig which has cell type data
Show older comments
Hi,
I want to extract data from a figure (.fig format). I do:
open('EstimatedSNR_Range.fig');
h = findobj(gca,'Type','line');
x=get(h,'Xdata');
y=get(h,'Ydata');
X2=cell2mat(x);
==>Error using cat Dimensions of matrices being concatenated are not consistent.
Error in cell2mat (line 84) m{n} = cat(1,c{:,n});
X2=cell2table(x); ==>Undefined function 'cell2table' for input arguments of type 'cell'.
I attached how the x and y look.
Accepted Answer
x and y are double vectors when you return them with get, not cell.
There's no need for cell2mat as the error is telling you.
Use
which x
to verify.
ADDENDUM: This is really not true; see follow-on comments that get the right answer. The above was based on an assumption that the handle was a single value, not a vector.
17 Comments
Keith
on 11 Mar 2014
Edited: Walter Roberson
on 11 Mar 2014
Walter Roberson
on 11 Mar 2014
Attachments are missing.
dpb
on 12 Mar 2014
Actually I meant whos, not which -- what does
class(x)
return?
I don't understand how you can get anything but an array -- iff'en I open a figure here like you I get the following --
>> open('fig1.fig')
>> h = findobj(gca,'Type','line');
>> h
h =
369.0016
368.0016
367.0016
>> x=get(h(1),'xdata');
>> whos x
Name Size Bytes Class Attributes
x 1x152 1216 double
This particular one had several lines so I just retrieved the first.
And, I've never seen a display like
{}x = <136X1 cell>
{}y = <136x1 cell>
in the workspace. How did you get that?
I'm at a loss, sorry; maybe Walter can help.
I also can't find any way to plot a cell array w/o converting it to an array. Well, let's try one other thing--
>> set(hL,'ydata',{y})
Error using set
Conversion to double from cell is not possible.
No, not even that will work to try to shove a cell into the 'YData' property of an existing plot. There's more going on here than meets the eye, apparently.
What version of ML? Maybe they've done something brand new and different since R2012b.
Keith
on 12 Mar 2014
Need to format your code -- use the {}Code button or just put two spaces in front of first line of code. Keep at it until it looks right in the preview window. Then we don't have to. Don't know why on a code forum TMW doesn't make that the default instead...
>>open('EstimatedSNR_Range.fig'); ==> opens the figure(attached)
>>h = findobj(gca,'Type','line'); ==> shows h in workspace
>>whos h
Name Size Bytes Class Attributes
h 136x1 1088 double
>>x=get(h,'Xdata');==> shows x in workspace as {}x = cell
>>whos h Name Size Bytes Class Attributes
h 136x1 1088 double
>>x=get(h,'Xdata');==> shows x in workspace as {}x = cell
>>whos x
Name Size Bytes Class Attributes
x 136x1 18968 cell
>> class(x)
ans = cell
What you can see from the variable window is that indeed it is a cell array and the reason you're having trouble is that excepting for the first which is two, each odd-number cell contains three values. Meanwhile, the even-numbered cells are a single double. It's that disparity in sizes that's the cause of the failure of cell2mat because indeed there's not the same number of elements in each row as it tries to build an array.
It looks like you should be able to extract
y=y{2:2:end}
ADDENDUM:
Being as it's a cell array the above is a list that must be concatenated--use
y=[y{2:2:end}]';
instead.
Keith
on 12 Mar 2014
I was a little groggy when I looked this morning...I overlooked something.
>>whos h
Name Size Bytes Class Attributes
h 136x1 1088 double
NB: that h is an array of 136x1 handles. That means that whoever built the figure did it piecewise instead of as a single line. I missed noticing that concentrating too much on the data.
The difference that I consequently overlooked is that get for multiple handles does encapsulate results for each in a cell array and looking at the figure while overlooking size(h) made it seem as though there should have been a handle for the primary trace.
The problem with the form I suggested is that it returns a list for each cell. You need to concatenate the list into an array by enclosing in square brackets.
x1=[x{2:2:end}]';
should work. Similarly for the other handles holding consistently-sized arrays per cell.
It would be a_good_thing (tm) perhaps if you could get the originator of the figures to modify the creation of them such that the number of handles is reduced. Basically that would be to have all the data and plot the full arrays instead of as a point-by-point with, apparently, line as was done instead of plot.
So, the upshot is, the changes aren't fundamental to Matlab but are in the way the figure was created. I'll edit my previous comment to remove the (incorrect) speculation for the record.
Keith
on 12 Mar 2014
The data that's in your earlier variable window (outside the first point which I have no clue above) appear to be a value and then a value with what I initially thought was an error band but it appears to actually be the y-axis limits. How they got that form I've no rational idea; would wonder if it wasn't, perhaps, a very inexperienced with Matlab summer intern or somesuch that did it for them.
The most puzzling thing even beyond that is that I see no correlation at all between those data and the figure. Are you sure you don't somehow have a mismatch in windows you're looking at? What if you open the figure and use the figure editor tools; do you see the same values?
The negative instead of positive slope on the plot of the x-array implies the data was added in reverse order ( while I didn't run a test case to see for sure which way the handles are stored/retrieved I think they're chronological).
If the other company would share it, it would be most interesting to see the code underlying the graphics. As is currently, if I were in your position trying to do something with them I don't think I'd trust anything (yet, anyway) until they could 'splain to me what I'm actually looking at and why the data don't seem to match the graphics.
Keith
on 12 Mar 2014
If you're not constrained by IP restrictions or some other reason, how about sending the file to me and I'll explore into it a little more than can do just by looking at the picture of it. Perhaps I could figure out something else if had it to actually poke on with a stick. You can get to me via the Forum even tho the address isn't public. If you can't do that, I understand.
I'll have to investigate the ? on the Plot Editor; I've never tried that.
ADDENDUM: No, doesn't appear to be.
Keith
on 12 Mar 2014
dpb
on 13 Mar 2014
OK, didn't think about doing it that way; I've got it; yes you can now delete it if prefer it not be around for others to look at as well. I was thinking of privately but this is ok if you're ok... :)
And, I'm NOT TMW; just an old retiree that likes to keep in hand w/ Matlab now and again. I'm farming now as the "day job" but weather last couple of days and taxes/bookwork has kept me in so I'm doing this to distract from what should be doing. :)
OK, I've uncovered at least some of the mystery...maybe you know what the nature of the problem is enough to be able to unravel it from here.
I still have no clue why they created the gazillion handles of one and three entries each -- I'm still guessing it is basically operator error/inexperience in Matlab programming.
The key to the whole mystery lies in that there are three line handles at the very end that have the full 167 data points in each. All three of the x vectors are the same but each y vector is unique. BUT, the key point is that the middle one of these three matches the primary trace in the figure. The first and third bracket it and apparently are error bounds I presume.
Now the million-dollar question is, what are all the rest that don't seem to match any of the others or can you, if you dig deeply enough actually figure out that they do match one or another of the three?
MAYBE your vendor can tell you but there's still my initial guess in play I think... :)
Anyway, good luck...interesting mystery, I'll be interested to hear what you finally resolve.
dpb
on 13 Mar 2014
Wow! I'll have to investigate--I didn't think the grid was saved as line handles but basically generated on the fly from the tick spacing and status of the major/minor grid properties. OK, w/ an "ordinary" figure here that seems to be so.
So, I'm left with the previous presumption that the vendor is doing something pretty silly to cause all those handles to be being generated.
I can't explain the mismatch in data--afaik there's no way to get a line displayed that doesn't match at least one [x|y]data array. I don't have as much time today as the weather's broken but if you were inclined to forward the saved new image to me via my email in the "contact" area I'd try to find a time over the weekend anyway if not today to see if can find the matching data.
It does seem like what you've got is the same but with and x offset early but then the latter portion doesn't look at all the same. Oh, going and looking more closely...your blue line has an offset and gain in x--the last value you show at 50 m is the rising edge of the peak at about 37 m in red. The y magnitude is the same; it's just offset and gain-shifted in x relative to the other red line. How/why that is I don't have an explanation for at the moment.
dpb
on 13 Mar 2014
_...made me understand that I should not plot only y...used plot(x,y)..."
Ah, yes, that (I thought) went w/o saying... :)
I don't follow the reasoning on why you need to plot the same data in Excel. Just plot what you retrieve on a new axis/figure will prove it although that you reproduce the line in the given figure proves it on that data anyway.
To automate the retrieval from figures should be fairly trivial if you have a given configuration so you know which handle it is that you're after. Altho then I'd wonder what the actual analysis path is that is generating the plots--why can't you get the data that's making them directly instead of retrieving from the figures?
Keith
on 13 Mar 2014
More Answers (0)
Categories
Find more on Data Import and Export in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
