ggcyto vs FlowJo axis transformation

[malisas]

Hi, I am wondering why the x-axis (CD154) looks like this in FlowJo:

but like this in ggcyto: (the low end of the CD154 population ends more "bluntly")

My guess is that the same events are being plotted in both FlowJo and ggcyto, but the axis transformation used for visualization is a little different, which makes it look more blunt in ggcyto. That would be the best scenario, as opposed to the alternative, in which I'm losing some CD154- events somewhere along the way.

Just wondering if this is a known issue that someone has insight into.

Thank you!

[gfinak]

Could this share this sample and workspace so we can troubleshoot?

[malisas]

Just sent to you and Jake. Thanks!

[jacobpwagner]

Thanks. I'll take a look in a little bit.

[jacobpwagner]

Hi @malisas , sorry I'm getting to this a little late. I actually cannot open that workspace from FlowJo 10.6.1. I just get an "Error Adding Files" notification. I can, however, open it and create as a GatingSet using CytoML as in your Rmd. I'm still investigating that issue.

I do recall there being an issue with one of the transformations whose definition changed between FlowJo versions that may be the cause of this (as this workspace is version 9.9.6) depending on whether we are handling both sides of the change in CytoML. I'm looking back through my records now to figure that out.

But, on the plus side, I can confirm that no cells are being lost:

> gh_pop_get_data(gs[[1]])
cytoframe object '15530_H12_H12_096.fcs'
with 215775 cells and 21 observables:

Anyway, I'll update here when I know more.

[jacobpwagner]

I think the issue of opening it is because the workspace is still explicitly pointing to the original home of the files. I can try to fix that in the xml, though.

[jacobpwagner]

@malisas , so the compensation matrix looks a little suspect, but I think the blunting you're seeing is just a result of your inclusion of marginalFilter for filtering the plotted data:

ggcyto(gs[[1]],
       aes(!!currentXaxis, !!currentYaxis),
       subset = parentGate,
       filter = marginalFilter) +
    geom_hex(bins=128) +
    geom_gate(myGate) +
    axis_x_inverse_trans() + axis_y_inverse_trans() +
    coord_cartesian(xlim = c(-100, 4000), ylim = c(-100, 4000)) +
    geom_stats()

Removing the marginal filter and adjusting the bins accordingly:

ggcyto(gs[[1]],
       aes(!!currentXaxis, !!currentYaxis),
       subset = parentGate) +
    geom_hex(bins=1024) +
    geom_gate(myGate) +
    axis_x_inverse_trans() + axis_y_inverse_trans() +
    coord_cartesian(xlim = c(-100, 4000), ylim = c(-100, 4000)) +
    geom_stats()

[jacobpwagner]

Actually, one better, if you avoid the y-dimension gate extension logic by passing a large negative value to extend_val in flowjo_to_gatingset (see Greg's discussion here), you will get even closer to what you have in FlowJo :

gs <- flowjo_to_gatingset(ws, name=sampleGroup, keywords=keywords2import,
                             path=fcs_subfolder, extend_val = -10000)

...

ggcyto(gs[[1]],
       aes(!!currentXaxis, !!currentYaxis),
       subset = parentGate) +
    geom_hex(bins=128) +
    geom_gate(myGate) +
    axis_x_inverse_trans() + axis_y_inverse_trans() +
    coord_cartesian(xlim = c(-100, 4000), ylim = c(-100, 4000)) +
    geom_stats()

[malisas]

Hi Jake, thank you so much for troubleshooting this.

I had gotten into the habit of using marginalFilter every time I plotted something with ggcyto (to make the hex bins look nice), but I will use it more judiciously from now on to avoid things like this.

About the gate extension thing, it seems that:

1. Setting extend_val = -10000 will result in similar gate membership in openCyto and FlowJo (as seen by the geom_stats() number), but
2. (according to the linked issue) this setting may actually be undesirable because openCyto is correcting a FlowJo export issue.
3. So perhaps I should try out both ways to make sure that the biological and statistical conclusions will not be too affected by this setting.

[jacobpwagner]

Yep, in general the extend_val logic is still necessary at least up through FlowJo 10.6.1, although not for ellipsoidGates. More discussion here. So you're right that you may need to try it both ways, particularly for older FlowJo versions.

[malisas]

Just an update about extend_val:

I'm very glad that you mentioned the extend_val issue to me, because I experienced a problem related to it today.

With the default extend_val=0 setting, ggcyto was displaying an artifact in my dataset that was not showing up in FlowJo (see left side of figure below).

It turned out that the L/D gate was getting extended in flowjo_to_gatingset to include those events (which also show up as an odd line when looking at CCR7 vs CD45RA):

So I guess I should be using extend_val=-10000 (or some large negative number) for this dataset at least.

Thanks again for your insight!