add ability to control dot size in static tSNE/MAP scatters
Closed this issue · 23 comments
in the static scatter the size of the plotted points is scaled automatically as the number of cells/samples to plot changes (larger dots for fewer, smaller for more). in general this works well, but in some cases, especially when plotting spatial data it would be very useful to be able to control the size of the plotted points manually
Writing for documentation purposes. According to scanpy, the default point size is automatically computed as 120000 / n_cells
I will also implement a slider like is shown in the Plotly scatter plot marker size option
Made a size range from 1 - 100, since the auto-scaling formula is based on 120K cells.
Picture with size 100
Picture with size 1 (which might be too small)
Marker size = None (auto-scaling applied)
hey shaun - i cant see this in nemo devel or nemo production - is it only on gear?
It's there. When you plot in the curator, open the Plot Configuration dropdown, check "Override marker size auto-scaling" and then the slider underneath will let you choose your own marker or dot sizes
@carlocolantuoni , you are going to need to reply directly to the Github issue instead of through email... the attachment you tried to send does not show up in the github ticket nor the email response.
Have you cleared your browser cache? Occasionally when we make changes the old version is still cached in the browser.
cleared cache, no change, here is what i see:
You need to create a basic plot first then the view I attached shows up. I redesigned both curators so that more advanced "power user" options are available after an initial plot. This way all of the options do not overwhelm beginner users, and I felt most people would adjust the plot after seeing some initial results.
ok trying now thnx
its all working now - thnx!
this is really huge for figure prep on the big paper we are pushing out - feel so dumb i did not realize where they were the whole time that you were adding features! i can use them now!
oops - then i got this: "Could not create plot image for this dataset and parameters. Please contact the gEAR team."
i switched a few paramaters and now its working, so dont worry about the last error for now
playing with parameters - it looks like the one that causes the "Could not create plot image for this dataset and parameters. Please contact the gEAR team." error is the "Check to bring data extremes to foreground", but just for this 1 datasets, not others - dont know why.
this "Check to bring data extremes to foreground" option plots highest values on top right? Can we call that "Check to plot high values on top of lower values" and also add a "Check to plot low values on top of higher values" option?
Resolving this issue, along with adding the colorway from PCA projection (and new datasets joshua is moving to devel) will enable ALL the remaining figures for the paper! so excited, will send a new version soon if you are interested.
playing with parameters - it looks like the one that causes the "Could not create plot image for this dataset and parameters. Please contact the gEAR team." error is the "Check to bring data extremes to foreground", but just for this 1 datasets, not others - dont know why.
It seems that error occurred because for that dataset, numpy made a sparse matrix out of the expression data, and their Sparse Matrix class did not have a method call for something I was using "numpy.squeeze()". I've personally never seen that before, but I'm sure a quick google search will give some solution that handles both sparse and dense matrices.
this "Check to bring data extremes to foreground" option plots highest values on top right? Can we call that "Check to plot high values on top of lower values" and also add a "Check to plot low values on top of higher values" option?
I think having two separate checkboxes to address this would be confusing. I think a better idea would be to have a dropdown for data point sort order with options like "highest values on top (default)", "lowest values on top", "two-way (or data extremes... whatever we want to call it)". I would have to implement more data point sort order algorithms to accommodate for a "lower on top" but I think it's a better solution.