`b2c.destripe()` worsens row/column-related technical effect

[Nick-Eagles]

Hello,

Thanks for developing this extraordinarily useful software. In some Visium HD data I'm working with, I've also observed the technical effect where certain array rows or columns have smaller/larger total raw counts than others. However, I've found that b2c.destripe() actually exaggerates the problem. The data is private, so while I can't provide a reproducible example, I'll provide the chunk of relevant code, then show screenshots of the resulting plots, where the only difference between the two is whether b2c.destripe(adata_filtered) was run. I read in the raw data from Spaceranger, apply the recommended filtering steps seen in the tutorial, apply b2c.destripe in one case, then add up total UMI counts for each bin. For display, I cap totals at 5 UMI, which helps the color range in the plots.

adata_filtered = b2c.read_visium(
    sr_dir,
    count_file = 'filtered_feature_bc_matrix.h5',
    source_image_path = raw_image_path,
    spaceranger_image_path = sr_spatial_dir
)

b2c.scaled_he_image(
    adata_filtered,
    mpp = mpp,
    save_path = 'temp.tiff'
)

#   Apply recommended filtering steps following tutorial
sc.pp.filter_cells(adata_filtered, min_counts=1)
sc.pp.filter_genes(adata_filtered, min_cells=3)

#   In one of the two cases, this is run
b2c.destripe(adata_filtered)

#   Add up counts for all genes in each bin. Set a hard maximum threshold to
#   eliminate outliers that throw off the color scale in plots
adata_filtered.obs['sum_umi'] = adata_filtered.X.sum(axis = 1)
adata_filtered.obs['capped_umi'] = np.clip(adata_filtered.obs['sum_umi'], 0, 5)

#   Take a small subset in the top-right corner of the data
scale_factor = 0.3
mask = ( 
    (adata_filtered.obs['array_row'] >= (1 - scale_factor) * adata_filtered.obs['array_row'].max()) & 
    (adata_filtered.obs['array_col'] >= (1 - scale_factor) * adata_filtered.obs['array_col'].max())
)
adata_small = adata_filtered[mask, :]

sc.pl.spatial(
    adata_small, color="capped_umi", img_key=f"{mpp}_mpp_150_buffer",
    basis="spatial_cropped_150_buffer"
)

This particular sample is quite low in total UMI in general (with a median around 2 counts per 2um bin after destriping). Is the high sparsity maybe throwing off the destripe algorithm?

Without destripe:

With destripe:

Best,
-Nick

[AtlasMaroc]

@Nick-Eagles any update ?

[Nick-Eagles]

@Nick-Eagles any update ?

Maybe you meant to tag the authors, but this issue is still open and a problem I've seen in multiple datasets.

[ktpolanski]

There is a note in the demo notebook in line with our current take on destriping - in local testing, it seems to be useful for GEX segmentation at the very least. If it does end up introducing some false positives, those can be easily QC'd out when working on the cell level object. Clipping the plots to 5 UMI max is quite different to the triple digit dynamic range shown in the demo notebook.

Does your GEX segmentation improve when you do it on unadjusted count totals? Another thing you can try is something I was fond of conceptually in development, namely foregoing the destriping and trying to make the grid_image() with log1p=True. It performed worse locally, but maybe it will be superior in your case?

[Nick-Eagles]

Yeah, it might be the much greater sparsity in my data causing issues. Indeed, GEX segmentation improves with unadjusted counts-- actually, I only came to noticing and reporting this issue because of a grid-like pattern in cell positions which I later found to be mediated by the GEX segmentations (when I first adjusted with b2c.destripe()). Interesting tip regarding the log1p=True-- I'll keep that in mind, thanks.

[ktpolanski]

Huh, that's good to know, thanks for the heads up. Keep me posted if you end up trying the log1p.