Tile layout clarification

[trus-uic]

Hello,

Thank you for providing and documenting this innovative tool, I am very excited to put it to use!

I wanted to reach out with a couple questions on the tiling structure within each lane. When examining Fig. S1, panel A of your preprint: the tile layout of a capture area is depicted as having an alternating y-offset for each tile within a row. This is the case with the fc_1 coordinate system depicting the tiles having alternating offsets in-row.

In Illumina's depiction of their tiling structure for an S4, their tiles are in a grid-format:

https://emea.illumina.com/content/dam/illumina/gcs/assembled-assets/marketing-literature/novaseq-lane-edge-tech-note-m-amr-00104/novaseq-lane-edge-tech-note-m-amr-00104.pdf - page 3

Could you please clarify why this is the case? Is this the actual tiling structure as defined by Illumina, which they simplify in the above representation?

Additionally, the fc coordinate system file depicts their being a column (swath) 0 within a lane (tiles x0xx), while your pre-print and Illumina's documentation define 6 swaths within a lane. Is this something that should be considered, or should lane 0 be considered as a result of the code index starting at 0?

Finally, the fc_1_coordinate_system.csv provided for the e13 mouse head sample and fc_2_coordinate_system.csv for adult mouse hippocampus sample are incredibly similar, except that they start at different initial offsets for the leftmost swath within each lane. Could you clarify how this offset is determined or in general how the lane-tile coordinate system is determined?

Thank you for your time and please let me know if I am misinterpreting anything above. Much appreciated.

edit: grammar

[nukappa]

Hi @trus-uic, thanks for the interest!

1. Indeed, the scheme provided by Illumina is simplified.
2. Nomenclature is the following. For fc_1_L3_tile_1056, for instance, L3 denotes the lane number, 56 is the tile number within the same swath, 0 denotes the swath number, and 1 in the 1056 means the bottom part of the flow cell was used (2 if the top).
3. We determined the lane-tile coordinate systems empirically, by stitching our data and also comparing to the H&E image. Seems that these two Illumina flow cells were not manufactured in the same way.

Hope this helps & best of luck with implementing open-ST!

[trus-uic]

Thank you for your clarification! Best of luck.

[gianmore]

Hi! thanks for the amazing tool you developed! We have now generated according to your protocol pucks from an S4 flowcell. We have previously sequenced the capture area and we have retrieved the spatial barcodes coordinates for all tiles. So now I have my lanes_and_tiles.txt file, my collection of puck_barcode_files, and for the coordinate_system.csv I simply took the one you provide and I have changed the names in the puck_id column according to my nomeclature of the puck_barcode_file. But instead the offset have to be experimentally determined for each flowcell?? I see your explanation here (We determined the lane-tile coordinate systems empirically, by stitching our data and also comparing to the H&E image. Seems that these two Illumina flow cells were not manufactured in the same way.) Can you provide a documentation/tutorial on how to do it? Thanks in advance!

[gianmore]

Hi Steven, thank you very much! Just to check if I got it right, so if from the heatmap I can see that the borders between the tiles are sheared I can run openst spatial_stitch with the alternative coordinate system (it should work either fc_1_coordinate_system.csv or fc_2_coordinate_system.csv right?) and then I will have my final spatial_stitched_spots.h5ad file to continue the analysis with, is that correct?

[StevenSong]

yes, that's my understanding. you'd have to rename the tile IDs in the coordinate system csv's, like you mentioned in your original comment. hypothetically, if neither coordinate system csv's are correct, you'd have to manually offset the intra-tile coordinates stored in obs/x|y_pos, but we've had luck with fc_1_coordinate_system.csv

[gianmore]

Thanks, Steven! Do you happen to have a full image showing the numbering of the tiles in the lane? For the pucks we generated in-house, I'm considering dividing the puck barcode files into macroareas. This way, spacemake will have fewer files to screen for barcode matches.

[StevenSong]

Yes, I generated the following grids based on the coordinates in fc_1_coordinate_system.csv and fc_2_coordinate_system.csv. Note that these 2 files both have a 0 column (swath) per lane, which is not reflective of the actual flow cells which only have columns 1-6: see page 73 of the support pdf. We asked the authors about this in the original body of this post but not sure if the question came across correctly. Anyways, we have 2 versions of either flow cell layout, one with and one without the 0 swath.

flowcell 1

flowcell 2

flowcell 1 with 0 swath

flowcell 2 with 0 swath

Last thing is about the macro-areas. We thought the same thing and simply grouped it by lane (1-4) and glass piece (1-2). So in the end we had 8 sets of tiles. That way, we didn't have to worry about column/row boundaries and which orientation the tiles go in, we weren't initially sure about these details (though after processing our first samples, I think we could do finer granularity). Still, maybe the lane/glass grouping is a nice middle ground

[gianmore]

Thank you very much! I share your concern about the coordinate system.
So in fc_1_coordinate_system.csv and fc_2_coordinate_system.csv there are basically 7 swath per lane included since the nomenclature goes from 0 to 6 and not 6 as indicated in the Illumina documentation (nomenclature from 1 to 6). My understanding is that the S4 have 6 swath per lane. @nukappa can you clarify this?