Abrimos 792 archivos de láminas reales y publicamos todos los resultados

¿Qué demuestra realmente este benchmark?

Que un archivo concreto, de un escáner concreto, con su tamaño real, se abre en la versión publicada y muestra píxeles en pantalla. Ni más ni menos. Una lista de formatos compatibles declara una capacidad; esto la mide. Si la estructura de un fabricante supera al decodificador, ese archivo aparece en la tabla de fallos con el texto de error que vería un usuario, no como una fila que falta.

Es una prueba hecha por el fabricante: nosotros escribimos el software y nosotros hicimos la prueba. Lo que hace que valga la pena leerla de todos modos es que puedes verificarla: los corpus son públicos, el ejecutor está en nuestro repositorio de escritorio y los resultados brutos por archivo están en esta página.

Cómo se probaron los archivos

Cada archivo se entrega a un proceso hijo desechable que construye el mismo cargador que construye la aplicación, lee las dimensiones de la imagen, decodifica un plano y lo convierte por la misma ruta de renderizado de Qt que usa el visor. Un archivo dañado que hace abortar un códec nativo solo mata a ese proceso hijo; el supervisor registra qué archivo se estaba procesando y continúa. Gracias a ese diseño, un benchmark sobre escaneos de fabricantes de varios gigabytes puede llegar a terminar, y por eso "bloqueado" es una categoría que esta tabla puede informar honestamente como cero.

• Ejecutor: slidescope-desktop/scripts/publish_format_benchmark.py: un solo comando, en el repositorio de escritorio de SlideScope, que ejecuta las tres pasadas y escribe exactamente el JSON que muestra esta página: python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
• Corpus: el corpus público de referencia de Open Microscopy Environment, las láminas de prueba publicadas por OpenSlide, los datos de prueba de las bibliotecas czitools y nd2, y muestras de fabricantes cuyo sha256 verificamos con el editor.
• Alcance: formatos de lámina completa y formatos de microscopía de fabricantes. Se excluyen los TIFF sueltos de un solo plano procedentes de volcados masivos de fabricantes: no aportan nada que un TIFF WSI piramidal no muestre mejor.
• Registrado por archivo: formato detectado, cargador, dimensiones T/Z/C/Y/X decodificadas, tipo de píxel, tamaño renderizado y, en caso de fallo, el tipo de excepción y el mensaje que ve el usuario.

Formatos de imagen de lámina completa

Estos son los formatos de escáner: los archivos que llegan de un instrumento de Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya o Agilent y que suelen ocupar varios gigabytes.

Formatos de microscopía y de imágenes médicas

Formatos de adquisición multidimensional, donde la pregunta interesante no es el tamaño del archivo, sino cuántos canales, planos Z y puntos de tiempo llegan intactos a la pantalla.

Cada archivo que no se abrió, y por qué

25 de los 792 archivos no se abrieron, y no son una sola historia, sino dos. 9 son limitaciones reales: una imagen auténtica que actualmente no podemos leer. Los otros 16 son archivos que de entrada no contienen ninguna imagen, y rechazarlos es la respuesta correcta. Meter los dos grupos en el mismo saco nos favorecería: el número honesto de fallos en esta ejecución es 9, no 25.

Limitaciones reales: 9 archivos que no podemos leer

Todos están intactos (las sumas de verificación coinciden con las del editor), así que son límites del decodificador y de la estructura del fabricante, no muestras dañadas. Se quedan en el corpus de forma permanente como cobertura de regresión, y así nos enteramos el día en que uno de ellos empiece a funcionar.

El patrón es la estructura del fabricante, no la modalidad. Los NDPI de fluorescencia y los MIRAX de fluorescencia se abren con normalidad; son variantes estructurales específicas (un SCN sin una imagen principal identificable, un BIF con un atributo de dirección inesperado, un contenedor "Imaris Classic" anterior a HDF5) las que los backends rechazan. Cada mensaje nombra la causa en lugar de decir que el archivo está dañado, porque en todos estos casos el archivo está bien y el problema es nuestro.

No son fallos: 16 objetos que no contienen imagen

DICOM es tanto un formato de documentos como un formato de imagen. Un DICOMDIR es el índice de un disco; un estado de presentación registra cómo alguien ajustó alguna vez la ventana de un estudio; otros objetos contienen informes o mediciones. Ninguno contiene píxeles. Un visor que los abriera no tendría nada que mostrar, así que SlideScope los rechaza con una explicación: el comportamiento correcto, contado por separado para que no infle ninguna de las dos columnas.

Nombrados en su totalidad para que nada quede oculto detrás de una categoría: DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183.

Donde SlideScope abrió un archivo y mostró lo que no era

Este es el tipo de fallo que más importa y el que las tablas de formatos nunca admiten, así que aquí está el nuestro.

Un escaneo multiplex de Akoya .qptiff (el archivo de referencia Vectra de siete colores) se abrió sin ningún error. El archivo contiene cinco páginas de fluorescencia de un solo canal a resolución completa (DAPI, FITC, CY3, Texas Red, CY5) de 34,560 × 24,960 en 33 páginas, lo que se confirmó de forma independiente con tifffile. SlideScope enviaba todos los .qptiff a su backend OpenSlide, que es un lector de campo claro, así que informaba un solo canal y devolvía un corte RGB. Los canales de fluorescencia quedaban inaccesibles y los controles de canales no tenían nada que ofrecer.

Nada te avisaba. Los escaneos QPTIFF de H&E de campo claro del mismo corpus se abren perfectamente, y justamente por eso esto pasó desapercibido.

Corregido en SlideScope 1.8.48 (18 de septiembre de 2026): ahora el backend se elige por archivo, no por extensión. Un escaneo multiplex va a un lector que devuelve los cinco canales; los QPTIFF de campo claro siguen usando OpenSlide y su teselado a resolución completa. La contrapartida se indica en lugar de ocultarse: un QPTIFF multiplex se muestra a resolución reducida, y el panel de detalles del archivo lo dice. La ejecución de esta página ya refleja la corrección: la fila de QPTIFF muestra ambos cargadores y cinco canales.

Esta ejecución demuestra la apertura. La exactitud de los píxeles es otra cuestión, y la probamos por separado: una segunda pasada decodifica los mismos planos con la biblioteca subyacente y los compara con lo que devuelve el cargador. Así se detectó el caso del QPTIFF.

Lo que SlideScope se niega a abrir

No hay un lector genérico de respaldo, y cómo maneja un visor un archivo para el que nunca fue diseñado importa tanto como los archivos para los que sí lo fue. Tomamos el archivo real más pequeño de cada extensión no compatible del corpus de referencia (93 en total) y pasamos cada uno por la fábrica de cargadores de la versión publicada.

Los 93 fueron rechazados con un mensaje claro. Ninguno se bloqueó. Ninguno se abrió a medias como algo que parecía una imagen pero no lo era. La lista incluye formatos que la gente probablemente intente abrir (.jpg, .lof, .nii, .oib, .oir, .png, .psd, .raw, .vsi); en el momento de esta ejecución eso incluía .png y .jpg, que se rechazaron con un mensaje en lugar de intentar adivinarlos.

Desde esta ejecución: SlideScope 1.10.0 (16 de octubre de 2026) abre 18 formatos más, entre ellos varios que aquí se rechazaron: Olympus .vsi, .oib y .oir, Leica .lof y .xlef, Hamamatsu .ndpis, y PNG, JPEG y otras imágenes comunes. Los números de esta página corresponden a la ejecución del 18 de septiembre tal como se midió; los formatos añadidos en 1.10.0 no formaron parte de ella. SlideScope 1.20.0 abre cinco más que esta ejecución no probó: Philips .isyntax, KFBio .kfb, ICS/IDS, Gatan .dm3 y .dm4, y Olympus .sis. Consulta la referencia de compatibilidad de archivos para ver la lista actual.

Lo que este benchmark no te dice

• Dos formatos no tienen ninguna cobertura con archivos reales. No existe ninguna muestra pública de .vmu ni de .svslide (OpenSlide no publica ninguna de las dos), así que esos cargadores solo se ponen a prueba con casos límite sintéticos. No afirmamos que su compatibilidad esté probada.
• No es un benchmark de velocidad. El tiempo hasta el primer píxel depende de tu disco, y estas ejecuciones fueron locales.
• No es una auditoría de exactitud más allá de la pasada de comparación de píxeles descrita arriba, y no es una validación clínica. SlideScope es para investigación, educación y revisión, no para diagnóstico.
• Es una instantánea. Con fecha 2026-09-18, sobre la versión vigente ese día. Las mejoras de los decodificadores mueven estos números en ambas direcciones.