Nxmx bit depth image

[graeme-winter]

Requires upstream fix in NXmx

dials/nxmx#15

To fix dials/dials#2401

[graeme-winter]

The tests will fail on this one until the upstream fix to NXmx is in place

[codecov]

Codecov Report

Merging #631 (d16ca6e) into main (af7cf7d) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

❗ Current head d16ca6e differs from pull request most recent head df0b0b2. Consider uploading reports for the commit df0b0b2 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #631      +/-   ##
==========================================
- Coverage   39.43%   39.42%   -0.01%     
==========================================
  Files         178      178              
  Lines       15460    15461       +1     
  Branches     2600     2600              
==========================================
  Hits         6096     6096              
- Misses       8804     8805       +1     
  Partials      560      560              

[rjgildea]

Given bit_depth_image isn't an official NXmx item (unless I'm mistaken), perhaps an alternative would be to do something similar to the workaround performed in FormatNXmxDLS?

dxtbx/src/dxtbx/format/FormatNXmxDLS.py

Line 78 in b864c23

self._bit_depth_readout = get_bit_depth_from_meta(self._meta)

[graeme-winter]

Given bit_depth_image isn't an official NXmx item (unless I'm mistaken), perhaps an alternative would be to do something similar to the workaround performed in FormatNXmxDLS?

dxtbx/src/dxtbx/format/FormatNXmxDLS.py

Line 78 in b864c23

self._bit_depth_readout = get_bit_depth_from_meta(self._meta)

DECTRIS think it is

https://www.dectris.com/support/downloads/header-docs/nexus/

And - on a practical note - I did not have a handy pointer to the actual nexus [HDF5] file structure, only to the NXmx object which obviously does not encode what it does not believe in

[rjgildea]

Given bit_depth_image isn't an official NXmx item (unless I'm mistaken), perhaps an alternative would be to do something similar to the workaround performed in FormatNXmxDLS?

dxtbx/src/dxtbx/format/FormatNXmxDLS.py

Line 78 in b864c23

self._bit_depth_readout = get_bit_depth_from_meta(self._meta)

DECTRIS think it is

https://www.dectris.com/support/downloads/header-docs/nexus/

And - on a practical note - I did not have a handy pointer to the actual nexus [HDF5] file structure, only to the NXmx object which obviously does not encode what it does not believe in

Official NXmx specification:
https://manual.nexusformat.org/classes/applications/NXmx.html

[graeme-winter]

I am not debating the standard, I am debating the issue we have on the ground now with real user data with instruments in the field which are not about to be fixed in a hurry.

We have a choice:

• deal with the data as is
• refuse to process non-standard data

I am not comfortable with the latter TBH even if that is what the standard says

I will figure a non-standard-questioning workaround.