mx-bluesky's Eiger datatype incompatible with eiger pixel mask

The pixel mask given directly by the eiger will set the dead pixels to a value of -1. When inspecting data using tools like dials.image_viewer, the mask is then automatically applied.
In mx-bluesky, we set the virtual dataset (VDS) datatype using the bit depth of the eiger, which we read from a PV. The VDS datatype is set to either u8, u16 or u32. This means that the -1 masked values get rolled over to the maximum value of the int, and the data viewing tools don't recognise the mask.
This hasn't mattered too much on i03 since the processing pipeline still works as expected. On VMXm, users look at the gridscan output directly and often mistake dead pixels for diffraction spots.

GDA's solution is to change the datatype from an unsigned int to a signed int, and then increase the number of bits so that the max value of a pixel hasn't changed. Eg u16->i32 . This means negative values can be used and the absolute max pixel value is the same. We aren't really sure what the implications of this are given that the raw data doesn't change type.

I will change vmxm's bluesky code to set the VDS datatype as signed integers, and see if this fixes their masking, but we should think of a proper solution/at least understand exactly what's going on.