Abbiamo aperto 792 file di vetrini reali e pubblicato ogni risultato

Che cosa dimostra davvero questo benchmark?

Che un file preciso, di uno scanner preciso, alla sua dimensione reale, si apre nella versione distribuita e mostra i pixel sullo schermo. Niente di più e niente di meno. Un elenco dei formati supportati dichiara una capacità; questo la misura. Se la struttura di un produttore mette in difficoltà il decodificatore, quel file compare nella tabella dei fallimenti con il testo dell’errore che vedrebbe un utente, non come una riga mancante.

È un test del produttore — il software l’abbiamo scritto noi e il test l’abbiamo eseguito noi. Ciò che lo rende comunque degno di lettura è che puoi verificarlo: i corpus sono pubblici, lo strumento di esecuzione è nel nostro repository desktop e i risultati grezzi per ogni file sono in questa pagina.

Come sono stati testati i file

Ogni file viene passato a un processo figlio sacrificabile che costruisce lo stesso loader che costruisce l’applicazione, legge le dimensioni dell’immagine, decodifica un piano e lo converte attraverso lo stesso percorso di rendering Qt usato dal visualizzatore. Un file malformato che fa abortire un codec nativo uccide solo quel processo figlio; il supervisore registra quale file era in elaborazione e prosegue. È grazie a questa architettura che un benchmark su scansioni di produttori da diversi gigabyte riesce a terminare, ed è per questo che «crash» è una categoria che questa tabella può onestamente riportare a zero.

• Strumento di esecuzione: slidescope-desktop/scripts/publish_format_benchmark.py — un solo comando, nel repository desktop di SlideScope, che esegue tutti e tre i passaggi e scrive esattamente il JSON visualizzato in questa pagina: python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
• Corpus: il corpus di riferimento pubblico dell’Open Microscopy Environment, i vetrini di test pubblicati da OpenSlide, i dati di test delle librerie czitools e nd2 e campioni dei produttori di cui abbiamo verificato lo sha256 con quello dell’editore.
• Ambito: formati whole slide e formati di microscopia dei produttori. Sono esclusi i TIFF sciolti a piano singolo provenienti da raccolte massive dei produttori — non dicono nulla che un TIFF WSI piramidale non dica meglio.
• Registrato per ogni file: formato rilevato, loader, dimensioni T/Z/C/Y/X decodificate, tipo di pixel, dimensione visualizzata e, in caso di fallimento, il tipo di eccezione e il messaggio mostrato all’utente.

Formati di immagini whole slide

Sono i formati degli scanner — i file che arrivano da uno strumento Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya o Agilent e che arrivano normalmente a diversi gigabyte.

Formati di microscopia e di imaging medico

Formati di acquisizione multidimensionali, in cui la domanda interessante non è la dimensione del file, ma quanti canali, piani Z e punti temporali arrivano intatti fino allo schermo.

Ogni file che non si è aperto, e perché

25 dei 792 file non si sono aperti, e non raccontano una storia sola ma due. 9 sono limiti reali: un’immagine vera che al momento non riusciamo a leggere. Gli altri 16 sono file che non contengono alcuna immagine, per cui rifiutarli è la risposta corretta. Metterli insieme ci farebbe sembrare migliori — il conteggio onesto dei fallimenti di questa esecuzione è 9, non 25.

Limiti reali: 9 file che non riusciamo a leggere

Sono tutti integri — i checksum corrispondono a quelli dell’editore — quindi si tratta di limiti dei decodificatori e delle strutture dei produttori, non di campioni danneggiati. Restano nel corpus in modo permanente come copertura per i test di regressione: è così che ci accorgeremo del giorno in cui uno di loro inizierà a funzionare.

Lo schema dipende dalla struttura del produttore, non dalla modalità. NDPI in fluorescenza e MIRAX in fluorescenza si aprono entrambi normalmente; sono specifiche varianti strutturali — un SCN senza un’immagine principale identificabile, un BIF con un attributo di direzione inatteso, un contenitore "Imaris Classic" precedente a HDF5 — che i backend rifiutano. Ogni messaggio indica la causa invece di definire il file corrotto, perché in ognuno di questi casi il file è a posto e il limite è nostro.

Non sono fallimenti: 16 oggetti che non contengono immagini

Il DICOM è un formato per documenti tanto quanto un formato per immagini. Un DICOMDIR è l’indice di un disco; un presentation state registra come qualcuno ha impostato la finestra di uno studio; altri oggetti contengono referti o misure. Nessuno contiene pixel. Un visualizzatore che li aprisse non avrebbe nulla da mostrare, quindi SlideScope li rifiuta con una spiegazione — il comportamento giusto, conteggiato a parte perché non possa gonfiare nessuna delle due colonne.

Indicati per esteso, così che nulla resti nascosto dietro una categoria: DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183.

Dove SlideScope ha aperto un file e mostrato la cosa sbagliata

Questo è il tipo di fallimento che conta di più, quello che le tabelle dei formati non ammettono mai, quindi ecco il nostro.

Una scansione Akoya .qptiff multiplex — il file di riferimento Vectra a sette colori — si è aperta senza alcun errore. Il file contiene cinque pagine di fluorescenza a canale singolo a piena risoluzione (DAPI, FITC, CY3, Texas Red, CY5) di 34.560 × 24.960 su 33 pagine, come confermato in modo indipendente con tifffile. SlideScope indirizzava ogni .qptiff al suo backend OpenSlide, che è un lettore per campo chiaro, quindi riportava un solo canale e restituiva una sezione RGB. I canali di fluorescenza erano irraggiungibili e i controlli dei canali non avevano nulla da offrire.

Nulla ti avvisava. Le scansioni QPTIFF in campo chiaro con colorazione H&E dello stesso corpus si aprono perfettamente, ed è proprio per questo che il problema è passato inosservato.

Risolto in SlideScope 1.8.48 (18 settembre 2026): ora il backend viene scelto per ogni file, non per estensione. Una scansione multiplex va a un lettore che restituisce tutti e cinque i canali; i QPTIFF in campo chiaro restano su OpenSlide, con la sua suddivisione in tessere a piena risoluzione. Il compromesso viene dichiarato, non nascosto: un QPTIFF multiplex viene mostrato a risoluzione ridotta e il pannello dei dettagli del file lo indica. L’esecuzione in questa pagina riflette già la correzione — la riga QPTIFF elenca entrambi i loader e cinque canali.

Questa esecuzione dimostra l’apertura. La correttezza dei pixel è una questione separata, e la testiamo separatamente: un secondo passaggio decodifica gli stessi piani tramite la libreria sottostante e li confronta con ciò che restituisce il loader. È così che è stato individuato il caso QPTIFF.

Che cosa SlideScope si rifiuta di aprire

Non esiste un lettore generico di ripiego, e il modo in cui un visualizzatore gestisce un file per cui non è stato pensato conta quanto i file per cui lo è. Abbiamo preso il file reale più piccolo di ogni estensione non supportata nel corpus di riferimento — 93 in tutto — e li abbiamo passati uno per uno attraverso la factory dei loader della versione distribuita.

93 su 93 sono stati rifiutati con un messaggio chiaro. Nessuno ha causato un crash. Nessuno è stato aperto a metà, trasformandosi in qualcosa che sembrava un’immagine ma non lo era. L’elenco comprende formati che è plausibile provare ad aprire — .jpg, .lof, .nii, .oib, .oir, .png, .psd, .raw, .vsi — e al momento di questa esecuzione includeva .png e .jpg, che sono stati rifiutati con un messaggio invece di essere interpretati a caso.

Dopo questa esecuzione: SlideScope 1.10.0 (16 ottobre 2026) apre altri 18 formati, tra cui diversi rifiutati qui: Olympus .vsi, .oib e .oir, Leica .lof e .xlef, Hamamatsu .ndpis, e PNG, JPEG e altre immagini di uso comune. I numeri in questa pagina sono quelli dell’esecuzione del 18 settembre così come misurati; i formati aggiunti nella 1.10.0 non ne facevano parte. SlideScope 1.20.0 apre altri cinque formati che questa esecuzione non ha testato: Philips .isyntax, KFBio .kfb, ICS/IDS, Gatan .dm3 e .dm4, e Olympus .sis. Consulta il riferimento sulla compatibilità dei file per l’elenco aggiornato.

Che cosa questo benchmark non ti dice

• Due formati non hanno alcuna copertura con file reali. Non esiste un campione pubblico .vmu o .svslide — OpenSlide non ne pubblica nessuno dei due — quindi quei loader vengono verificati solo con casi limite sintetici. Non dichiariamo un supporto testato per questi formati.
• Non è un benchmark di velocità. Il tempo fino al primo pixel dipende dal tuo disco, e queste esecuzioni erano in locale.
• Non è una verifica di accuratezza al di là del passaggio di confronto dei pixel descritto sopra, e non è una validazione clinica. SlideScope è destinato a ricerca, didattica e revisione — non alla diagnosi.
• È un’istantanea. Datata 2026-09-18, sulla versione disponibile quel giorno. Gli aggiornamenti dei decodificatori spostano questi numeri in entrambe le direzioni.