pyxem
Add projection/pattern center arrays to CrystalMap from TSL .ang reader
.ang files from EDAX TSL contain the mean projection/pattern center (PC) for the whole map, in their convention x*, y*, z*, in the header:
# TEM_PIXperUM 1.000000
# x-star 0.587700
# y-star 0.798700
# z-star 0.511600
# WorkingDistance 0.000000
These values should be part of the returned CrystalMap from the file reader in some way. I suggest adding three arrays of the map shape with these values in each map point to the CrystalMap.prop dictionary with names "xstar", "ystar", "zstar". This is simplest, but requires more memory than necessary.
I would like this because I routinly inspect EBSD dictionary indexing results from EMsoft with kikuchipy, where we need the PC to define the kikuchipy.detectors.EBSDDetector.
See e.g. the kikuchipy documentation on EBSD reference frames for an explanation of the PC.
These values should be part of the returned CrystalMap from the file reader in some way. I suggest adding three arrays of the map shape with these values in each map point to the
CrystalMap.propdictionary with names "xstar", "ystar", "zstar". This is simplest, but requires more memory than necessary.
Am I correct in thinking that these variables don't vary across the sample? Does the architecture constrain .prop objects to be arrays - and if so would it make more sense to describe these as metadata?
You're correct, they vary with probe position. TSL only provides the mean PC in their .ang file, so it will be most valid in the map center, and more wrong as you move away from the map center. Although not optimal, I believe it is better to return this per map point than not return it at all, as we don't do now.
Adding to CrystalMap.prop requires one value or multiple values (like the 20 best matching scores) per point, as described in the documentation. It can be considered as metadata, but currently we don't have such a thin in orix.
Sorry, I think I've got myself a bit jumbled. It looks like xstar being an array would work fine (and be consistent with formats that measured the PC at every position) but to save memory you could consider making it a scalar? Part of me thinks that's not worth the hassle though...
No problem, your questions are valid.
A fixed PC for the whole map is actually valid when using EMsoft without PC refinement (this is "turned off" in the default nml (name list) input file to the EMFitOrientation program). Considering TSL also returns one PC for the whole map, I think it is OK to fill the entire map with a fixed PC from .ang files.
Actually, I avoid using orix.scalar.Scalar wherever I can, because I don't like writing and reading code where the .data is needed to get the NumPy array. I haven't looked at the reason why we need Scalar, it might a good one, perhaps it enables us to not check for instance shapes or something similar, but I would be interested in seeing if we can remove completely.