EBSD rotating/cropping artifact

[djm87]

Hi Guys,

Sometimes it is nice to rotate EBSD in-plane to align with the material frame followed by cropping, but there are pixel artifacts from this type of procedure and there doesn't seem to be a simple way around. e.g. If EBSD is not resampled, the edges of the EBSD image look like:

Regridding the EBSD with gridify results in sampling artifacts e.g.

Best, Dan

[ralfHielscher]

Hi Dan, of course you should not use gridify on the rotated map. Apart from this I did not observe that rotating causes issues. What have you done to generate the first image?

Ralf.

[djm87]

Hi Ralf,

Thanks for getting back quickly.

You can reproduce the jagged edge by cropping any EBSD dataset in which the grid is rotated (example is given below) or just by viewing a hex grid image.

There are two problems that I'm bringing up. First, is producing nice borders when plotting non-square EBSD unit cells and grids. I found a workaround for this using the xlim and ylim to limit my view of the EBSD dataset to a region of interest. Maybe a border overlay feature would be nice.

Second, is re-gridding rotated, structured datasets. Per the function description, gridify is supposed to transform non-structured EBSD into a structured grid. If a point in the new regular grid does not have a corresponding point in the old EBSD dataset, then it is set to unindexed in the new regular grid. For a fully indexed, rotated but structured grid to result in unindexed points seems to point to some limitation in the row/column index extraction method: gridify.m line 135-145 in MTEX-5.3.

I've run into issues in the past when unwarping/registering EBSD data to other imaging modalities and I'm sure there are other applications that would benefit from a more robust gridify function.

Along these lines, what is the appropriate way to do hex to square grid conversions now that the gridify function supports the hexagonal unit cell?

Example:

% import the data
mtexdata titanium

% grid data to start
[gebsd,~] = gridify(ebsd);

% Rotate scan
rgebsd=rotate(gebsd,rotation('axis',zvector,...
    'angle',20*degree));

% Crop to center
cropSz=700;
xm=(max(rgebsd.x)+min(rgebsd.x))/2;
ym=(max(rgebsd.y)+min(rgebsd.y))/2;
ch=cropSz/2;
cropDim=[xm-ch,ym-ch,cropSz,cropSz]

crgebsd=rgebsd(inpolygon(rgebsd,cropDim));

% Plot data with xlim,ylim crop
h=figure;plot(rgebsd,rgebsd.orientations)
xlim([cropDim(1),cropDim(1)+cropDim(3)])
ylim([cropDim(2),cropDim(2)+cropDim(4)])

% Plot as cropped data
figure;plot(crgebsd,crgebsd.orientations)

% Regrid
gcrgebsd=crgebsd.gridify;

% Plot regridded data
figure;plot(gcrgebsd,gcrgebsd.orientations)

Best, Dan

[ralfHielscher]

Hi Dan,

this seems to be a resolution issue. If you zoom in the pixels are all correct. The point is that MTEX only specifies the polygonal shape but not the pixels. This rendering is done by Matlab. I guess you have to export your figures at a higher resolution to get rid of this artifact.

Ralf.

[zmichels]

Hi Ralf and Dan,

When I run the example that Dan pasted, the final plot of the 'regridded data’ has missing points/solutions that didn’t exist in the original data. No matter how much I zoom in, systematically spaced holes (NaN data) persist in the grid plot. I don’t understand how this is rendering resolution issue. Ralf, can you explain how one might avoid the appearance of these NaN points?

Zach

On Apr 13, 2020, at 1:52 PM, Ralf Hielscher notifications@github.com wrote:

Hi Dan,

this seems to be a resolution issue. If you zoom in the pixels are all correct. The point is that MTEX only specifies the polygonal shape but not the pixels. This rendering is done by Matlab. I guess you have to export your figures at a higher resolution to get rid of this artifact.

Ralf.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mtex-toolbox/mtex/issues/471#issuecomment-613039827, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACC5AU75DLAK2CM4OIZAUPTRMNNQJANCNFSM4MGDGUAA.

[ralfHielscher]

Hi Zach,

from my point of view it makes not so much sense to apply gridify on a rotated map. I'm not sure what kind of output one should expect in such a case? Should MTEX interpolate the data on some regular grid? Which one? Currently, gridify only works for data which have already a regular structure - which is destroyed after rotating.

Hence, my previous comment referred to the plot before the gridify command.

Ralf.

[djm87]

Hey Ralf,

I think I understand what you are saying now that I look at the code in more detail. Though gridify appears to be a nearest-neighbor type interpolation, it was developed with a couple of differences: 1) Instead of using the nearest neighbor to define the transfer, the coordinates of the old grid and the unit cell size are used with rounding to get an index on the new grid, and 2) by using coordinates to produce indexes there is a check to limit the extent of the interpolation.

The new grid Nan region has a simple interpretation:

Here is an example of the general nearest-neighbor interpolation which enables gridify to work appropriately with the rotated data. gridify2.m.txt test.m.txt

Dan