Closed hinderling closed 1 year ago
@hinderling Many thanks for the patch and for the meticulous description, too! The remaining issues (regarding bit depth differences etc.) need to be solved first in MMDevice and MMCore (and each device); I've added a note to micro-manager/mmCoreAndDevices#34 but feel free to add any thoughts there.
This code should fix issues with
setSLMImage()
. Until now, images had to be converted tochar *
which lead to issues with values >'\x7f'
(127) because they don't match to valid ASCII characters (see discussion). For thegenericSLMDevice
, this meant that gray is the brightest color that could be achieved. Allowing fornp.arrays
removes one data conversion step for the user, and matches the behaviour of pycro-manager.Accepted inputs with this PR:
uint8
uint8
, color order [RGB]char *
with either w*h bytes or w*h*4 bytes (for imgRGB32), so that existing scripts are not broken.Input formats I chose not to accept:
np.arrays
, as there are currently no DMDs supporting it, and it leads to unexpected behaviour withgenericSLMDevice
np.arrays
, as different DMDs use different values to designate an on-pixel (1 or 255) and there is currently no way to extract it.Thoughts on further improvement:
np.arrays
that behave the same on different hardware setups. This is however complicated by the fact that some DMDs support multiple bit depths (e.g. genericSLMDevice reports 4byte but also accepts 8bit).Caught errors:
RuntimeError: Image dimensions are wrong for this SLM. Expected (1140, 912), but received (1141, 912)
RuntimeError: Pixel array type is wrong. Expected uint8.
RuntimeError: Number of bytes per pixel in pixels is greater than expected. Received: 3, Expected: 1
RuntimeError: Pixels must be a 2D numpy array [h,w] of uint8s , or a 3D numpy array [h,w,c] of uint8s with 3 color channels [R,G,B]
I chose not to highlight that also
char *
is supported because of the above mentioned issues.Tested on Windows with genericSLMDevice, Andor Mosaic 3, Mightex Polygon1000.