¿Qué demuestra realmente este benchmark?
Que un archivo concreto, de un escáner concreto, a 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 del propio fabricante: escribimos el software y nosotros mismos hicimos la prueba. Lo que hace que merezca la pena leerla de todos modos es que puedes comprobarla: los corpus son públicos, el script de ejecución 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 mal formado que hace abortar un códec nativo solo mata a ese proceso hijo; el supervisor registra qué archivo se estaba procesando y continúa. Ese diseño es la razón por la que un benchmark sobre escaneos de fabricantes de varios gigabytes puede llegar a terminar, y por la que "bloqueado" es una categoría que esta tabla puede indicar honestamente como cero.
- Script de ejecución:
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 de referencia público de Open Microscopy Environment, los portaobjetos de prueba publicados por OpenSlide, los datos de prueba de las bibliotecas
czitools y nd2, y muestras de fabricantes cuyo sha256 verificamos con el del editor.
- Alcance: formatos de portaobjetos completos y formatos de microscopía de fabricantes. Se excluyen los TIFF sueltos de un solo plano procedentes de volcados masivos de fabricantes: no dicen nada que un TIFF WSI piramidal no diga 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 portaobjetos completos
Estos son los formatos de escáner: los archivos que llegan de un instrumento Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya o Agilent y que suelen ocupar varios gigabytes.
Formatos de microscopía y de imagen médica
Formatos de adquisición multidimensional, en los que la cuestión interesante no es el tamaño del archivo, sino cuántos canales, planos Z y puntos temporales llegan intactos a la pantalla.
Todos los archivos que no se abrieron, y por qué
25 de los 792 archivos no se abrieron, y no es una sola historia sino dos. 9 son limitaciones reales: una imagen auténtica que ahora mismo no podemos leer. Los otros 16 son archivos que de entrada no contienen ninguna imagen, y en ellos rechazarlos es la respuesta correcta. Meterlos a todos en el mismo saco nos favorecería: el recuento honesto de fallos de esta ejecución es 9, no 25.
Limitaciones reales: 9 archivos que no podemos leer
Todos están intactos —las sumas de comprobación coinciden con las del editor—, así que se trata de límites del decodificador y de la estructura del fabricante, no de muestras dañadas. Se quedan en el corpus de forma permanente como cobertura de regresión, y así sabremos el día en que alguno empiece a funcionar.
El patrón es la estructura del fabricante, no la modalidad. NDPI de fluorescencia y MIRAX de fluorescencia se abren con normalidad; lo que los backends rechazan son variantes estructurales concretas: un SCN sin una imagen principal identificable, un BIF con un atributo de dirección inesperado, un contenedor "Imaris Classic" anterior a HDF5. 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 somos nosotros los que fallamos.
No son fallos: 16 objetos que no contienen ninguna imagen
DICOM es tanto un formato de documentos como un formato de imagen. Un DICOMDIR es el índice de un disco; un presentation state registra cómo alguien ajustó en su día 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: es el comportamiento correcto, y se cuentan aparte para que no inflen ninguna de las dos columnas.
Se nombran todos para que nada quede oculto tras una categoría: DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183.
Dónde SlideScope abrió un archivo y mostró algo equivocado
Este es el tipo de fallo que más importa y el que las tablas de formatos nunca reconocen, así que aquí está el nuestro.
Un escaneo Akoya .qptiff multiplex —el archivo de referencia de siete colores de Vectra— 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, algo confirmado de forma independiente con tifffile. SlideScope enviaba todos los .qptiff a su backend OpenSlide, que es un lector de campo claro, así que indicaba un solo canal y devolvía un corte RGB. Los canales de fluorescencia eran inaccesibles y los controles de canal no tenían nada que ofrecer.
Nada te avisaba. Los escaneos QPTIFF de campo claro con H&E del mismo corpus se abren perfectamente, y precisamente por eso 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; el QPTIFF de campo claro sigue con OpenSlide y su teselado a resolución completa. La contrapartida se explica en lugar de ocultarse: un QPTIFF multiplex se muestra a resolución reducida, y el panel de detalles del archivo lo indica. 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 reserva, y cómo trata un visor un archivo para el que nunca se diseñó importa tanto como los archivos para los que sí. 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 se rechazaron con un mensaje claro. Ninguno provocó un bloqueo. Ninguno se abrió a medias como algo que parecía una imagen sin serlo. 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 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 cotidianas. Las cifras de esta página corresponden a la ejecución del 18 de septiembre tal como se midió; los formatos añadidos en la versión 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 ejercitan 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, formación y revisión, no para diagnóstico.
- Es una instantánea. Fechada el 2026-09-18 con la versión vigente ese día. Las mejoras de los decodificadores mueven estas cifras en ambos sentidos.
Preguntas sobre este benchmark
¿Qué formatos de microscopía y de portaobjetos completos abre realmente SlideScope?
Dieciocho extensiones de archivo: .svs, .ndpi, .mrxs, .scn, .bif, .vms, .vmu, .svslide, .qptiff, .avs, .czi, .nd2, .lif, .ims, .dcm, .dicom, .tif y .tiff. No hay un lector genérico de reserva: todo lo que queda fuera de esa lista se rechaza con un mensaje claro en lugar de abrirse mal.
¿Es independiente este benchmark?
No. Lo publica SlideScope sobre SlideScope, así que tómalo como una prueba del propio fabricante, no como una auditoría de terceros. Lo que podemos ofrecer en lugar de independencia es que todo se puede comprobar: los corpus son públicos, el script de ejecución está en nuestro directorio de scripts abierto, el archivo de resultados brutos está enlazado en esta página y los fallos se detallan igual que los éxitos.
¿Por qué fallan algunos archivos?
Casi siempre porque un fabricante escribió una estructura que el backend de código abierto subyacente no puede leer; por ejemplo, OpenSlide indica "Can't find main image" con un SCN de fluorescencia. Son limitaciones de origen que mostramos en lugar de ocultarlas. Los archivos que fallan están intactos: sus sumas de comprobación coinciden con las del editor.
¿Que un archivo se abra significa que la imagen es correcta?
No por sí solo, y por eso probamos ambas cosas. Esta ejecución demuestra la apertura; la exactitud de los píxeles se demuestra por separado con sweep_format_reference.py, que decodifica los mismos planos con la biblioteca subyacente y los compara con lo que renderiza SlideScope. Un caso conocido —un Akoya QPTIFF multiplex— se abrió sin error y aun así mostraba algo equivocado hasta que SlideScope 1.8.48 lo corrigió. Está documentado en esta página.
¿Puedo reproducirlo?
Sí. El corpus de referencia de Open Microscopy Environment se puede descargar públicamente, las muestras de fabricantes proceden de OpenSlide y de los datos de prueba de las propias bibliotecas de formatos, y el script de ejecución se incluye en el repositorio de escritorio de SlideScope. El JSON bruto de todas las tablas de esta página está enlazado más arriba.
¿Está SlideScope aprobado para el diagnóstico clínico?
No. SlideScope es para investigación, formación y revisión. No es un dispositivo de diagnóstico y no debe usarse para hacer un diagnóstico primario.
La única prueba que cuenta es la tuya
Nuestro corpus no es tu cajón de portaobjetos. Instala SlideScope, abre los archivos que de verdad te dan problemas y, si alguno falla, envíanoslo: los fallos de esta página llegaron aquí porque alguien lo hizo.
Descargar SlideScope