Casting back to int after motion correction

Hi everyone! I had a quick question about casting back to int16 for saving after motion correction. During motion correction the data must be in float for interpolation, but saving to binary (e.g. to pass to a sorter) is generally required to go back to int16 for disk space. I'm wondering if anyone has looked into the effect on this on the motion correction?

I guess if a spike is in the range ~0-200uV its feasible that casting back to int will loose some useful precision, but I've not measured it. I guess if you had a 100.5uV rounded to 101uV you would loose 0.5% precision, 1% at 50uV etc). Also I guess if you were to motion-correct then whiten (now in a small uV range) then cast back to int16 there would definitely be some issues. I don't have time to test this at the moment but was curious if anyone had ever looked into it?

Review the motion-correction and binary-saving paths in the Python package, then trace how data types change before and after interpolation. Measure whether casting corrected or whitened data back to int16 loses meaningful precision, and document the result or define a scoped change based on that evidence.