-
Notifications
You must be signed in to change notification settings - Fork 5
1283 use pixels per micron from file not gda #1298
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, as per comment I think there's a bit of a nicer way to do it
yield from bps.abs_set( | ||
oav.snapshot.microns_per_pixel_x, oav.parameters.micronsPerXPixel | ||
) | ||
yield from bps.abs_set( | ||
oav.snapshot.microns_per_pixel_y, oav.parameters.micronsPerYPixel | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should: I don't think it makes sense for it to be the job of this plan to do this at feels internal to the OAV. I think that the OAV itself should manage the state of the microns_per_pixel
information. What about we convert OAVConfigParams
into a Device
itself that we can read the microns_per_pixel
from? Then in this file when we do yield from bps.read(oav.snapshot)
we can just do yield from bps.read(oav.parameters)
at the same time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the microns_per_pixel should be on the snapshot as it's a property of the individual snapshot, depending on zoom etc the OAV microns per pixel can change over time, whereas if it's on the snapshot you always know that it relates to the specific image you are looking at.
Having said that I agree it would be nice if somehow the OAV device itself applied the current mpp to the snapshot at the point at which it is generated.
I didn't do it because at the time it looked a bit fiddly and didn't want to get sidetracked.
"oav_snapshot_microns_per_pixel_x": 1.25, | ||
"oav_snapshot_microns_per_pixel_y": 1.25, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could: Would be good to not have these equal in each dimension, to test that we're using the right one at the right time
b5efe47
to
5dd5eb9
Compare
523094c
to
072d694
Compare
662c1aa
to
36436f3
Compare
6b8f472
to
1decd6a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thank you! Can you remove the unused and empty good_test_stepped_grid_scan_parameters.json
and fix the merge conflicts/failing tests? Otherwise I think this is mergeable :)
…A parameters WIP for grid-scan ispyb system test
…A parameters WIP for grid-scan ispyb system test
…A parameters * Remove support for 2D gridscans from ispyb callbacks * Remove references to microns-per-pixel from ispyb params * Ispyb system test for grid scan and grid-detect
Remove microns-per-pixel from ispyb_params Fix minor issue where grid-ids were not being returned in the IspybIds
…napshot is triggered instead of requiring the plan to apply it manually.
* Fix broken system+unit tests * Fix pathlib.Path being passed into grid_detection_plan instead of str
1decd6a
to
709859a
Compare
…Source/1283_use_pixels_per_micron_from_file_not_GDA 1283 use pixels per micron from file not gda
Fixes #1283
Link to dodal PR (if required): DiamondLightSource/dodal#423
(remember to update
setup.cfg
with the dodal commit tag if you need it for tests to pass!)To test: