Libertem: NeXus application definition for pixelated STEM

[uellue]

We are creating a NeXus Application Definition (http://download.nexusformat.org/doc/html/classes/applications/index.html) for pixelated STEM. For that we need to figure out what information we want to store and how to map that onto NeXus. In https://github.com/LiberTEM/LiberTEM/tree/master/fileformat you find drafts that we should refine bit by bit. We can discuss the details in this Issue.

[mkoennecke]

I have a number of comments:

For the illumination I would reuse NXsource. The documentation of the group and of some fields needs to be updated to reflect the use as a electron source. May be we need to add some fields.

As you state you have the ability to move the beam and not only the sample. I suggest to add the necessary positional fields into NXbeam for changing the beam position.

I also would like you to look at the NeXus scan rules at : http://download.nexusformat.org/doc/html/rules.html#scans for more information. From what you describe I think they can be applied.

Regarding NXdetector, I think you are mostly covered. There are fields which can be used to store the information you require. But what is the nature of the gain curve? I understand that it somehow relates the raw detector counts to the real electron counts. In what way is it different to what NeXus already has as efficiency in NXdetector?

I confirm that for the projection, NXtransformation is the right thing to look at. It is just not obvious how to apply it. What are you going to calculate with it?

I do not understand drift corrections but it seems as if this is indeed an additional base class.

The Virtual detectors: What is this? In the description the word reduced is used. This suggests to me that this is some kind of processed data which ought to go into a NXprocess entry.

[uellue]

What is actually the difference between NXsource and NXbeam?

[mkoennecke]

Am 16.03.2018 um 16:31 schrieb Dieter Weber <[email protected][e-mail]>:

What is actually the difference between NXsource and NXbeam?

NXsource is the description of the radiation source. NXbeam is more a freely usable group used to describe the
characteristics of the beam at a a certain point in the instrument. The radiation from the source may have been monochromated,
polarized, collimated or what else.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/LiberTEM/LiberTEM/issues/15#issuecomment-373750187, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEy_2rP2G8Au-F47Fe-C9j-3K8xSd6y9ks5te9rIgaJpZM4SIm_m.

[woozey]

I finally found some time to put together a feedback with regards to fileformat.basic pixelated STEM:

• In general an easier approach for me would be first defining full format with all possible metadata, and than hoping it down to minimum required for pix-STEM, therefore the following comments are regardless if it is minimum or not.
• Having illumination separated from source:
  Source: Beam energy, energy spread, source type, extractor voltage, emission current, coherence (?)
  Illumination, in addition to what is listed: Monochromation, gun lens, probe size
• With regards to scanning, does one need some info about HW here? Otherwise it should go somewhere else. For instance it could be type of deflectors, models/brand of generator, position in column, descan, …
  
  
  
  • With regards to detector, I’d add also standard annular detectors and EDS and EELS as all of that can be collected together with pix-STEM
  
  
• With regards to detector.physical size (x, y), I think physical pixel size is more relevant here...
• With regards to detector.gain curve, in CCD camera notation, you may be referring to gain reference image which doesn't relate the read out to calibrated units though. Otherwise it is just a factor which you would call it calibration
• With regard to detector, I think the spatial calibration of the detector should also go here rather than in the projection section
• With regard to Virtual detectors, are the datasets may contain the virtual detector (VD) images? Otherwise the information about the VDs might be irrelevant.
• With regards to projection, one may also add: diffraction (or image) rotation, (?) image/diffraction mode (although it is difficult to imagine having projection system in imaging mode in the case of STEM)
• And last general one, what is totally missing is the information about other HW in particular optics, see issue for example https://github.com/hyperspy/hyperspy/issues/1713

Hope it helps.

[woozey]

I think that also Andy Stewart @ediff should be a part of this discussion.

[magnunor]

Some points after reading through discussion and files in https://github.com/LiberTEM/LiberTEM/tree/master/fileformat:

• How many of the various metadata fields will be required vs. optional? For example, in most of my datasets I have really no idea what the beam current really is, since I mostly work with pretty robust samples
• What is Spot size defined as? I think Jeol and FEI instruments have the numbering the opposite ways?
• It would be very useful to include detector settings. For example, for the Medipix3 detector knowing the threshold values could be really useful
• From a more practical standpoint it would be _very_ useful for the pixelated STEM definition to have some kind of diffraction and image sums, as this would greatly improve easy exploration of these datasets. The Medipix data converted to EMD-style HDF5 using https://fpdpy.gitlab.io/fpd/convert_merlin_binary.html has this in the form of fpd_sum_im and fpd_sum_dif, which means I can easily explore these datasets lazily in HyperSpy by using s.plot(navigator=s_fpd_sum_im)

[uellue]

@magnunor +1 regarding the preview images and other points! Great preparation for the Google hangout next week. :-)