Abrimos 792 ficheiros reais de lâminas e publicámos todos os resultados

O que prova realmente este benchmark?

Que um ficheiro identificado, de um digitalizador identificado, no seu tamanho real, abre na versão publicada e mostra píxeis no ecrã. Nem mais, nem menos. Uma lista de formatos suportados afirma uma capacidade; isto mede-a. Se a estrutura de um fabricante derrotar o descodificador, esse ficheiro aparece na tabela de falhas com o texto de erro que um utilizador veria, e não como uma linha em falta.

É um teste do próprio fabricante: fomos nós que escrevemos o software e fomos nós que fizemos o teste. O que o torna digno de leitura mesmo assim é que o pode verificar: os corpora são públicos, o script de execução está no nosso repositório da aplicação para computador e os resultados em bruto, ficheiro a ficheiro, estão nesta página.

Como os ficheiros foram testados

Cada ficheiro é entregue a um processo filho sacrificável que constrói o mesmo carregador que a aplicação constrói, lê as dimensões da imagem, descodifica um plano e converte-o pelo mesmo caminho de apresentação Qt que o visualizador usa. Um ficheiro malformado que faça abortar um codec nativo só mata esse processo filho; o supervisor regista que ficheiro estava a ser processado e continua. É graças a esta conceção que um benchmark sobre digitalizações de fabricantes com vários gigabytes consegue chegar ao fim, e é por isso que esta tabela pode indicar honestamente zero na categoria «falha fatal».

• Script de execução: slidescope-desktop/scripts/publish_format_benchmark.py: um único comando, no repositório da aplicação SlideScope para computador, que executa as três passagens e grava exatamente o JSON que esta página apresenta: python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
• Corpora: o corpus público de referência do Open Microscopy Environment, as lâminas de teste publicadas pelo OpenSlide, os dados de teste das bibliotecas czitools e nd2, e amostras de fabricantes cujo sha256 verificámos junto do editor.
• Âmbito: formatos de lâmina inteira e de microscopia de fabricantes. Os TIFF soltos de plano único provenientes de exportações em massa de fabricantes ficam excluídos: não dizem nada que um TIFF WSI piramidal não diga melhor.
• Registado por ficheiro: formato detetado, carregador, dimensões T/Z/C/Y/X descodificadas, tipo de píxel, tamanho apresentado e, em caso de falha, o tipo de exceção e a mensagem mostrada ao utilizador.

Formatos de imagem de lâmina inteira

Estes são os formatos dos digitalizadores: os ficheiros que chegam de um instrumento Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya ou Agilent e que chegam habitualmente a vários gigabytes.

Formatos de microscopia e de imagiologia médica

Formatos de aquisição multidimensionais, em que a questão interessante não é o tamanho do ficheiro, mas quantos canais, planos Z e pontos temporais chegam intactos ao ecrã.

Todos os ficheiros que não abriram, e porquê

25 dos 792 ficheiros não abriram, e não se trata de uma história, mas de duas. 9 são limitações reais: uma imagem genuína que atualmente não conseguimos ler. Os outros 16 são ficheiros que, à partida, não contêm qualquer imagem, e em que recusar é a resposta correta. Juntar os dois grupos seria favorecer-nos: a contagem honesta de falhas desta execução é 9, não 25.

Limitações reais: 9 ficheiros que não conseguimos ler

Todos eles estão intactos (as somas de verificação coincidem com as do editor), por isso trata-se de limites do descodificador e da estrutura do fabricante, não de amostras danificadas. Ficam permanentemente no corpus como cobertura de regressão, e é assim que saberemos no dia em que um deles começar a funcionar.

O padrão é a estrutura do fabricante, não a modalidade. O NDPI de fluorescência e o MIRAX de fluorescência abrem ambos normalmente; são variantes estruturais específicas (um SCN sem imagem principal identificável, um BIF com um atributo de direção inesperado, um contentor "Imaris Classic" anterior ao HDF5) que os backends recusam. Cada mensagem indica a causa em vez de dizer que o ficheiro está corrompido, porque em todos estes casos o ficheiro está bem e quem falha somos nós.

Não são falhas: 16 objetos que não contêm imagem

O DICOM é tanto um formato de documento como um formato de imagem. Um DICOMDIR é o índice de um disco; um estado de apresentação regista como alguém, um dia, ajustou a janela de um estudo; outros objetos contêm relatórios ou medições. Nenhum contém píxeis. Um visualizador que os abrisse não teria nada para mostrar, por isso o SlideScope recusa-os com uma explicação. É o comportamento correto, contado à parte para não inflacionar nenhuma das colunas.

Identificados na íntegra para que nada fique escondido atrás de uma categoria: DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183.

Onde o SlideScope abriu um ficheiro e mostrou a coisa errada

Este é o modo de falha que mais importa e aquele que as tabelas de formatos nunca admitem, por isso aqui está o nosso.

Uma digitalização multiplex Akoya .qptiff (o ficheiro de referência Vectra de sete cores) abriu sem qualquer erro. O ficheiro contém cinco páginas de fluorescência de canal único em resolução total (DAPI, FITC, CY3, Texas Red, CY5) com 34 560 × 24 960 em 33 páginas, o que foi confirmado de forma independente com tifffile. O SlideScope encaminhava todos os .qptiff para o seu backend OpenSlide, que é um leitor de campo claro, por isso indicava um canal e devolvia um corte RGB. Os canais de fluorescência ficavam inacessíveis e os controlos de canais não tinham nada para oferecer.

Nada o avisava. As digitalizações QPTIFF de H&E em campo claro do mesmo corpus abrem perfeitamente, e é exatamente por isso que isto passou despercebido.

Corrigido no SlideScope 1.8.48 (18 de setembro de 2026): o backend é agora escolhido por ficheiro e não por extensão. Uma digitalização multiplex vai para um leitor que devolve os cinco canais; o QPTIFF de campo claro mantém o OpenSlide e o seu mosaico em resolução total. A contrapartida é assumida e não escondida: um QPTIFF multiplex é mostrado em resolução reduzida, e o painel de detalhes do ficheiro indica-o. A execução apresentada nesta página já reflete a correção: a linha do QPTIFF lista os dois carregadores e cinco canais.

Esta execução prova a abertura. A exatidão dos píxeis é uma questão separada, e testamo-la separadamente: uma segunda passagem descodifica os mesmos planos através da biblioteca subjacente e compara-os com o que o carregador devolve. Foi assim que o caso do QPTIFF foi detetado.

O que o SlideScope se recusa a abrir

Não existe um leitor genérico de recurso, e a forma como um visualizador lida com um ficheiro para o qual nunca foi criado importa tanto como os ficheiros para os quais foi. Pegámos no ficheiro real mais pequeno de cada extensão não suportada do corpus de referência (93 no total) e passámos cada um pela fábrica de carregadores da versão publicada.

93 de 93 foram recusados com uma mensagem clara. Nenhum provocou uma falha fatal. Nenhum foi aberto a meio, como algo que parecia uma imagem mas não era. A lista inclui formatos que as pessoas plausivelmente experimentam (.jpg, .lof, .nii, .oib, .oir, .png, .psd, .raw, .vsi); na altura desta execução, incluía .png e .jpg, que foram recusados com uma mensagem em vez de abertos à sorte.

Desde esta execução: o SlideScope 1.10.0 (16 de outubro de 2026) abre mais 18 formatos, incluindo vários aqui recusados: Olympus .vsi, .oib e .oir, Leica .lof e .xlef, Hamamatsu .ndpis, e PNG, JPEG e outras imagens comuns. Os números desta página são os da execução de 18 de setembro, tal como foram medidos; os formatos acrescentados na 1.10.0 não fizeram parte dela. O SlideScope 1.20.0 abre mais cinco que esta execução não testou: Philips .isyntax, KFBio .kfb, ICS/IDS, Gatan .dm3 e .dm4, e Olympus .sis. Consulte a referência de compatibilidade de ficheiros para a lista atual.

O que este benchmark não lhe diz

• Dois formatos não têm qualquer cobertura com ficheiros reais. Não existe nenhuma amostra pública de .vmu nem de .svslide (o OpenSlide não publica nenhuma delas), por isso esses carregadores só são exercitados com casos-limite sintéticos. Não afirmamos que o seu suporte esteja testado.
• Não é um benchmark de velocidade. O tempo até ao primeiro píxel depende do seu disco, e estas execuções foram locais.
• Não é uma auditoria de exatidão para além da passagem de comparação de píxeis descrita acima, nem uma validação clínica. O SlideScope destina-se a investigação, ensino e revisão, não a diagnóstico.
• É um retrato de um momento. Datado de 2026-09-18, com a versão atual nesse dia. As atualizações dos descodificadores fazem estes números variar nos dois sentidos.