What exactly is this 3D object inside my axis and how to attach it to a colormap?

I have a figure that was generated by a collaborator, and it's a result of some kind of integration with COMSOL, a software for doing simulations. The simulation was done in COMSOL, and the output is generated as a .fig file so it can be viewed in Matlab. This is what I get (though I removed the x and y-axis labels):

I can't quite figure out exactly what kind object (is that the correct terminology?) is actually inside the axis. Because it looks like a surface plot in the sense that I can look at the 3D structure from any angle. But when I try to change the colormap, only the color bar changes. From browsing other questions, etc., my understanding is that only some objects that can be inside an axis are actually tied to a colormap. And a surface plot is one of them. But if this is not a surface plot, then what is it? How can it still have a 3D shape?

And--more importantly for practical purposes--how do I force it to use a colormap which I can then control and change? Ultimately I want to manipulate the colors to make it match the coloring scheme in my other figures.

EDIT: attached figure file

[Mehmed Saad]

can you attach .fig file

[Alexei M]

Ok updated my post with attachment. Can you download it?

Answer 1

[Stephen23]

That figure contains four objects, the fourth one listed is the main axes:

>> fgh = openfig('Resultplot_ID3.fig');
>> fgh.Children
ans = 
  4x1 graphics array:
  Toolbar     (plotnavigation)
  Menu        (&COMSOL)
  ColorBar
  Axes        (Surface: Displacement field, Z component (m))

The main axes has just one child object, which is a patch object:

>> pah = fgh.Children(4).Children;
>> pah.Type
ans =
patch

Patches have several ways of defining their colors based on the axes colormap, explained here:

https://www.mathworks.com/help/matlab/creating_plots/how-patch-data-relates-to-a-colormap.html

But the patch in your figure does not use any of those. It uses what the MATLAB documentation calls "truecolor", where the color is explicitly defined using RGB values, and has absolutely nothing to do with the axes colormap.

>> size(pah.CData) % truecolor (i.e. RGB), nothing to do with the colormap!
ans =
           3      114912           3

You can read more about how that works in the patch documentation, e.g.:

https://www.mathworks.com/help/matlab/ref/patch.html#br92bi7-1-C

https://www.mathworks.com/help/matlab/ref/patch.html#buscm5g-1

"... how to attach it to a colormap?"

The answer is that you would have to replace the truecolor RGB values in CData and/or FaceVertexCData with indices into the colormap, following the array sizes given in the documentation. Unfortunately MATLAB makes it a bit tricky to get the original colormap data (does anyone know a better way?), but the rest is quite simple:

>> warning off
>> S = load('Resultplot_ID3.fig','-mat'); % import as a structure
>> warning on
>> old = S.hgS_070000.children(2).properties.Colormap; % old colormap
>> image(permute(old,[3,1,2])) % optional: view the colormap
>> [idx,idy] = ismember(pah.FaceVertexCData,old,'rows'); % indices of patch colors in colormap
>> all(idx) % check that all colors used in patch exist in colormap
ans =
     1
>> pah.FaceVertexCData = idy; % replace truecolor with indices
>> pah.CDataMapping = 'direct';

Now the patch colors are "attached" to the colormap, exactly as you requested. This only needs to be done once: after that you can simply change the figure colormap to any which has 256 colors, e.g.:

>> colormap(fgh,autumn(256)) % any colormap you want, must be 256 colors!

Alternatively you could have to update the CData and/or the FaceVertexCdata properties with new RGB values, but this requires updating those arrays everytime you want to change the colormap (i.e. it does not actually "attach" the patch colors to the colormap as you request).

[Alexei M]

This is great, thank you! This method does mess up the scale by the color bar, which represented units of length. But I guess what you said at the end about updating CData/FaceVertexCdata properties would prevent that. Oh well, this works for me--I'm doing image editing later anyway, so the changed scale values can be redone.

Answer 2

[Ameer Hamza]

I am not sure why anyone would use patches instead of a surface object to make such a plot. However, the following shows a simple way to modify the "colormap" of the patches and colorbar

fig = openfig('Resultplot_ID3.fig');
p = findobj(fig, 'type', 'patch');

[clrs, ~, idx] = unique(p.FaceVertexCData, 'rows');
new_colormap = cool; % <<==== new colormap name. It you make a custom colormap, it must have 256 RGB colors
colormap(new_colormap);
new_colormap(171:end,:) = flipud(new_colormap(171:end,:));
p.FaceVertexCData = new_colormap(idx, :);

Note: As pointed out by Stephen in the comments, the output of unique() is not necessarily an ordered colormap. For the figure you attached in the question, there was just a single discontinuity, so fixing it was easy. However, for a general case, you need another method to first arrange the output of unique() into a colormap. One interesting method is to use HSV colorspace as described here: https://stackoverflow.com/questions/2245842/sorting-colors-in-matlab

Also read the following links

https://mathematica.stackexchange.com/questions/87588/how-to-sort-colors-properly

https://www.alanzucconi.com/2015/09/30/colour-sorting/

[Stephen23]

"I am not sure why anyone would use patches instead of a surface object to make such a plot"

We can determine the reason simply by looking at the figure.

When we look closely, it is clear it is not a plot of a function of x and y. It is actually a solid 3D object (a very thin one perhaps, but a 3D object none the less) of the type that would be commonly used for some FEM analysis. The triangulation also indicates that this is based on FEM data, or something very similar.

Not only that, but according to Wikipedia, COMSOL is "a cross-platform finite element analysis" tool, so naturally it works with triangulated solids and not with surfaces.

So the short answer is: because a surface object could not actually represent that 3D object.

Zoom of the 3D object's edge (definitely not a plot of a function of two variables):

[Ameer Hamza]

Yes! Zooming in indeed reveals that it is a solid object. Using patches does make more sense here. From its general appearance, it appeared like a surface.

[Stephen23]

I don't see how unique helps. The (third output) indices returned by unique are relative to the sorted first output clrs, but the order of the sorted RGB rows is rather arbitrary and bears no real relationship to the colormap order. It will certainly will not be the same between different colormaps. We can visualize the sorted colors easily:

>> image(permute(clrs,[3,1,2]))

giving:

We can see that this order does not represent the original colormap order shown in the figure. The obvious discontinuity occurs between indices 170 and 171, so we can look for those colors in the new colormap. One simple way is to change the colors around rows 170 and 171 to something that we can easily spot, e.g.:

new_colormap = cool(256);
new_colormap(160:170,:) = 0; % black
new_colormap(171:181,:) = 1; % white
p.FaceVertexCData = new_colormap(idx, :);

And now that discontinuity is easy to spot in the figure as well (the black and white colors should be adjacent to each other... but are they? (hint: you can find the white in the very corner):

[Ameer Hamza]

Ah yes! unique will not necessarily order them in the order of a colormap. Thankfully there is a single discontinuity, so a quick fix can be applied.

[Alexei M]

Hey guys, this is awesome! I think this will resolve my problems (eventually)... I'm going to look through the links in the answer.

But, while I work on that, could you also clarify a few things?

1.) I will need to use a custom colormap here rather than one of the built-in ones. I have another question active about how to copy a colormap from an existing color bar--which was not MATLAB-generated. So my question is, why does the colormap have to be 256 colors, as written in your comment? The line,

new_colormap = cool;

creates a colormap of only 64 colors. So... how does that square with your comment?

2.) What is this "output of sort()" that you're referring to in your note? It's not in your code nor in Stephen's comment...

[Ameer Hamza]

Ok. According to the tag on your question, you are using R2018b. Therefore it only returns 64 colors. In Later versions, the default value is changed to 256 colors. You can get the same using

new_colormap = cool(256);

As for why 256 colors are needed? Because the .fig file you shared has 256 unique colors in its colormap. Having the new colormap of the same length makes the thing easy. Using a bigger or smaller colormap will likely make the code unnecessarily complex. I recommend you to convert your custom colormap to 256 colors, for example, use interpolation.

"What is this "output of sort()" that you're referring to in your note?" That was mistake. I was referring to unique().

[Stephen23]

"I think this will resolve my problems..."

No it won't, because the sorted colormap bears no useful relationship to the original colormap order. In order to replace the patch colors you need to know their original positions in the colormap (so that you can replace with the corresponding color from the new colomap), not their position in some arbitrarily sorted RGB data.

Sorting RGB triples is essentially meaningless for this task, but that is what unique does.... and its output indices are (as I wrote earlier) relative to its sorted output, not your original colormap order.

In any case, in my answer I aready shown you exactly how to replace the truecolor data with the correct indices (not sorted!) so that you can use any colormap of your choice.

[Alexei M]

Thank you both. Either way, I learned some things here.