More feedback and prototyping of new camera API (chapter 3)

[henrypinkard]

This issue is for providing feedback on the new camera API.

With this v2, we're now in a prototyping phase where I will be implementing it on a Basler camera.

Previous discussions of this API can be found in:

Chapter 1

Chapter 2

Version 1 of the proposed API can be found here

[marktsuchida]

@henrypinkard Sorry for the silence - I'll try to comment on this and your other proposals in the next few days.

[henrypinkard]

@marktsuchida No worries, I am mid-prototyping on this one right now and am accumulating questions as a go. I think it would be more efficient to batch it all into one larger discussion later

[henrypinkard]

*Accumulating questions and fixing mistakes

[marktsuchida]

@henrypinkard Regarding the timing events (such as CameraEventFrameEnd),

• These seem like a good opportunity for breaking up the problem into smaller units: presumably these can be added in a second round, completely independent from the main trigger configuration API.
• Can you point me to one or more actual camera API docs that correspond to these events? I'm trying to think about whether they should be callbacks more strongly associated with individual acquisitions rather than being "events".

[henrypinkard]

• Can you point me to one or more actual camera API docs that correspond to these events? I'm trying to think about whether they should be callbacks more strongly associated with individual acquisitions rather than being "events".

https://docs.baslerweb.com/event-notification

and from GenICam

So far as I can tell, events/callbacks like ExposureEnd/Line0RisingEdge/etc (or some equivalent) are needed to implement triggers and acquisitions correctly in the GenICam way of doing things.

• These seem like a good opportunity for breaking up the problem into smaller units: presumably these can be added in a second round, completely independent from the main trigger configuration API

Based on everything I've seen thus far, I think breaking this into multiple units would create substantially more work, because I would have to figure out how to interleave our existing camera API with GenICam's concepts, which seems to me a lot more challenging and with potential for edge cases and errors than to simply adopt the subset of its specifications that make sense for micro-manager all at once.

[marktsuchida]

So far as I can tell, events/callbacks like ExposureEnd/Line0RisingEdge/etc (or some equivalent) are needed to implement triggers and acquisitions correctly in the GenICam way of doing things.

Now that I think about it, this seems correct -- at least if using software triggers.

• These seem like a good opportunity for breaking up the problem into smaller units: presumably these can be added in a second round, completely independent from the main trigger configuration API

Based on everything I've seen thus far, I think breaking this into multiple units would create substantially more work, because I would have to figure out how to interleave our existing camera API with GenICam's concepts, which seems to me a lot more challenging and with potential for edge cases and errors than to simply adopt the subset of its specifications that make sense for micro-manager all at once.

Fair enough.

[marktsuchida]

Do non-GenICam-based camera APIs also have a similar event mechanism?

[henrypinkard]

Yes, looking through several of the scientific cameras in 3rdparty, it seems this is a common mechanism

[marktsuchida]

Which ones should I look at?