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

Linking with static plot seems to have some errors #117

Open
dicook opened this issue Jun 8, 2023 · 3 comments
Open

Linking with static plot seems to have some errors #117

dicook opened this issue Jun 8, 2023 · 3 comments

Comments

@dicook
Copy link
Collaborator

dicook commented Jun 8, 2023

When linking between a static plot and the tour, using code from your upcoming paper, the points that have been brushed don't necessarily match the corresponding points in the tour view.

image

See that brushing the small cluster, shows as this cluster and the smile in the tour view. Is there a problem linking the row to row?

Here is the code to reproduce the problem.

# remotes::install_github("dicook/mulgar")
library(mulgar)
library(uwot)
library(detourr)
library(dplyr)
library(crosstalk)
library(plotly)

set.seed(42)
cnl_umap <- umap(clusters_nonlin)
umap_df <- data.frame(umapX = cnl_umap[, 1],
                      umapY = cnl_umap[, 2])

cnl_df <- bind_cols(clusters_nonlin, umap_df)
shared_cnl <- SharedData$new(cnl_df)

detour_plot <- detour(shared_cnl, tour_aes(
  projection = starts_with("x"))) |>
    tour_path(grand_tour(2), fps = 60) |>
       show_scatter(alpha = 0.7, axes = FALSE,
                    width = "100%", height = "450px")

tsne_plot <- plot_ly(shared_cnl,
                    x = ~umapX, 
                    y = ~umapY,
                    color = I("black"),
                    height = 450) %>%
    highlight(on = "plotly_selected", 
              off = "plotly_doubleclick") %>%
    add_trace(type = "scatter", 
              mode = "markers")
@casperhart
Copy link
Owner

casperhart commented Jun 10, 2023

In the example, I don't think the smile is highlighted, it's just the points are packed so densely that they appear darker due to the overlap, which makes it harder to distinguish the highlighted vs. non-highlighted points.

For example here, I have only the small cluster selected:
image

And it isn't clear that it's only the small cluster that's selected until I change the colour:
image

To show this more clearly, If I select both the small cluster along with some of the smile, the selected points in the smile do become darker:
image

So this could definitely be made better, but I'm not sure the best approach that will retain the alpha transparency in both the selected and non-selected points. What do you think?

@dicook
Copy link
Collaborator Author

dicook commented Jun 11, 2023

Oh, I'm sure you're right. I kept thinking going back and forth on whether it was correct or not.What about automatically colouring the selection with the current colour? This would then make it clear what is selected or not, and allow the alpha transparency to stay as it is.

@casperhart
Copy link
Owner

The problem with applying the current brush colour immediately is if some brushing / selection has already been done, the same issue will crop up again.

I think having the selection highlighted with some colour could work, but it should work separately from the brush and be cleared when the selection is cleared. There would still be some risk of the highlight colour clashing with a brush colour, but this shouldn't be much of an issue.

Alternatively, the highlighted points could be given a red border or something. Maybe a red and white border in case the points have already been brushed red.

I'm not sure what these would take to implement, but I might have time to look in to it in a few weeks.

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

2 participants