application - NXtomo: add 'half_acquisition' field.

[payno]

This PR propose to add the "half_acquisition" field to the NXtomo application.

• Half-acquisition scanning mode allows the field of view to be increased. Processing needs to be aware of it.
• The name half-acquisition is commonly accepted amount the community.

Note:
In a perfect world, the NXtomo could store pre-processed sinograms / projections directly, and this field would not be needed.
In reality, however, NXtomo applications are generated from detector raw data, with the processing embedded in the processing pipeline so that computation can happen on the fly. This makes the process less memory-intensive and this field required.

[phyy-nx]

@payno thanks for the contribution. At the telco today this was generally received favorably. Some comments from discussion:

Note that there could be an inconsistency between this field and the rotation axis position in a badly formatted file. Is this important enough to include an extra sentence noting that if half_acquisition is True, there's an expectation of what the rotation axis should be? The idea is helping future developers build their files.

Also, are there other collection modes besides half and full collection? Should this be an enumeration of acquisition modes (half, full) instead of a boolean?

None of these are hard stoppers though. If you can respond before the 26th of September, we can include this in our discussion/voting in NIAC 2026.

[payno]

Thank you for the review.

1. Regarding the inconsistency between this field and the rotation axis position in a badly formatted file.

Fair point, the thing is that the processing associated with the half_acquisition field should work no matter the value of the rotation axis position... but if it is not on a side, then we lose the interest of such an acquisition...

I updated the description of the field a bit to try to clarify this. I hope it is better and still concise enough — otherwise, let me know.

2. Regarding other collection modes

This is a very good question and we asked ourselves the same. We debated a bit with tomography colleagues.

At the moment at my institute (ESRF) there is a beamline that does so called 'tetra-acquisition'. Which is stitching projections horizontally as a preprocessing of the reconstruction. But indeed this operation and related treatment come in addition to the half_acquisition (even if in the absolute half_acquisition is still optional).

This case is not directly covered by NXtomo, at the moment two NXtomos are generated and 'treated' together. Making several assumptions. This is a 'niche' technique but when (and if) we generalize this method IMO we would either:

• create an NXtomo with projections stitched and the half_acquisition field set to True. Which would require some pre-processing to generate it. (And today we try to have 'raw data' on the NXtomo for convenience question - like avoiding duplication of data)
• propose another Nexus application because this use case is different. probably called NXtomoTetra and that has two 'NXtomo' entries likes - or more for octa... for example today the x_rotation_axis_pixel_position is a scalar position in pixels that will be different for the inner and the outer scans. But the NXtomo on themselves are kind of loosing their purpose (being able to contain all the necessary information to reconstruct the volume)

But within the context of NXtomo (which is the current scope) IMO having half_acquisition as a boolean it what makes the most sense, it is simple and practical. And so this is what will be used.
Having an Enum seems nice on paper but in fact I don't think we could use it right away with NXtomo which has a more limited scope - and limitations (and it is a good thing IMO).