Skip to content

Treat the Owkin PLISM derivative as a correspondence benchmark, not a provenance bridge #39

Description

@matthewvaishnav

Corrected scientific finding

The public owkin/plism-dataset-tiles derivative is valuable for registered cross-domain correspondence, but its slide_id must not be described as a biological-provenance bridge.

The dataset card states that:

  • the 91 original PLISM WSIs were re-registered with Elastix to the GMH-stained Hamamatsu NanoZoomer S60 reference;
  • every registered WSI contributes 16,278 tiles at 0.5 µm/pixel;
  • the feature matrices use the same tile order across slides, so matching row/tile positions represent the same registered location;
  • slide_id names the original registered WSI/domain (for example, values of the form GIVH_AT2_to_GMH_S60), while tile_id encodes the derivative tile location.

Because PLISM contains 13 serial-section staining conditions scanned on seven devices, the 91 slide_id values correspond to the stain × scanner WSI crossing. They do not identify patient, specimen, block, TMA core, or an independent biological parent. The name slide_id is therefore provenance-bearing only at the WSI/domain level, not at the level required for leakage-safe biological train/test splitting.

What the derivative legitimately enables

Use this release as a separate PLISM-Owkin correspondence benchmark:

  1. compare scanner domains within a fixed staining condition using aligned tile_id positions;
  2. compare stain/section domains only with the explicit caveat that staining condition is aliased with physical serial section;
  3. estimate representation drift, retrieval consistency, paired distances, rank stability, and scanner robustness on matched registered locations;
  4. preserve the distinction between the original PLISM registration pipeline and Owkin's Elastix re-registration/extraction pipeline;
  5. report uncertainty by registered location and domain, without calling the folds patient- or specimen-independent.

High-value replication question

Are encoder robustness rankings stable across the original PLISM registered-tile release and the Owkin Elastix derivative?

A rank reversal would be scientifically informative: it would show that apparent scanner robustness depends materially on registration, interpolation, tissue masking, or tile extraction rather than only on scanner domain.

Required validation and audit

  • Enumerate all 91 slide_id values and verify one-to-one coverage of the 13 stain × 7 scanner WSI crossing.
  • Parse each slide_id into source stain, source scanner, registration reference, and WSI/domain identity.
  • Verify exactly 16,278 unique tile_id values per slide_id.
  • Confirm that every corresponding matrix row / tile_id denotes the same registered location across all 91 WSIs.
  • Check missing and duplicated (slide_id, tile_id, stainer, scanner) tuples.
  • Record dataset revision, license, file hashes, registration software/reference, interpolation details when available, extraction MPP, and tissue-mask procedure.
  • Keep original-PLISM and Owkin-derived manifests and result tables separate.
  • Do not use slide_id for patient/specimen-independent splitting unless a separate verified biological-parent mapping is obtained.

Claim boundary

This derivative supplies a strong domain and registered-location key, not a patient/specimen provenance key. It can support paired scanner/stain robustness experiments, but it cannot by itself support independent biological generalization claims or leakage-safe predictive-model partitions.

Primary public evidence

  • Ochi et al., Scientific Data 11, 330 (2024), DOI: 10.1038/s41597-024-03122-5.
  • owkin/plism-dataset-tiles dataset card and schema: 1,481,298 images, 91 registered WSIs, 16,278 tiles per WSI, explicit slide_id and tile_id, common tile ordering across slides.
  • Filiot et al., Distilling foundation models for robust and efficient models in digital pathology, arXiv:2501.16239 (2025).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions