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
Is your feature request related to a problem? Please describe. WSPBiexTransform seems to rely on the default value for the channel_range in its call to generate_biex_lut, which is 4096. However, this is not static and can vary within FlowJo workspace XML, specified by the "length" param. See example below from a FlowJo 10.10 wsp:
Given generate_biex_lut is already written to handle this variability, hopefully it is pretty easy to provide the flexibility one layer up the call stack.
Describe the solution you'd like
Allow channel_range as an arg to WSPBiexTransform constructor. It's still fine if it defaults to 4096.
Describe alternatives you've considered
Locally forking or re-implementing the logic of the constructor to generate the transform function and its inverse
Additional context
Discovered by successful import of FlowJo workspace that generated improperly transformed data (not matching that in FlowJo). It looks like this is getting parsed from the XML and strictly enforced as 256, which makes the 4096 default even stranger.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
WSPBiexTransform seems to rely on the default value for the
channel_range
in its call togenerate_biex_lut
, which is 4096. However, this is not static and can vary within FlowJo workspace XML, specified by the "length" param. See example below from a FlowJo 10.10 wsp:Given
generate_biex_lut
is already written to handle this variability, hopefully it is pretty easy to provide the flexibility one layer up the call stack.Describe the solution you'd like
Allow
channel_range
as an arg toWSPBiexTransform
constructor. It's still fine if it defaults to 4096.Describe alternatives you've considered
Locally forking or re-implementing the logic of the constructor to generate the transform function and its inverse
Additional context
Discovered by successful import of FlowJo workspace that generated improperly transformed data (not matching that in FlowJo). It looks like this is getting parsed from the XML and strictly enforced as 256, which makes the 4096 default even stranger.
The text was updated successfully, but these errors were encountered: