Metadata Dtypes #1328
Description
I've given some thought to the dtype dilemmas coming up in our Source codes following discussion/debugging #1302 with Josh yesterday. With some code changes, we were able to get all the single/double cases to work as I would require for the save/load round trips, but this solution will create problems in practice for all real ImageSource's whereby their preprocessing behaviors will not be correct (imo) unless run as doubles.
Specifically, I have a lot of concern with truncating the meta parameters to singles. The most obvious example that came up is that common values for pixel size (eg ribosom 1.34 or yeast's 1.43) are not going to be representable. This will immediately yield compounding error intervals for filters, offsets etc all down the line. It was so much trouble getting the single (low error calcs) mul and divs to match up for this new Relion offset design that I have no inclination to go through the same for deep calculations.... there is no benefit to it and it will put all the prior work I've done matching things at very high risk for regression.
The code's gemmi/STAR interface is already configured to be virtually all float (doubles), so that is a positive.
I think the thing to do here is to hold and interact with all the metadata as doubles. The images themselves can still be served as single/double, but that is probably the only thing that makes sense to do as singles. (I'm less in agreement about that than when I started, but I digress).