How to vary the pixel size in matlab imagesc() plot?

I have data of a heated plate (2m x 2m = L x L) defined by a grid (x- and y-coordinates from 0 to 2 in same or different refinements) and a corresponding matrix containing the temperatures of the centres of the plates fields (the field dimensions are defined by the x- and y-grid).

The imagesc() plot function from matlab creates good results on equidistant grids since every field has the same length and width. However working with an non-equidistant grid requires to adjust all fields dimensions according to x-y-grid.

Is it possible to do this within the imagesc() function?

Code:

imagesc(x,y, sol)
set(gca,'YDir','normal')
colormap(jet(2000)); colorbar;
xlabel('x[m]')
ylabel('y[m]')

x and y are vectors containing the coordinates of the grid, sol is the matrix containing the field centres temperatures.

Plot:

[Heated Plate with equidistant grid]

[Heated Plate with non-equidistant grid]

The non-equidistant grid performs a refinement on the right side of the plate since numerical error is biggest there.

The refinement is defined by

- same discretization for 0 <= x <= L/2 (same for y)

- double fine discretization for L/2 <= x <= L*3/4 (same for y)

- four times discretization for L*3/4 <= x <= L (same for y)

As you can see, the refinement's new field dimensions are not considered which ends up ruining the visulization.

I've already tried different plot methods like surf or pcolor. Both are not well suited for a field-centre-oriented solution.

Thank's for any advice.

Answer 1

[millercommamatt]

What I understand your issue to be is that you have non-uniform spacing of you data points along the x-axis of your data and you're having issues since imagesc assumes uniformspacing.

Try the surf function.

[x_mesh y_mesh] = meshgrid(x, y);
surf(x_mesh, y_mesh, sol,'EdgeColor','none');
view(2);

Also, throw the jet color map out of the window. I recommend the parula built-in colormap or a colormap from the VIRIDIS family avalibale in the File Exchange. If you really just have to have a rainbow color map, there's going to be a map called turbo in the 2020b release.

[Eric Machorro]

While this is a quite useful tip, strictly speaking, this doesnt asnwer the question - the orginal poster is asking how to vary the pixel size, not to just scale the position of the voxel centers. When one has different pixels of different sizes, surf(...) will indeed space the pxel centers correctly, BUT it will can't 'plot' the correct pixel dimensions.

This casn be expecially problematic at edges of an array or image.

[DGM]

I don't think surf()/pcolor() are really appropriate since they apply the Z data to the vertices instead of the faces as the text suggests. There have been attempts to make imagesc() support nonuniform x,y data

https://www.mathworks.com/matlabcentral/fileexchange/35601-sanepcolor-varargin

I thought I saw a newer one recently, but I can't find it.

That said, I don't really see that OP was asking how to vary size independently of spacing. Discretizing a uniform field doesn't suggest that there would be a distinction between the two. If nothing else, a truly arbitrary combination of size and spacing could be expressed with some elaborate use of scatter().

I could suppose that OP is maybe trying to create an image where L-shaped regions are sampled at different densities -- which could lead to confusion, since the obvious solution might not be what they expected.

Consider this example. I'm using pcolor() simply because it can give a quick visualization, not because I think it's an appropriate tool for answering the question.

% xy data with a density step
x = [1:2:20 21:40]; % [(lo density) (hi density]
y = x.'; % same

% z data
Z = x.*y; % just something smooth

% that's probably unexpected
pcolor(x,y,Z)

One might think they created an L-shaped region of one density, and a square of another density. In reality, they get this mess with rectangular pixels and three characteristic densities instead of two.

If that's the issue, then this is a more difficult problem than OP probably expected. If we create nesting L-shaped regions of square pixels of different spacing, we basically no longer have a gridded problem (at least not yet). Something like these hypothetical arrangements:

I'm sure we could come up with ways to illustrate such a thing, but given that OP's data is held in three rectangular arrays, we can be fairly sure that the data is already not of this form. We would expect the data to either be expressed in a scattered form as vectors, or perhaps as a piecewise form with multiple 2D sets. If this is coming from a simulation, I'm not sure that either of these would be expected arrangements.

Again, I can't be sure what OP really needed. That's just a strained guess as to the underlying problem presented in the question. If you have your own form of this or a similar problem, you're free to elaborate.