state which frame a sequence of images is in, and lay them out that way
Where a raster array sits relative to a specimen is not derivable from the array, so two images are not comparable until they are stated in one frame. This is the step that states it. It is deliberately explicit: the relation is a fact about the experiment that only the person who ran it knows, and guessing it silently is how a mirrored map reaches the end of a workflow and returns nonsense.
Description
The relation may be given three ways, most certain first:
ori the rotation, when it is known outright
'byScreenAlignment' inferred from the assertion that the frames were
plotted together and seen the same way up
neither read off the two bases, when both already carry oneLike <Miller.transformReferenceFrame.html the method of the same name on Miller> this changes the numbers, not the thing: nothing is resampled and no value changes, only the layout and the frame stamp. Only a signed permutation can be applied by reindexing, so a relation that is not axis aligned raises rather than silently resampling.
A map travelling with an image is turned with it, so the two stay in one array order and ebsd.bc can sit beside img without a conversion.
Syntax
mg = transformReferenceFrame(mg,gL) % a layout
mg = transformReferenceFrame(mg,other) % that of another image
mg = transformReferenceFrame(mg,fr,ori) % the rotation, known
mg = transformReferenceFrame(mg,fr,'byScreenAlignment')Input
| mg | mapImage, one or an array |
| gL | gridLayout to lay the array out in |
| other | mapImage, meaning its layout |
| fr | referenceFrame every entry is to end up in |
| ori | orientation from an entry's frame to fr, when it is known |
Output
| mg | the same images, laid out in the target |
See also
mapImage gridLayout orientation.byScreenAlignment EBSDsquare.transformReferenceFrame