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?

[henrypinkard]

I didn't want to post info about 3rd party SDKs here and now I forget which I looked at :), but it should be pretty easy to look through a few SDKs and find them

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".

What do you think is the advantage of making them callbacks rather than events? It seems like the functionality is fairly similar, but the latter has terminology more consistent with GenICam, which is the design principle we've embraced for most of this API

[marktsuchida]

That comment was just due to me not having looked at any of the event APIs. I think events are fine if that is what all/most of the SDKs use.

The nice thing about acquisition-specific callbacks is that an app wouldn't have to explicitly de-register its event handler -- the end of the acquisition would be the end of the calls received by that handler. It prevents a category of bugs. But the MMDevice API (and probably even the MMCore API in this case) should probably follow what the device SDKs have; we definitely don't want each device adapter to replicate logic to convert semantics.