Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleaning up the Camera API #16

Open
nanthony21 opened this issue Mar 22, 2021 · 4 comments
Open

Cleaning up the Camera API #16

nanthony21 opened this issue Mar 22, 2021 · 4 comments
Labels
MMDevice Related to the redesign of MMDevice API

Comments

@nanthony21
Copy link
Member

nanthony21 commented Mar 22, 2021

@henrypinkard:
There's a few overlapping things in the core that would need to get sorted out here. Multi-channel cameras, multi-component cameras (rgb falls here i think), and multi-camera device adapter. The current calls for these are pretty confusing

@nicost:
Agreed! But it does make sense that the same camera can operate in monochrome and RGB modes.

@henrypinkard henrypinkard changed the title GDOCS: Cleaning up the Camera API Cleaning up the Camera API Mar 23, 2021
@henrypinkard henrypinkard added the MMDevice Related to the redesign of MMDevice API label Mar 23, 2021
@henrypinkard
Copy link
Member

Here is an old forum post that discusses the challenges of a scanning confocal setup: http://micro-manager.3463995.n2.nabble.com/scanning-confocal-microscopes-td7578637.html

@nanthony21
Copy link
Member Author

I recently noticed that in order for a camera device adapter to work in MMStudio in addition to implementing the official API it must have a "Binning" property which can be used to determine what the available binning options are. There may be other semi-required properties that can help inform how the API's should be updated. Ideally no property should be required for operation with the GUI.

@nanthony21
Copy link
Member Author

The getExposure method is declared as const which makes it so that no instance variables can be modified from within this method. Many device adapters work around this by implementing an exposure property and then having the property handler do the necessary changes to the instance variables.

We should review declarations of const methods to make sure they make sense.

@jondaniels
Copy link

As mentioned in the overview document a major weakness is the lack of API for controlling triggering.

Consider also API for changing readout speed and/or readout mode (e.g. lightsheet mode) and/or trigger mode (e.g. single trigger many exposures, "overlap" or "synchronous" mode, "bulb" trigger, etc.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
MMDevice Related to the redesign of MMDevice API
Projects
None yet
Development

No branches or pull requests

3 participants