trisurf interpolation changed behavior in 2014b

Hello,

Matlab 2014b brought changes to the whole plotting functions. Unfortunatly, this introduced a bug into a plotting function that i use frequently. I measure data on a sphere around an object (usually loudspeakers) and plot magnitude and phase of this data using trisurf.

The phase is plotted as the color. As it is only defined between 0 and 2*pi, there are points, where the phase jumps from one end of the color bar to the other. The colorbar is set to have the same color on both sides, so that these jumps are not visible (colormap hsv).

An example created with the attached function is shown in this figure:

The magnitude of every point on the sphere is set to one, and the phase is changing with azimuth direction from 0 to 2pi.

Since the change to 2014b the trisurf interp option introduces a "rainbow" between these points.

Although this behavior can be considered correct (there is a value of 0 next to a value of 6 so there has to be every other value in between) it is not really suitable for my uses as the phase is not continuous. This plot now suggests corrupted data of some kind.

Without the interp option (option 'FaceColor','flat') this break is no longer visible. Unfortunately the plot in itself does not look "presentable" any more (not really visible in this example case).

My guess is, that matlab used to interpolate between the color of neighboring faces and is now interpolating between values.

My question now becomes: Is there a way to switch between these suspected modes?

[Eric Sampson]

Jan-Gerrit, if you don't get a satisfactory answer here or on the newsgroup, you could try posting a link to this question on graphics developer Mike Garrity's blog and see if he responds, a relevant post of his to comment on might be this one: http://blogs.mathworks.com/graphics/2014/11/18/what-is-a-surface/

Answer 1

[Mike Garrity]

I think I can guess from the picture. If I'm right, you've got CData which is a scalar value per vertex (as opposed to RGB colors) and your renderer is opengl.

Assuming that's correct, you've actually encountered a bug in the old opengl renderer which we fixed in 14b. Here's the bug:

surf(peaks,'EdgeColor','none','FaceColor','interp')
colormap(flag)
set(gcf,'Renderer','zbuffer')

yielded this picture in 14a.

But if you switched the renderer to opengl, you got this picture:

What was happening is that the opengl renderer was converting the scalar CData values into an RGB value at each vertex and then linearly interpolating those RGB values. That looked OK if your colormap was really smooth because you couldn't see the difference between the two types of interpolation. But when your colormap had discontinuities, it looked really awful. We fixed that in R2014b so that all of the renderers do the same thing:

But your colormap doesn't have discontinuities, does it? No, but it's actually a related case. Your colormap is cyclic. And some of your triangles have vertices with colors from the top and vertices with colors from the bottom. As you've guessed, the interpolation of the CData values is linear between those these values. If you marked the values on that colorbar, you'd see that the interpolation hits all of the colors between them. What you really want in this case is to go around the "other side" of the cyclic colormap. In other words, off the top of the colorbar and back on the bottom, if that's shorter than interpolating across the interior of the colorbar. But there isn't any way to tell MATLAB to do cyclic colormap interpolation. RGB interpolation looked like it was doing that, but it was really just doing linear interpolation in the RGB space. If your colormap was smooth enough, you didn't notice the difference.

There is a way to get the old behavior, you need to give the graphics system RGB values. You can do this by running your CData through ind2rgb.

[Jan-Gerrit]

that did work for me

thank you very much