Nous avons ouvert 792 vrais fichiers de lames et publié chaque résultat

Que prouve réellement ce banc d’essai ?

Qu’un fichier nommé, issu d’un scanner nommé, à sa taille réelle, s’ouvre dans la version publiée et affiche des pixels à l’écran. Ni plus, ni moins. Une liste de formats pris en charge revendique une capacité ; ceci la mesure. Si une structure propre à un fabricant met le décodeur en échec, le fichier figure dans le tableau des échecs avec le texte d’erreur qu’un utilisateur verrait, et non comme une ligne manquante.

C’est un test réalisé par l’éditeur — nous avons écrit le logiciel et nous avons mené le test. Ce qui le rend malgré tout digne d’intérêt, c’est que vous pouvez le vérifier : les corpus sont publics, le script d’exécution se trouve dans notre dépôt desktop, et les résultats bruts fichier par fichier sont sur cette page.

Comment les fichiers ont été testés

Chaque fichier est confié à un processus enfant sacrifiable qui construit le même chargeur que l’application, lit les dimensions de l’image, décode un plan et le convertit par le même chemin de rendu Qt que la visionneuse. Un fichier malformé qui fait planter un codec natif ne tue que ce processus enfant ; le superviseur enregistre quel fichier était en cours et poursuit. C’est grâce à cette conception qu’un banc d’essai portant sur des numérisations de plusieurs gigaoctets peut aller jusqu’au bout, et c’est pourquoi « plantage » est une catégorie que ce tableau peut honnêtement afficher à zéro.

• Script d’exécution : slidescope-desktop/scripts/publish_format_benchmark.py — une seule commande, dans le dépôt desktop de SlideScope, qui exécute les trois passes et écrit exactement le JSON affiché par cette page : python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
• Corpus : le corpus de référence public de l’Open Microscopy Environment, les lames de test publiées par OpenSlide, les données de test des bibliothèques czitools et nd2, et des échantillons de fabricants dont nous avons vérifié le sha256 auprès de l’éditeur.
• Périmètre : formats de lames entières et formats de microscopie des fabricants. Les TIFF isolés à un seul plan issus d’exports en masse de fabricants sont exclus — ils n’apprennent rien qu’un TIFF WSI pyramidal n’apprenne mieux.
• Enregistré pour chaque fichier : format détecté, chargeur, dimensions T/Z/C/Y/X décodées, type de pixel, taille affichée et, en cas d’échec, le type d’exception et le message présenté à l’utilisateur.

Formats d’images de lames entières

Ce sont les formats de scanners — les fichiers qui proviennent d’un instrument Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya ou Agilent et atteignent couramment plusieurs gigaoctets.

Formats de microscopie et d’imagerie médicale

Des formats d’acquisition multidimensionnels, pour lesquels la question intéressante n’est pas la taille du fichier mais combien de canaux, de plans Z et de points temporels arrivent intacts jusqu’à l’écran.

Chaque fichier qui ne s’est pas ouvert, et pourquoi

25 des 792 fichiers ne se sont pas ouverts, et ils ne racontent pas une histoire mais deux. 9 sont de vraies limites : une véritable image que nous ne savons pas lire actuellement. Les 16 autres sont des fichiers qui ne contiennent aucune image au départ, et pour lesquels le refus est la bonne réponse. Les mettre dans le même sac nous flatterait — le nombre honnête d’échecs pour ce test est de 9, pas de 25.

Vraies limites : 9 fichiers que nous ne savons pas lire

Tous ces fichiers sont intacts — les sommes de contrôle correspondent à celles de l’éditeur — il s’agit donc de limites du décodeur et de la structure propre au fabricant, pas d’échantillons endommagés. Ils restent définitivement dans le corpus comme tests de non-régression : c’est ainsi que nous saurons le jour où l’un d’eux commencera à fonctionner.

Ce qui compte, c’est la structure propre au fabricant, pas la modalité. Les NDPI et les MIRAX de fluorescence s’ouvrent normalement ; ce sont des variantes structurelles précises — un SCN sans image principale identifiable, un BIF avec un attribut de direction inattendu, un conteneur "Imaris Classic" antérieur à HDF5 — que les moteurs refusent. Chaque message nomme la cause au lieu de déclarer le fichier corrompu, car dans chacun de ces cas c’est le fichier qui est correct, et nous qui ne le sommes pas.

Pas des échecs : 16 objets qui ne contiennent aucune image

Le DICOM est autant un format de documents qu’un format d’images. Un DICOMDIR est l’index d’un disque ; un état de présentation enregistre la façon dont quelqu’un a un jour fenêtré une étude ; d’autres objets contiennent des comptes rendus ou des mesures. Aucun ne contient de pixels. Une visionneuse qui les ouvrirait n’aurait rien à afficher : SlideScope les refuse donc avec une explication — le bon comportement, comptabilisé à part pour ne gonfler aucune des deux colonnes.

Nommés en entier pour que rien ne se cache derrière une catégorie : DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183.

Quand SlideScope a ouvert un fichier et affiché la mauvaise chose

C’est le mode d’échec qui compte le plus, celui que les tableaux de formats n’avouent jamais ; voici donc le nôtre.

Une numérisation multiplex Akoya .qptiff — le fichier de référence Vectra à sept couleurs — s’est ouverte sans la moindre erreur. Le fichier contient cinq pages de fluorescence monocanal en pleine résolution (DAPI, FITC, CY3, Texas Red, CY5) de 34 560 × 24 960 sur 33 pages, ce que nous avons confirmé indépendamment avec tifffile. SlideScope orientait tous les .qptiff vers son moteur OpenSlide, qui est un lecteur fond clair : il annonçait donc un seul canal et renvoyait une coupe RVB. Les canaux de fluorescence étaient inaccessibles et les commandes de canaux n’avaient rien à proposer.

Rien ne vous avertissait. Les numérisations QPTIFF H&E en fond clair du même corpus s’ouvrent parfaitement, et c’est précisément pour cela que le problème est passé inaperçu.

Corrigé dans SlideScope 1.8.48 (18 septembre 2026) : le moteur est désormais choisi par fichier, et non par extension. Une numérisation multiplex est confiée à un lecteur qui renvoie les cinq canaux ; le QPTIFF en fond clair conserve OpenSlide et son tuilage en pleine résolution. La contrepartie est annoncée plutôt que cachée : un QPTIFF multiplex est affiché à résolution réduite, et le panneau des détails du fichier l’indique. Le test présenté sur cette page intègre déjà la correction — la ligne QPTIFF mentionne les deux chargeurs et cinq canaux.

L’ouverture est prouvée par ce test. L’exactitude des pixels est une autre question, que nous testons séparément : une seconde passe décode les mêmes plans via la bibliothèque sous-jacente et les compare à ce que renvoie le chargeur. C’est ainsi que le cas QPTIFF a été détecté.

Ce que SlideScope refuse d’ouvrir

Il n’y a pas de lecteur générique de secours, et la façon dont une visionneuse gère un fichier pour lequel elle n’a jamais été conçue compte autant que les fichiers pour lesquels elle l’a été. Nous avons pris le plus petit vrai fichier de chaque extension non prise en charge du corpus de référence — 93 au total — et l’avons passé dans la fabrique de chargeurs de la version publiée.

Les 93 ont tous été refusés avec un message clair. Aucun n’a provoqué de plantage. Aucun n’a été à moitié ouvert en quelque chose qui ressemblait à une image sans en être une. La liste comprend des formats que l’on peut vraisemblablement essayer — .jpg, .lof, .nii, .oib, .oir, .png, .psd, .raw, .vsi — ; au moment de ce test, elle incluait .png et .jpg, qui ont été refusés avec un message plutôt que devinés.

Depuis ce test : SlideScope 1.10.0 (16 octobre 2026) ouvre 18 formats de plus, dont plusieurs refusés ici : Olympus .vsi, .oib et .oir, Leica .lof et .xlef, Hamamatsu .ndpis, ainsi que PNG, JPEG et d’autres images courantes. Les chiffres de cette page sont ceux du test du 18 septembre, tels que mesurés ; les formats ajoutés dans la version 1.10.0 n’en faisaient pas partie. SlideScope 1.20.0 ouvre cinq formats supplémentaires que ce test n’a pas couverts : Philips .isyntax, KFBio .kfb, ICS/IDS, Gatan .dm3 et .dm4, et Olympus .sis. Consultez la référence de compatibilité des fichiers pour la liste actuelle.

Ce que ce banc d’essai ne vous dit pas

• Deux formats n’ont aucune couverture par de vrais fichiers. Il n’existe aucun échantillon public .vmu ou .svslide — OpenSlide n’en publie aucun — ces chargeurs ne sont donc éprouvés que par des cas limites synthétiques. Nous ne revendiquons pas de prise en charge testée pour eux.
• Ce n’est pas un banc d’essai de vitesse. Le délai d’affichage du premier pixel dépend de votre disque, et ces tests ont été exécutés en local.
• Ce n’est pas un audit d’exactitude au-delà de la passe de comparaison des pixels décrite plus haut, et ce n’est pas une validation clinique. SlideScope est destiné à la recherche, à l’enseignement et à l’examen — pas au diagnostic.
• C’est un instantané. Daté du 2026-09-18, sur la version en vigueur ce jour-là. Les mises à jour des décodeurs font évoluer ces chiffres dans les deux sens.