Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow WSPBiexTransform contructor to specify channel_range #235

Open
jacobpwagner opened this issue Jan 6, 2025 · 0 comments
Open

Allow WSPBiexTransform contructor to specify channel_range #235

jacobpwagner opened this issue Jan 6, 2025 · 0 comments

Comments

@jacobpwagner
Copy link

jacobpwagner commented Jan 6, 2025

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:

 <transforms:biex transforms:length="256"  transforms:maxRange="214748"  transforms:neg="0"  transforms:width="-10"  transforms:pos="4.3319291278" >
   <data-type:parameter data-type:name="FL1" />
 </transforms:biex>

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant