Add Hamamatsu camera service

[ivalaginja]

Fixes #162.

Contains a code sneak in which I delete a property from the AV cam service that is not set up or used.

Todo

• Check library loading
• Test on hardware
• Check dimensions: sensor_width vs. sensor_heigth, width vs. height
• Address all todos in code

[ivalaginja]

For once a camera service that was simple and went smoothly. Tested on hardware on a Hamamatsu ORCA-Quest C15550-20UP as the science_camera with a 400 x 400 px ROI, and everything works as expected:

[ivalaginja]

@ehpor note how this is the first camera in catkit2 that uses seconds as exposure time units, instead of microseconds as for the other cameras. I have formulated an issue around this here: #181

Edit: the service has been changed since to use microseconds as exposure time as well.

[ivalaginja]

While testing in the lab, we learned that the first frame of each acquisition contains very obvious systematic errors, so it is unusable. It is probably rare that anyone would use the very first frame from a data stream, but it seemed more correct to me to never submit that faulty frame to the data stream in the first place.

I am not actually sure how to test this code block though... if you have any pointers @ehpor, please let me know.

@erinpougheon could I ask you to post a screenshot of the faulty frame here in the PR, for future reference?

[ehpor]

Question: does this faulty frame reappear when you change ROI, exposure time, gain or other settings?

Yes, I'd never submit that frame to the data stream. I'm not sure what you mean by "test". Since this is hardware-only behaviour, you can't do unit tests unless you go for hardware-in-the-loop, which is a hassle to automate. If you mean, just testing that this behaves as expected, I'd put an info log message instead of just breaking.

[ivalaginja]

Very good questions. I'll pass them on to @erinpougheon to test in the lab when she's back on Wednesday. FYI @johanmazoyer

I meant indeed to just test whether it behaves as expected. I'll do that.

[erinpougheon]

Here is a screenshot of the faulty frame.

[ivalaginja]

Question: does this faulty frame reappear when you change ROI, exposure time, gain or other settings?

So it turns out that we haven't paid much attention to the proper way of property setting with this camera - or the Allied Vision cameras. Some of the properties need the camera acquisition to be temporarily stopped, so I opened an issue for this for the AV service here: #183

For the Hamamatsu camera, only the exposure time can be changed while the camera is acquiring, the other properties need a temporary stop of the acquisition as well. Since that retriggers the acquisition loop, yes the faulty frame would appear again, but it would also be automatically discarded again in the current implementation. As for resetting the exposure time, I don't actually know how to catch the exact first frame after resetting it to figure out whether it's fine or not...

We only have our loaner camera for one more day and we won't be able to implement and test this before we have to send it back. We won't get our own camera for a while. My idea would be to open an issue an put a rework of the properties that need an acquisition halt into it (#194), akin to the issue for the Allied Vision cameras. And to open a separate issue (#195) to figure out how to test the first frame upon an exposure time change to decide whether it's fine or whether we need to throw it away too.

What do you say?

[ivalaginja]

The tests on GitHub are failing for MacOS for some reason, but they are successful when I run them locally:

[ehpor]

What do you say?

Yes, I'm fine with merging this early, with potentially incorrect first-frame handling and some other issues to be fixed in a later PR.

[ehpor]

Let me know when this is ready for review, since you're still changing things.

[ivalaginja]

@ehpor I think this is actually ready for review now, unless I forgot anything that we talked about.

[ehpor]

LGTM.