ConstructMetaspots not compatible with Seurat's VisiumV2 class

[ppm1337]

Since Seurat v5.1 the default image class (also for non-Visium HD data) is VisiumV2. Unfortunately, the resulting object has a completely different structure and hence no slot anymore called coordinates, which ConstructMetaspots tries to access:

Error in nrow(cur_seurat@images[[x]]@coordinates) : 
  no slot of name "coordinates" for this object of class "VisiumV2"

I came across the error following the described workflow for Visium ST data when calling MetaspotsByGroups.

The SeuratObject I'm using returns 5.0.2 when checking it's version slot.

R session info

R version 4.3.3 (2024-02-29)
Platform: x86_64-conda-linux-gnu (64-bit)
Running under: Ubuntu 22.04.2 LTS

Matrix products: default
BLAS/LAPACK: /home/peter/universal_envs/hdwgcna/lib/libopenblasp-r0.3.27.so;  LAPACK version 3.12.0

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C               LC_TIME=en_GB.UTF-8       
 [4] LC_COLLATE=en_GB.UTF-8     LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8   
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
[10] LC_TELEPHONE=C             LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

time zone: Europe/Brussels
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] purrr_1.0.2           patchwork_1.2.0       hdWGCNA_0.3.01        igraph_2.0.2         
 [5] WGCNA_1.71            fastcluster_1.2.6     dynamicTreeCut_1.63-1 ggrepel_0.9.5        
 [9] Seurat_5.1.0          SeuratObject_5.0.2    sp_2.1-3              harmony_1.2.0        
[13] Rcpp_1.0.12           ggplot2_3.4.4         GeneOverlap_1.38.0    furrr_0.3.1          
[17] future_1.33.2         enrichR_3.2           dplyr_1.1.4           cowplot_1.1.3        

loaded via a namespace (and not attached):
  [1] RcppAnnoy_0.0.22        splines_4.3.3           later_1.3.2             bitops_1.0-7           
  [5] tibble_3.2.1            polyclip_1.10-6         preprocessCore_1.64.0   rpart_4.1.23           
  [9] fastDummies_1.7.3       lifecycle_1.0.4         doParallel_1.0.17       globals_0.16.3         
 [13] lattice_0.22-6          MASS_7.3-60             backports_1.4.1         magrittr_2.0.3         
 [17] rmarkdown_2.26          Hmisc_5.1-2             plotly_4.10.4           httpuv_1.6.15          
 [21] sctransform_0.4.1       spam_2.10-0             spatstat.sparse_3.0-3   reticulate_1.36.0      
 [25] pbapply_1.7-2           DBI_1.2.2               RColorBrewer_1.1-3      abind_1.4-5            
 [29] zlibbioc_1.48.0         Rtsne_0.17              BiocGenerics_0.48.1     RCurl_1.98-1.14        
 [33] nnet_7.3-19             WriteXLS_6.5.0          GenomeInfoDbData_1.2.11 IRanges_2.36.0         
 [37] S4Vectors_0.40.2        irlba_2.3.5.1           listenv_0.9.1           spatstat.utils_3.0-4   
 [41] goftest_1.2-3           RSpectra_0.16-1         spatstat.random_3.2-3   fitdistrplus_1.1-11    
 [45] parallelly_1.37.1       leiden_0.4.3.1          codetools_0.2-20        tidyselect_1.2.1       
 [49] farver_2.1.1            tester_0.2.0            matrixStats_1.1.0       stats4_4.3.3           
 [53] base64enc_0.1-3         spatstat.explore_3.2-6  jsonlite_1.8.8          progressr_0.14.0       
 [57] Formula_1.2-5           ggridges_0.5.6          survival_3.5-8          iterators_1.0.14       
 [61] foreach_1.5.2           tools_4.3.3             ica_1.0-3               glue_1.7.0             
 [65] gridExtra_2.3           xfun_0.43               GenomeInfoDb_1.38.1     withr_3.0.0            
 [69] fastmap_1.1.1           fansi_1.0.6             caTools_1.18.2          digest_0.6.35          
 [73] R6_2.5.1                mime_0.12               colorspace_2.1-0        scattermore_1.2        
 [77] GO.db_3.18.0            gtools_3.9.5            tensor_1.5              spatstat.data_3.0-4    
 [81] RSQLite_2.3.4           utf8_1.2.4              tidyr_1.3.1             generics_0.1.3         
 [85] data.table_1.15.2       httr_1.4.7              htmlwidgets_1.6.4       uwot_0.1.16            
 [89] pkgconfig_2.0.3         gtable_0.3.4            blob_1.2.4              impute_1.76.0          
 [93] lmtest_0.9-40           XVector_0.42.0          htmltools_0.5.8.1       dotCall64_1.1-1        
 [97] scales_1.3.0            Biobase_2.62.0          png_0.1-8               rstudioapi_0.16.0      
[101] knitr_1.46              reshape2_1.4.4          rjson_0.2.21            checkmate_2.3.0        
[105] nlme_3.1-164            curl_5.1.0              proxy_0.4-27            zoo_1.8-12             
[109] cachem_1.0.8            stringr_1.5.1           KernSmooth_2.23-22      parallel_4.3.3         
[113] miniUI_0.1.1.1          foreign_0.8-86          AnnotationDbi_1.64.1    pillar_1.9.0           
[117] grid_4.3.3              vctrs_0.6.5             RANN_2.6.1              gplots_3.1.3.1         
[121] promises_1.3.0          xtable_1.8-4            cluster_2.1.6           htmlTable_2.4.2        
[125] evaluate_0.23           cli_3.6.2               compiler_4.3.3          rlang_1.1.3            
[129] crayon_1.5.2            future.apply_1.11.2     labeling_0.4.3          plyr_1.8.9             
[133] stringi_1.8.3           viridisLite_0.4.2       deldir_2.0-4            munsell_0.5.1          
[137] Biostrings_2.70.1       lazyeval_0.2.2          spatstat.geom_3.2-9     Matrix_1.6-5           
[141] RcppHNSW_0.6.0          bit64_4.0.5             KEGGREST_1.42.0         shiny_1.8.1.1          
[145] ROCR_1.0-11             memoise_2.0.1           bit_4.0.5

[smorabit]

Thank you for taking the time for writing this issue and for diagnosing the problem regarding the new class structure. FYI, I am currently very busy with some upcoming deadlines over the next couple of weeks, so I will not be able to push a fix for this until late June or early July. For now you might want to just use Seurat 4 if possible.

[ppm1337]

Thanks for considering the support of the VisiumV2 class in the future. I've also opened an issue in the Seurat repository regarding the handling of the different image classes. A Seurat maintainer specifically addressed hdWGCNA in their reply, so you may want to check out the corresponding Seurat issue.

[Lucayao777]

Thank you for taking the time for writing this issue and for diagnosing the problem regarding the new class structure. FYI, I am currently very busy with some upcoming deadlines over the next couple of weeks, so I will not be able to push a fix for this until late June or early July. For now you might want to just use Seurat 4 if possible.

Thank you! I have same problems. Do you find the way to get the row, col, imagerow, and imagecol in Seurat 5.1.0?just like the tutorial https://smorabit.github.io/hdWGCNA/articles/ST_basics.html, I can't find coordinates in this data and I try to run

coords <- GetTissueCoordinates(cur_seurat)
coords <- coords[, 1:2]
colnames(coords) <- c("row", "col")

still lack two cols. And I try to install Seurat V4, it's still not work

[ppm1337]

The easiest workaround without downgrading to Seurat v4 is to use the coordinates directly from the spaceranger output (<space_ranger_dir>/outs/spatial/tissue_positions.csv) and bind them to the meta data of the SeuratObject. To obtain these from the file, you could use the Seurat::Read10X_Coordinates method. Alternatively, you can just use Seurat::GetTissueCoordinates on the SeuratObject with VisiumV2 image(s) and provide different scale parameters to obtain the relevant (scaled/unscaled) coordinates.

However, this will not prevent the error described in this issue because hdWGCNA::ConstructMetaspots will try to access the coordinates slot of the input SeuratObject. A workaround to create a VisiumV1 object manually is described in the linked Seurat issue.

[Lucayao777]

不降级到Seurat v4的最简单解决方法是直接使用spaceranger输出（<space_ranger_dir>/outs/spatial/tissue_positions.csv）的坐标，并将其绑定到SeuratObject的元数据。要从文件中获取这些，您可以使用Seurat::Read10X_Coordinates方法。或者，您只需在带有VisiumV2图像的SeuratObject上使用Seurat::GetTissueCoordinates，并提供不同的scale参数来获得相关的（缩放/未缩放）坐标。

然而，这不会阻止此问题中描述的错误，因为hdWGCNA::ConstructMetaspots将尝试访问输入SeuratObject的coordinates插槽。链接的Seurat问题中描述了手动创建VisiumV1对象的变通方法。

The easiest workaround without downgrading to Seurat v4 is to use the coordinates directly from the spaceranger output (<space_ranger_dir>/outs/spatial/tissue_positions.csv) and bind them to the meta data of the SeuratObject. To obtain these from the file, you could use the Seurat::Read10X_Coordinates method. Alternatively, you can just use Seurat::GetTissueCoordinates on the SeuratObject with VisiumV2 image(s) and provide different scale parameters to obtain the relevant (scaled/unscaled) coordinates.

However, this will not prevent the error described in this issue because hdWGCNA::ConstructMetaspots will try to access the coordinates slot of the input SeuratObject. A workaround to create a VisiumV1 object manually is described in the linked Seurat issue.

so,seurat or hdwgcna must do some changes, and I notice that dcollins15 said he will make a patch soon, so we can wait for him

[smorabit]

This issue is not fully solved, it looks like the Visium V2 Seurat no longer uploads all the coordinates that are output from spaceranger, which ultimately causes issues with hdWGCNA. The workaround is to use Seurat v4, or to load the output table
with the coordinates from spaceranger. The tutorial has been updated to discuss this:

https://smorabit.github.io/hdWGCNA/articles/ST_basics.html