Open jwlodek opened 2 days 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...
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?
Nope, we use lazy=True
so the file open is deferred to receiving first frame
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.
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:
Acceptance Criteria