Change xlim and ylim independently for each channel when exporting a .wsp to flowJo. about cytoml HOT 7 OPEN

I am not sure the hard-coded axis limits approach will be sufficient to handle visualization scales in all different gates of the entire gating tree. That said, the limits of exported flowJo plots do look a little strange.
I don't have a clue yet regarding to how to control the flowJo axis through its xml. I will have to install a flowJo software locally to explore it or consult the flowJo people before getting back to you on this.
For now, you will have to manually adjust it in flowJo once imported.

from cytoml.

Hi Mike,
With a little help from Josef, I managed to solve this issue with the axis labelling. I had to edit the GatingSet2flowJo.R function. I added 20-30 lines. It would be easiest to compare the original with my version (see attached) through a diff program like meld.
GatingSet2flowJo.zip

The things I added were as follows:

1. I created a parameter, Scaling, allowed to be sent to the function GatingSet2flowJo.
2. Scaling is defined as (as an example):

• Scaling <- list( c(316, 5000000), c(100,30000000), ..., c(10, 5000000))
• names(Scaling) <- (gs@data[[1]]@parameters@data$name)
• GatingSet2flowJo(gs, output.path, Scaling)

3. Scaling gets passed down through workspaceNode, SampleListNode and transformationNode.
4. Inside transformationNode there are different options/cases based on the type of transformation that is wanted to be implemented. The ones I have edited are trans.type == "flowJo_linear", trans.type == "logicle" and trans.type == "flowJo_biexp".
5. The "flowJo_linear" essentially will replace the minRange and maxRange if a min and max has been defined in Scaling for that parameter. If not, it uses your default.
6. The "logicle" sets offset to the min and then calculates decades based on the min and max given by Scaling. Again the default is used if Scaling does not contain that channel. Essentially this was done for a project I was working on and is not completely consistent with how FlowJo or CytoML defines certain transformations. Essentially my project was always "trans.type == logicle" and I created a transformation that they needed.
7. The "flowJo_biexp" section has actually been commented out. Even though CytoML allows me to change the "transforms:neg" value to anything, FlowJo only accepts between 0 and 1. (or 0 and -1, I can't remember). However, changing the "transforms:neg" slightly and changing "transforms:pos" can be effective here.

I believe that a more robust version could be implemented. Perhaps Scaling could also contain the type of transformation that is wanted to be created. And trans.type could be overwritten with that. Or perhaps a better designed Scaling input parameter could be created to allow for any of the different transformation options.

I hope you find this useful. We will most likely be needing this for the majority of our projects that need us to create .wsp files, provided the transformation isn't sent to FlowJo seemlessly. Perhaps the bi-ex transform is much more robust and this is only occurring for us now because we used a logicle. But none the less, it would be great to have this functionality in an updated version of CytoML.

Thank you,
Justin

from cytoml.

Please note that this issue can be resolved if you accept my pull request for changes to GatingSet2flowJo.R. Thanks.

from cytoml.

@jmeskas my issue with your pull request is that you've deleted and re-added the file, so I can't tell what's changing. Is it possible to correct this?

from cytoml.

I am yet to run some tests to verify the changes. Also, as I mentioned, I don't have access to flowJo and I feel a little uncomfortable to apply changes without seeing the actual effects on exporting various use cases. (My current tests only check if the xml can be reloaded back to openCyto)

from cytoml.

I just re-did the commits on my github and did a new pull request. It only has one commit now. You should see that the changes are very minimal. Just added the "Scaling" parameter. And only lines of code can be accessed if Scaling is not NULL. Cheers.

from cytoml.

Thanks, @jmeskas

from cytoml.