-
Notifications
You must be signed in to change notification settings - Fork 26
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
UI to set ROI #837
Comments
This feature used to be there in cockpit through a dedicated menu on the camera in the main pannel. It would be nice to be able to trigger some other action upon changing the roi. I'm thinking about triggering a change in a rectangular window adapting the size of the excitation to the ROI size. |
I would think that this should go through the events system. The camera view definitely triggers some stuff if the camera image size changes but this only happens once an image is returned. It would be better to have whatever is adjusting the RIO fire an ROI event and get any interested devices to listen to such an event. |
This (default initial ROI in the depot file) is now implemented on my branch |
Here is the branch for the interactive ROI changes that Matthew did: dstoychev/cockpit/interactive_roi |
I've quickly looked at it and only have one question. The code seems to assume that ROI coordinates are always relative to the sensor original shape. So a ROI with width of 10 will return an image of width 5px if binning is 2x2. But did you actually test that? (if it doesn't work there may also be an issue in Microscope). Also, if the ROI has width 1 but binning is 2x2, what should happen (may be a discussion for Microscope)? |
I would need to check the code but I think a camera with 10x10 sensor and binned 2x2 returns an image that is 5x5 and the camera view adjusts to that. This solves the 1 pixel width on a 2x2 binned image, but we then need to define how ROI are interpreted in microscope, or expand the ROI from image pixels to camera pixels before we pass it over the wire. |
Just to note that I think that is the expected behavior from the user perspective. A user will most of the time associate the ROI with FOV and 'zoom' rather than the number of pixels of the final image. There are less thinking steps for the average user that is not using binning. |
Not at the time, but I tested it now and it works in the following (expected) way:
|
I'm not sure about a thing. You set binning to 2x2, then acquire an image. Then you draw a 5x5 ROI on the camera view. Does it send a 5x5px or 10x10px ROI to Microscope? I think cockpit should be sending a 10x10px ROI (but I may be wrong on what actually happens, it's not documented anywhere). |
There is an obvious clash between the current settings and the settings when the images was taken here. If you set the camera to bin 2x2, acquire and image, set it back to 1x1 then set a ROI you will get the wrong result but I think this is such a side issue that we should ignore it. To be honest Mike removed my scale bar in the camera views over exactly the same issue but I think it is such a corner case that we can document it and ignore it. |
(cherry picked from commit 1285b9f)
(cherry picked from commit 1285b9f)
I have played a little with this and I can see some improvements. I have started to make them in my copy of this branch as well as rebasing it on the latest master.
|
Just to make it clear I have fixed point 1 above in my branch. |
I have created a new event UPDATE_ROI. The code I implemented fired a MOSAIC_UPDATE event which deals with the mosaic image outline. I have also added flag to keep displaying the selected ROI until a new image is collected or if it cleared. Finally the code also now uses the real coords to draw the ROI, with shift used to force a square roi. For Julio's question above about changing illumination area on change of ROI, we should subscribe to the UPDATE_ROI event which is passed the camera name. We should add a trigger to ask if other cameras should have the same ROI set. My current issue with this is where do we do this? We could have every camera handler subscribe to the UPDATE_ROI and check the name, if this cam is active and it was not this camera then offer to set the ROI, the problem with this if you have 4 cameras active and you set an ROI you get 3 dialogs. |
Interactove ROI from Issue microscope-cockpit#837 added dialog to apply ROI to other active cameras ROI selection now not square, but can be forced with shift-drag Added UPDATE_ROI event and changed imageviewer and mosaics to use it keep ROI bounding box in camera view until a new image is snapped force a moasic update after an roi change so moasics have the correct image size on them Allow setting roi interactively
Added the dialog to apply it to other active cameras. Closing issue as complete. |
Interactove ROI from Issue microscope-cockpit#837 added dialog to apply ROI to other active cameras ROI selection now not square, but can be forced with shift-drag Added UPDATE_ROI event and changed imageviewer and mosaics to use it keep ROI bounding box in camera view until a new image is snapped force a moasic update after an roi change so moasics have the correct image size on them Allow setting roi interactively
Currently, there only way to set a ROI on a camera is through the settings button (and manually type in the ROI). This goes through the
"roi"
setting instead of theset_roi
andget_roi
methods but in Python-Microscope we would like to remove that"roi"
setting (see python-microscope/microscope#260).add a UI to draw a ROI on the camera view: @dstoychev has a patch about this that needs to be cleared
ability to select between preconfigured ROIs
Originally posted by @juliomateoslangerak in python-microscope/microscope#260 (comment)
Originally posted by @iandobbie in python-microscope/microscope#260 (comment)
This should be very easy to implement in the same manner that transform is already a config option in depot for cameras.
The text was updated successfully, but these errors were encountered: