Closed dstoychev closed 3 years ago
The problem is two-fold. First, the buffers are hardcoded to "uint16" data type. Second, the circular buffer callback casts to an unsigned 16-bit integer. I address both of these in dstoychev/microscope@334d2f2c9902f7e7ee46432c2cff8085d3f54274.
This is a known issue with cockpit. Basically all data is assumed to be uint16, so fixing it in microscope might not actually solve the problem.
I address both of these in dstoychev/microscope@334d2f2.
My one concern with this solution is are there any other possible bit depths, or data types? Any pvcam cameras that return 32 bit floats? We should solve the problem generally if possible.
I did some testing and didn't notice any problems in cockpit. Haven't tried experiments yet though.
Regarding different depths, I don't think they are necessary at this stage. As far as I can tell, all cameras sold by Photometrics at the moment use 16-bit data transfers, with the only exception being the Kinetix with its fast 8-bit mode. Here is what the documentation says:
Most Photometrics cameras transfer pixels in 16-bit words (uns16 type). However, some cameras are capable of transferring 8-bit data (uns8 type).
I don't quite understand how the colour cameras work, but I think they transfer in 16-bit chunks too.
Ok sounds good. I guess we would need to update if colour cameras transfer as 24bit (ie 3x8bit) or maybe 3x12 or 14 bit. We should probably comment the code to say this so it is easier to spot in future.
There is an open cockpit issue about 16 bit data streams. Maybe it got fixed! We should probably cords reference the issues in case we find a problem in future in the cockpit to microscope interface.
Ian
Sent from my iPhone
On 24 Mar 2021, at 17:05, dstoychev @.***> wrote:
I did some testing and didn't notice any problems in cockpit. Haven't tried experiments yet though.
Regarding different depths, I don't think they are necessary at this stage. As far as I can tell, all cameras sold by Photometrics at the moment use 16-bit data transfers, with the only exception being the Kinetix with its fast 8-bit mode. Here is what the documentation says:
Most Photometrics cameras transfer pixels in 16-bit words (uns16 type). However, some cameras are capable of transferring 8-bit data (uns8 type).
I don't quite understand how the colour cameras work, but I think they transfer in 16-bit chunks too.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/python-microscope/microscope/issues/194#issuecomment-806000176, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABJTBBNQPSXOTY5W3VGIJX3TFILURANCNFSM4YOUNXHA.
Added a comment to say colour cameras might need more options then pulled fix into master
The 8-bit mode of the Kinetix camera is not working properly. The data seems to be garbled and to me it appears as a tiled image of smaller size. It must be something to do with the way data is interpreted. My guess is that the API has been configured (via
ctypes
) to expect 16-bit data.