bluesky / ophyd-async

Hardware abstraction for bluesky written using asyncio
https://blueskyproject.io/ophyd-async
BSD 3-Clause "New" or "Revised" License
11 stars 26 forks source link

DatasetDescriber for AD based StandardDetectors should use file plugin signals for size/data type, rather than top level #659

Open jwlodek opened 2 days ago

jwlodek commented 2 days ago

Currently, the AD standard dets instatiate ADBaseDatasetDescriber with the top level driver. They should use the io for the file plugin instead. It should have the same signals, so should work in-place. The reason is that the size/dtype of the frame as it comes out of the detector is not necessarily the size/dtype written to disk. For example, an ROI plugin can crop the image and reduce the size.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Create AD standard det device
  2. Set up AD plugin execution chain to add an ROI to crop the image
  3. Run an acquisition
  4. See shape listed in docs does not match shape on-disk.

Acceptance Criteria

coretl commented 12 hours ago

The problem with this is that we require describe to work before the first frame has been acquired. We can do this if we point ADBaseDatasetDescriber at the driver because those PVs are populated even before the first frame is acquired, but if we point at the fileio then it won't work and we're back to having to "prime" the chain which I really didn't want to do...

jwlodek commented 9 hours ago

Don't we need to prime the chain for the HDF plugin anyway since the IOC side needs to know the dimensions before starting capture?

coretl commented 8 hours ago

Nope, we use lazy=True so the file open is deferred to receiving first frame

jwlodek commented 7 hours ago

Ah OK. I think maybe what we can do is twofold - first, have an option (that defaults to using the driver signals) to use any NDArrayBaseIO in the dataset describer, rather than an ADBaseIO. Second, when we emit a resource doc, check the dataset describer output against the signals of the file plugin, and emit a warning at least if they don't match.

I caught this when trying to read back some data collected at HEX where they had applied an ROI to the image to cut out something that was in the frame. Collection and everything worked fine, but since the shape metadata was incorrect we couldn't read the data back.