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 think removal of saturated events is something that should be done because they are numerically incorrect and will mess up the distribution statistics. This is even more relevant in the Excel UI, where the main output are statistics, and where most people don't look at the histograms.
@JS3xton, however, has presented a case in which he thinks not removing saturated events is justified:
I've also had situations where I did not want to do high_low gating (quantifying 2 different populations where one of my populations was saturating. FSCvSSC gate made me confident I was isolating cells, so I did not want to throw away events that saturated low or high in my fluorescence channel).
I would argue that the real solution would be to use a better detector voltage when acquiring that data. If you're only looking at histograms, not discarding saturating events is probably fine. But the moment you calculate means or anything else is when you get objectively incorrect values.
But let's say you don't want to re-acquire the data and just make the best of the data you already have. I would then argue that you can choose to not discard saturating events via the Python API.
But if we really want to pull this into the Excel UI (where, as I said, the main output are statistics, and most people don't look at the histograms), a middle ground where we agree seems to be an additional column called "Remove Saturated Events" with values True or False. I would argue that, if the column is not present (and it should not be present in the example file), saturated events should be removed, so that removing saturated events is an "opt-out" procedure. This preserves the current default behavior but allows users who know what they are doing to disable it.
An additional idea in #246 was to lump this (more specifically, high_low gating with saturating values as low and high) into the scatter gates, instead of making it into its own column. But this would make it harder for the user to specify whether to remove saturating values in the fluorescence channels, at least until #270 is implemented (which might take a while).
Finally, this is only relevant for files with integer datatype, as files with floating-point datatype do not saturate events at predictable values.
The text was updated successfully, but these errors were encountered:
Original discussion in #246.
I think removal of saturated events is something that should be done because they are numerically incorrect and will mess up the distribution statistics. This is even more relevant in the Excel UI, where the main output are statistics, and where most people don't look at the histograms.
@JS3xton, however, has presented a case in which he thinks not removing saturated events is justified:
I would argue that the real solution would be to use a better detector voltage when acquiring that data. If you're only looking at histograms, not discarding saturating events is probably fine. But the moment you calculate means or anything else is when you get objectively incorrect values.
But let's say you don't want to re-acquire the data and just make the best of the data you already have. I would then argue that you can choose to not discard saturating events via the Python API.
But if we really want to pull this into the Excel UI (where, as I said, the main output are statistics, and most people don't look at the histograms), a middle ground where we agree seems to be an additional column called "Remove Saturated Events" with values True or False. I would argue that, if the column is not present (and it should not be present in the example file), saturated events should be removed, so that removing saturated events is an "opt-out" procedure. This preserves the current default behavior but allows users who know what they are doing to disable it.
An additional idea in #246 was to lump this (more specifically, high_low gating with saturating values as low and high) into the scatter gates, instead of making it into its own column. But this would make it harder for the user to specify whether to remove saturating values in the fluorescence channels, at least until #270 is implemented (which might take a while).
Finally, this is only relevant for files with integer datatype, as files with floating-point datatype do not saturate events at predictable values.
The text was updated successfully, but these errors were encountered: