picamera issues.

[iandobbie]

Unclear if these issues are cockpit or microscope. I now have a full test system with ludl stage, red pitaya executor and picamera.

Two obvious issues:

1) Transforms aren't honored so no matter what the cockpit configured transform, the image arrives with the same orientation.

2) The camera config isn't properly done on init. To get the correct sensitivity currently you need to connect from cockpit, and run an experiment, then the sensitivity is set.

I suspect that issue 1 is microscope and Issue 2 is somewhere in the interface between cockpit and microscope.

[iandobbie]

Ok Issue 1 is my error, I was setting the transform on the objective and not the camera. Setting ti on the camera works as expected.

Additionally mosaic dies are a while probably due to the slow image return. I will chase up what delay is catered for and see if increasing this solves the issue.

[iandobbie]

Mosaic has an exposure time + 1s timeout. We should include the camera readout time, as this is set to about .7 s on the picamera as the response is so slow. I will add a call to the readout time to get a better estimate of the likely image delay.

[iandobbie]

Issue 2 is that something in the camera connection process resets the exposure time. So if the system is imaging at 100 ms/frame and you show down and then restart cockpit the exposure time gets reset to something tiny. Disabling and reenabling the light source sets it to the correct 100 ms. So something in the connection and init process is not reading the light source exposure times to properly set the exposure times.

[iandobbie]

Mosaic has an exposure time + 1s timeout. We should include the camera readout time, as this is set to about .7 s on the picamera as the response is so slow. I will add a call to the readout time to get a better estimate of the likely image delay.

Doing this allowed me to collect several 100 images in a single mosaic on the pi camera based system so I think this is a proper fix for this. I will push the code and reference this issue.

[iandobbie]

As to the original camera config issue (point 2 above). This occurs if the remote microscope is already active when you start cockpit. The system initializes with a 40 ms exposure time, despite the fact there is an active light with a 100 ms exposure time. There are obviously some other setting that aren't properly initialized as well as the sensitivity of the system is much lower in this init state with a 40 ms exposure than when reset by toggling off and on a light source with a light and a 10 ms exposure.

[iandobbie]

The exposure time issue is that there is no defined state for the system to be in after an enable call. I suggest that we set microscopeCamera device to either issue a LIGHT_EXPOSURE_UPDATE or directly call the Imager._on_light_update to reset the camera exposure time at the end of the enable function.

The only issue here is that the event, and the function both expect light handler to be in the call, but neither actually use it.

[iandobbie]

My suggestion is we add the following code to the end of the enable_camera function

        # a hack as the event expects a light handler, but doesnt use it so
        # call with the camera handler. 
        events.publish(events.LIGHT_EXPOSURE_UPDATE,self.handler)

[iandobbie]

This will prod the interfaces.imager to go through active lights to find the longest exposure and set the active cameras to that exposure time. This should make snaps on enable work, but needs testing as their does appear to be some other weirdness in the picamera as it was so insensitive even though it had a 40 ms exposure.

[iandobbie]

There is something very weird here. On startup my test system has a simulated 488 light enabled with an exposure time of 100 ms. The pi camera starts disabled but with an exposure time of 100 ms (almost as the times are not ints). When enabling the camera I get an exposure time of 6ms, I don't know where from. If I disable, then reenable the light the camera picks up the correct exposure time of 100 ms. Very weird. I guess I need to trace what the LIGHT_EXPOSURE_UPDATE does at startup with the simulated light.