Closed jacobpwagner closed 3 years ago
Actually, this may be pretty straightforward. CurlyQuadGate::interpolate appears to just revert back to raw, then to 256 scale to do the interpolation anyway. So why not just do the interpolation starting from the raw scale as the gate is brought in?
For example, simply adding this:
trans_local dummyTrans = trans_local();
gate->interpolate(dummyTrans);
right before this this return appears to solve this issue for me. With transform = TRUE
, the gates still appear appropriately interpolated on the transformed scales, but with transform = FALSE
, they appear to be appropriately interpolated on the raw scales as well.
I suppose if that change were made, then the interpolation could be removed from GatingHierarchy::transform_Gate, as it would be already be done. The scales would just need to be set up appropriately for the transformation.
I could be missing something, though.
In fact the gate is stored as transformed scale in xml, and for non-linear scale, the transformation won't be available during gate parsing stage in order to properly rescale the gate to 256 space for the interpolation, which is why we had to deliberately delay the interpolation until transform_gate
The test case you are using may be the linear scale?
Ah. Yeah. Sorry, that makes sense. Alright. I'll find another workaround I suppose.
Describe the bug Hey @mikejiang. I'm running in to a really particular issue with parsing
CurlyQuadrant
gates from FlowJo withtransform = FALSE
(which also necessitatesexecute = FALSE
). Basically, it looks like somewhere along the way only the center vertex gets written out so.cpp_getGate
only returns the single central vertex here (g$x
andg$y
each only have a single value), which causes this to fail with this error:I'll also keep trying to trace it backwards to the root problem and update if I find anything.
To Reproduce Steps to reproduce the behavior:
I believe this should be reproducible with any FlowJo xml with CurlyQuadrant gates on transformed scales. I don't have access to these internal test files, but I'm guessing this should reproduce it. You'd have to put an appropriate CurlyQuadrant population in the
gh_pop_get_gate
call (I can't glean what those would be from the test file)That last
gh_pop_get_gate
call should yield the error. If that is not the case, I can probably attach a particular wsp for which I am seeing the error and update the reprex.Additionally, it appears this is confined to the
polygonGates
resulting from CurlyQuadrant gates in the xml. Regular PolygonGates are coming through just fine, as are the other two quadrant types (regular and skewed).Expected behavior No errors. I'd expect the CurlyQuadrant gates to be interpolated to polygons as usual, just on the untransformed scales.
SessionInfo: