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

[jwlodek]

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

• AD standard detectors use fileio signals for size and dtype to generate documents.

[coretl]

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]

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]

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

[jwlodek]

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.