You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd vote for NOT supporting multi-element detectors. It leads to too many choices about how to apply deadtime corrections. Since these corrections need to be done once, and are generally not played with, it's just easier to require that this be done and columns be added before putting into an XDI file.
Also, if you allow MED data, you have to allow 400 detectors, as from a MAIA.. And that could mean 400 "summed ROIS", 400 input-count-rates and 400 output-count rates, all floating point numbers, meaning a single line would exceed 10,000 characters.
I am not clear why a 10000-character wide line is inherently problematic, except for implementations in laguages lacking dynamic memory allocation. As I said on the mailing list, I agree that the user will usually want those 400 channels summed into a single column. But if someone has a reason to examine the data column-by-column (and cannot, for whatever reason, use an archival format more appropriate for such large data quantities), then that should be possible.
Conveying the raw signal from each channel sounds like a data interchange issue to my ear.
How do we specify the columns of a multi-element detector? I would suggest something like:
except that is inconsistent with the more generic
Column.N
header scheme.The text was updated successfully, but these errors were encountered: