Open Gigarrum opened 1 year ago
Discussion from Code Camp:
Thanks @PeterC-DLS for the clarifications.
Philosophy from the Code camp: the ideas in 3. above would be a breaking change for NXtomophase, so regardless of whether they are acceptable, the software that implements reading and writing phase-contrast imaging data would need to know about it. A more gentle change would be additive fields that would for example use only one NXdetector but with three fields representing scans with that detector. Then the documentation could be updated to indicate which fields are now more preferred.
All this said! How can we improve the documentation of NXtomo and NXtomophase so it's more clear for new users of NeXus?
I will point out some things that I consider that are problems on NXtomo and NXtomophase application definitions so we can discuss and enhance them:
NXtomo and NXtomophase documentation uses different terms for the same thing: While on NXtomo the term flat is used on NXtomophase the term used is bright_field. Considering that one of NeXus objectives is to create a data dictionary for X-ray/Neutron/Muon experimental data, I consider standardizing how flat/bright field is called between application definitions from similar tecniques crucial. If flat and bright are not the same information, documenting what NXtomophase means by bright seems important.
NXtomo and NXtomophase structures detected data in different ways: While on NXtomo flat,dark and projections are stored in the same array in the data field from a NXdetector group, on NXtomophase it is split and stored in the data field from 3 different NXdetector groups. Checking the NXdetector, the NXtomo definitions seems to follow more precisely how NXdetector class defines to save the data, however If both representations are possible and acceptable, should we add new fields to NXdetector group class in order to document this other type of organization for detected data?
NXtomophase defines 3 NXdetector groups inside NXintrument: The problem is that all of them probably refers to the same device making the existance of 3 NXdetectors group incoherent in my opinion. According to NeXus NXDetector base class documentation, that class defines "A detector, detector bank, or multidetector", that said, having 3 NXdetectors named according to the respective data inside it and refering to data acquired from the same device seems a structural problem in the NXtomophase definition. If data requires to be split and stored separately, in my opinion, the correct way would be something like this:
NXinstrument detector:NXdetector bright_field NX_INT (Rank: 3, Dimensions: [nBrightFrames, xSize, ySize]) dark_field NX_INT (Rank: 3, Dimensions: [nDarkFrames, xSize, ySize]) data NX_INT (Rank: 4, Dimensions: [nSampleFrames, nPhase, xSize, ySize])