Any plans to create a class also containing quality metrics (CI, IQ etc.) in addition to orientations?

[hakonanes]

Hi all!

Are there any plans to create a class also containing quality metrics (CI, IQ etc.) in addition to orientations? I'm asking for mainly two reasons:

• I'm starting to create quality metrics maps (Krieger-Lassen's image quality and soon average dot product map akin to EMsoft's) in KikuchiPy, and want it to be easy to create navigation masks and to navigate patterns in these instead of a virtual image or just the mean intensity of each pattern. I had in mind a sort of Map class, where I can easily do s.plot(navigator=m.iq) e.g. However, it would be natural to couple these maps to orientation data, which would fit in orix...
• Also, I plan to write a reader for EMsoft's dictionary indexing result file (HDF5), both orientations and quality maps. Should I add a load_emsoft function along with the other load functions under io/__init__.py, or does anyone have any other plans or preferanses?

I see the use of orix as the natural step forward to couple EBSD patterns directly with orientation data (from indexing in other softwares, for now), quality metric maps etc. in KikuchiPy. I'm therefore also interested in just generally hearing your future plans for orix.

[dnjohnstone]

Hi @hakonanes,

Short answer - yes, and we'd be delighted if you were to get involved with this!

For us, so far, this functionality has been in the CrystallographicMap class in pyxem (https://github.com/pyxem/pyxem/blob/master/pyxem/signals/crystallographic_map.py)

But, as is obvious from that class having a save_mtex_map() method, when we wrote that we hadn't made enough progress with orix and were imagining any analysis of the CrystallographicMap happening in MTEX. I think we both agree that MTEX is fantastic but there are some appealing aspects to have a fully python based pipeline.

As we move forwards - the vision is definitely that crystal orientation analysis in our workflows would eventually happen in orix and maybe one day we'll be able to do very many of the things that a package like MTEX does.

So to address your particular points:

1. Yes I think we need a class also containing quality metrics.

2. A load_emsoft function would be great, and for now putting it in io/init.py is fine - we can work on improving that stuff if it's an issue.

Some other assorted code structure points that are in our minds include:

1. We want to keep orix as light as possible in terms of dependencies. Most particularly (given your/my background), that means we want to avoid a hyperspy dependency in this package unless it is really justified. My feeling is that a phase/orientation/metric map is not really a hyperspectral Signal class so this is appropriate. This means that we imagine KikuchiPy/pyxem depending on both hyperspy and orix and any analysis that requires both of those being put downstream.

2. We're now aware that there may be some functionality that we've inadvertently replicated from other well established packages e.g. transforms3d, numpy-quaternion - it would be good to determine if we should be be adding dependencies to these libraries as soon as possible because it will only get more painful to change that down the line.

Does that help?

[hakonanes]

Thanks for a fast and detailed answer, @dnjohnstone!

Ah yes, I was aware of the CrystallographicMap, but forgot it yesterday... So from your particular point 1 I take it that functionality in that class will be taken over by a new class in orix?

I have no problem with trying to avoid using HyperSpy for these readers. The reason I wanted it to depend on HyperSpy was based solely upon the ease of calling s.plot(navigator=m.iq) instead of s.plot(navigator=hs.signals.Signal2D(m.iq)), which I now realise isn't enough of a reason...

Thanks for the last two points, it is really useful info to have before starting to contribute to orix! So far, I'm mostly interested in creating navigation masks based upon quality metrics, so I don't think I will look into transforms3d or numpy-quaternion now.

Regarding the EMsoft reader: I've moved the discussion to a new issue #47, since the question I posed got a thorough answer.

[pc494]

This was superceded by #47 and #48