Allow signed types

[DominicOram]

Data coming off of the Eiger should be interpreted as signed (where -1 is a masked pixel). When trying to set odin to use a signed datatype I get the following error:

/odin/odin-data/cpp/frameProcessor/src/Acquisition.cpp:468:
 15:26:06,104 FP.Acquisition ERROR - Invalid frame: Frame has data type 3, expected 0 for dataset data (0: UNKNOWN, 1: UINT8, 2: UINT16, 3: UINT32, 4: UINT64, 5: FLOAT)

[Ohisemega]

cc: @JamesOHeaDLS

[Ohisemega]

Data coming off of the Eiger should be interpreted as signed (where -1 is a masked pixel). When trying to set Odin to use a signed datatype, I get the following error:

/odin/odin-data/cpp/frameProcessor/src/Acquisition.cpp:468:
 15:26:06,104 FP.Acquisition ERROR - Invalid frame: Frame has data type 3, expected 0 for dataset data (0: UNKNOWN, 1: UINT8, 2: UINT16, 3: UINT32, 4: UINT64, 5: FLOAT)

Hi @DominicOram, you mentioned this issue at the last Odin-ops meeting. In 2's complement, -1 is the same as MAX_UINT (or the max unsigned of whatever signed type -1 is in). Can this be used in masking for your use case?

[DominicOram]

you mentioned this issue at the last Odin-ops meeting.

Erm... I don't think I have ever been to such a meeting but I have discussed this a few times with @shihab-dls.

The problem is in downstream processing, where many tools (sometimes third-party ones that we do not have access to modify) expect the hdf file to be a signed number with -1 in the masks so we will probably, at some point in the stack, need to change the hdf file metadata to be signed to allow reading by all these tools.

However, there is potentially some issue with the Eiger itself not producing signed data (see https://diamondlightsource.slack.com/archives/C08FER0BZN0/p1783586706256689?thread_ts=1783531870.701089&cid=C08FER0BZN0). In which case anything we do in odin won't help.

The potential workaround is that we change the nexus file, that vds links to the odin produced hdf file, to reinterpret the link as signed. We have done this before but it seems messy and, if possible, it would be better for the hdf file to be as expected for downstream processing.

[Ohisemega]

you mentioned this issue at the last Odin-ops meeting.

Erm... I don't think I have ever been to such a meeting but I have discussed this a few times with @shihab-dls.

The problem is in downstream processing, where many tools (sometimes third-party ones that we do not have access to modify) expect the hdf file to be a signed number with -1 in the masks so we will probably, at some point in the stack, need to change the hdf file metadata to be signed to allow reading by all these tools.

However, there is potentially some issue with the Eiger itself not producing signed data (see https://diamondlightsource.slack.com/archives/C08FER0BZN0/p1783586706256689?thread_ts=1783531870.701089&cid=C08FER0BZN0). In which case anything we do in odin won't help.

The potential workaround is that we change the nexus file, that vds links to the odin produced hdf file, to reinterpret the link as signed. We have done this before but it seems messy and, if possible, it would be better for the hdf file to be as expected for downstream processing.

Oh, it seems I mistook you for someone else; my apologies. The discussion continues on Slack, so I'll move back there.