1

I have a Liquid Crystal on Silicon Spatial Light Modulator (LCOS SLM) by Hamamatsu Photonics, which is basically a 1280 x 1024 pixel screen with a DVI connection to my graphics card. It can display 8bit grayscale images, i.e. with pixel values from 0 to 255.

I am using the WINAPI function SetDIBitsToDevice() to draw a pre-calculated 1280 x 1024 8bit device-independent bitmap (DIB) on the SLM (with the correct header and everything). My implementation in python using ctypes goes like this:

def draw(data: numpy.array):  # data has dtype=numpy.uint8 and lies in memory like a standard C-array in 8bit format, row-major order
    data_p = data.ctypes.data_as(ctypes.c_void_p)  # pointer to data of C-type void*
    SetDIBitsToDevice(SLM_HDC,          # display context of screen
                      0, 0, 1280, 1024, # fill whole screen
                      0, 0, 0, 1024,    # draw whole data-array
                      data_p, pbmi, 0)  # pbmi is a ctypes.POINTER(BITMAPINFO), i.e. of C-type BITMAPINFO*

More implementation details can be found in my answer to this question, if you are interested. For an example you can run on any computer with 2 screens, download from my dropbox, adjust screen resolution in display test file and run it. The point is that it works, both on regular LCD monitors in the office and on the SLM.

But: On the SLM, I have measured a delay of > 70 msec before the screen even starts updating. The expected maximum delay due to 60Hz DVI frequency and 120Hz SLM frequency is 1/(60Hz) + 1/(120Hz) = 25 msec. All I am doing in python are the two lines of code in the above function; everything else is precalculated and static. Can you see any programming reason that would cause more than 40 msec delay? I am hoping that I am making some stupid mistake and someone can point it out.

P.S. I have had difficulty reaching Hamamatsu's tech support, so I haven't been able to ask a specialist.

dimitsev
  • 127
  • 1
  • 10
  • If performance is a design goal, why are you writing this in Python? Write a C version and you have an implementation that suits itself far better for performance investigations. – IInspectable Apr 09 '21 at 13:49
  • Also check [\[SO\]: C function called from Python via ctypes returns incorrect value (@CristiFati's answer)](https://stackoverflow.com/questions/58610333/c-function-called-from-python-via-ctypes-returns-incorrect-value/58611011#58611011) for other considerations (not directly related to your problem). As for the slowness, you'll have to debug the problem yourself (simplest: add *print*s) and determine the bottleneck. – CristiFati Apr 09 '21 at 16:58
  • In [my answer to this question](https://stackoverflow.com/questions/39669915/grayscale-hbitmap-with-python-ctypes/66946126), I set SetDIBitsToDevice.argtypes according to the WINAPI documentation. As for ctypes performance, can python function calls really cause > 40 msec delays? – dimitsev Apr 10 '21 at 14:08
  • This probably will not solve your delay problem but using BGRX or BGR instead of paletted 8 bits should improve throughput. – Daniel Sęk Apr 11 '21 at 07:27
  • I couldn't understand (even after combining the 2 questions) what the problem is. Does the 70ms delay occurs every time or only the 1st? I don't see the full code, only pieces, so it's hard to tell. It is possible that *Python* would introduce that delay, but I don't think it does. Try the same thing from *C* and compare results. [\[SO\]: How to create a Minimal, Reproducible Example (reprex (mcve))](https://stackoverflow.com/help/minimal-reproducible-example). – CristiFati Apr 12 '21 at 04:44
  • Thanks guys, a researcher that has worked with SLMs before told me they used imshow() from OpenCV. P.S. The code in my dropbox in the question draws on your pc's secondary screen, see the quesiton above. – dimitsev Apr 12 '21 at 08:38

0 Answers0