static_background is not stored in metadata upon loading

[htrellin]

I'm having trouble with the static background not beeing stored to the EBSD.metadata upon loading an EBSD recording from a NORDIF .dat file. When looking at the metadata the only thing stored under "static_background" is -1. When calling EBSD.static_background it does return the information, but from where I'm not sure

My problem is that I want to store the file to the .h5 format without doing any processing and without loosing any information. But when I later import that same .h5 file the information about the static background is gone.

My current workaround is to manually set the static_background by using the depricated set_experiemental_parameters() function, this raises a warning of the function soon beeing removed, but does the trick. This allows me to store the pattern in the .h5 format with the information about the static background.

What I can't figure out is that the property EBSD.static_background returns the correct information when looking on the original .dat file, but it is not stored in the metadata, and I can't seem to figure out where it's stored.

Any help on this is highly appreciated, it's a small problem, but would be really nice to clearify if I'm missing just a simple step!

[hakonanes]

Hi @htrellin,

is this the procedure you're following?

>>> import kikuchipy as kp
>>> print(kp.__version__)
'0.6.1'
>>> s = kp.load("kikuchipy/kikuchipy/data/nordif/Pattern.dat")
>>> print(s.static_background)
[[84 87 90 ... 27 29 30]
 [87 90 93 ... 27 28 30]
 [92 94 97 ... 39 28 29]
 ...
 [80 82 84 ... 36 30 26]
 [79 80 82 ... 28 26 26]
 [76 78 80 ... 26 26 25]]
>>> s.save("test.h5", overwrite=True)
>>> s2 = kp.load("test.h5")
>>> print(s2.static_background)
[[84 87 90 ... 27 29 30]
 [87 90 93 ... 27 28 30]
 [92 94 97 ... 39 28 29]
 ...
 [80 82 84 ... 36 30 26]
 [79 80 82 ... 28 26 26]
 [76 78 80 ... 26 26 25]]

Here I'm importing the NORDIF test dataset part of the kikuchipy source code, saving it as in kikuchipy's HDF5 file format, then reading it back. As you can see, the static background pattern follows along.

If this is not your approach, could you share it?

We used to use the signal metadata layed out by HyperSpy, but replaced the information contained there in the three new EBSD class attributes static_background, detector and xmap. I'm currently working on updating these attributes whenever it is natural for them to update, e.g. updating the detector and background when EBSD.rebin() is called (a method inherited from HyperSpy). This is why we have deprecated some stuff, like our custom metadata and the setting of experimental parameters and phase parameters.

[htrellin]

Hi, I have the same approach, but on a different NORDIF dataset. Maybe there is something wrong with the file, but then again it seems to be able to store the static background information when loading the first time.

import kikuchipy as kp

print(kp.__version__)

s = kp.load("C:\EBSD data\DI data\Al 60x60\Pattern.dat", lazy=True)

print(s.static_background)

s.save("C:\EBSD data\DI data\Al 60x60\Pattern4.h5", overwrite=True)

s2 = kp.load("C:\EBSD data\DI data\Al 60x60\Pattern4.h5", lazy=True)

print(s2.static_background)

which gives the result

0.6.1
[[30 30 30 ... 25 26 26]
 [29 29 29 ... 23 25 25]
 [29 28 28 ... 23 24 24]
 ...
 [29 29 29 ... 23 22 23]
 [29 29 29 ... 22 23 24]
 [30 30 29 ... 24 24 24]]
-1

-1 is the output of the last print. I also tried to set lazy=True, but it gave the same results.

[hakonanes]

Right... For some reason it worked yesterday, while today I can reproduce your result, which is as expected. The background pattern is written to the HDF5 file, but is not passed to the static_background attribute in the h5ebsd reader when creating the EBSD signal as it is in the NORDIF reader. This is the reason for EBSD.static_background == -1 in the final loading.

This is fixed in the development branch (develop), and a new minor release 0.7.0 is only one improvement away from being released (see milestone). I might also change the docs theme before releasing 0.7.0 (to the PyData Sphinx theme), but I hope to release within the weekend. If it takes longer time, I'll make a v0.6.2 patch release instead fixing this issue. Does this work for you?

[htrellin]

Yes, that works It is not time critical for our project so we have time to wait for the 0.7.0 release.

Thank you:)

[hakonanes]

Version 0.7.0 is finally out on PyPI (conda-forge by tomorrow latest), could you check your workflow after updating?

[htrellin]

Updated today, it works fine now!

[hakonanes]

Great! Please let me know next time you encounter a bug (I'm sure you will)!