O que este vídeo aborda
As listas de formatos suportados afirmam capacidades; este vídeo mede-as. 792 ficheiros reais em 14 famílias de formatos, 44 GB no total, foram abertos um a um num processo isolado que constrói o mesmo carregador que o visualizador usa, descodifica um plano e apresenta-o. 767 abriram, 9 não puderam ser lidos, 16 não continham qualquer imagem e nenhum provocou uma falha.
O vídeo percorre os formatos de lâmina inteira (SVS, NDPI, MIRAX, SCN, BIF, VMS, QPTIFF, AVS), os formatos de microscopia (CZI, ND2, LIF, OME-TIFF) e o DICOM, explica porque é que 16 "falhas" são ficheiros sem quaisquer píxeis e identifica os 9 ficheiros que realmente não podem ser lidos. Todos os resultados, incluindo as falhas, estão publicados na página do benchmark de formatos.
Prefere ler? O benchmark de formatos: todos os ficheiros e resultados.
Transcrição
Atualizado desde a gravação. Desde que este vídeo foi gravado, o problema do QPTIFF multiplex que descreve foi corrigido: os ficheiros QPTIFF multiplex da Akoya abrem agora com os respetivos canais de fluorescência, em vez de uma única imagem RGB. A página do benchmark apresenta os resultados atuais.
Setecentos e noventa e dois ficheiros. Catorze famílias de formatos. Quarenta e quatro gigabytes.
Setecentos e sessenta e sete abriram. Nove não puderam ser lidos.
Dezasseis não continham qualquer imagem. Nenhum fez o visualizador falhar.
Todos os resultados estão publicados, incluindo os que nos deixam mal vistos.
Quase todos os visualizadores publicam uma lista de extensões que alguém escreveu.
Essa lista afirma uma capacidade. Não a mede.
Não lhe diz nada sobre se um ficheiro real de um digitalizador real abre,
nem sobre o que acontece quando não abre.
Por isso testámos todos os ficheiros que temos e publicámos as falhas ao lado dos sucessos.
Cada ficheiro é entregue a um processo filho sacrificável.
Esse processo constrói o mesmo carregador que a aplicação constrói, lê as dimensões,
descodifica um plano e apresenta-o pelo mesmo caminho que o visualizador usa.
Um ficheiro malformado que faça abortar um codec nativo só mata esse processo filho.
É por isso que esta tabela pode indicar honestamente zero na coluna das falhas fatais.
Capítulo um. Formatos de lâmina inteira.
Os ficheiros que saem de um digitalizador e chegam habitualmente a vários gigabytes.
Capítulo dois. Formatos de microscopia.
Aqui a questão não é o tamanho do ficheiro, mas quantos canais, planos focais e pontos temporais sobrevivem.
Capítulo três. DICOM, incluindo DICOM de lâmina inteira.
Trezentos e setenta e oito ficheiros testados. Trezentos e sessenta e dois abriram.
O DICOM é tanto um formato de documento como um formato de imagem.
Um ficheiro DICOMDIR é o índice de um disco.
Um estado de apresentação regista como alguém, um dia, ajustou a janela de um estudo.
Outros contêm relatórios ou medições. Nenhum deles contém píxeis.
Por isso, recusá-los é a resposta correta, e contá-los como falhas seria favorecer-nos.
A contagem honesta de falhas desta execução é nove, não vinte e cinco.
Nove ficheiros que realmente não conseguimos abrir.
Duas lâminas Leica SCN. Uma não tem uma imagem principal identificável.
A outra tem imagens principais dissemelhantes.
Um Ventana BIF com um atributo de direção inesperado.
E seis contentores Imaris Classic mais antigos, de antes de o formato passar para HDF5.
Todos eles estão intactos. As somas de verificação coincidem com as do editor.
São limites do descodificador e da estrutura do fabricante, e ficam no corpus como cobertura de regressão.
Esta é a falha que mais importa, e aquela que as tabelas de formatos nunca admitem.
Um QPTIFF multiplex da Akoya abre sem qualquer erro.
O ficheiro contém cinco canais de fluorescência em resolução total, com trinta e quatro mil píxeis de largura.
DAPI, FITC, Cy3, Texas Red e Cy5.
Encaminhamo-lo para um leitor de campo claro, por isso indica um canal e devolve um corte RGB.
Os canais de fluorescência ficam inacessíveis e nada o avisa.
As digitalizações de campo claro do mesmo formato abrem perfeitamente, e é exatamente por isso que isto passou despercebido.
Capítulo quatro. Não existe um leitor genérico de recurso.
Pegámos no ficheiro real mais pequeno de cada extensão não suportada do corpus de referência.
Noventa e três ficheiros, cada um passado pelo carregador da versão publicada.
Todos os noventa e três foram recusados com uma mensagem clara. Nenhum provocou uma falha.
Nenhum foi aberto a meio, como algo que parecia uma imagem mas não era.
Dois formatos não têm qualquer cobertura com ficheiros reais.
Não existe nenhuma amostra pública de nenhum deles, por isso não afirmamos que o seu suporte esteja testado.
Isto não é um benchmark de velocidade, nem uma validação clínica.
E é um teste do próprio fabricante. Fomos nós que escrevemos o software e fomos nós que fizemos o teste.
Em vez de independência, o que oferecemos é a possibilidade de verificar.
O nosso corpus não é a sua gaveta de lâminas.
Os resultados em bruto, ficheiro a ficheiro, estão publicados em JSON.
Os corpora podem ser transferidos publicamente e o script de execução está no nosso repositório.
Abra os ficheiros que realmente lhe dão problemas.
E se algum deles falhar, envie-o para nós.
As falhas deste vídeo chegaram aqui porque alguém o fez.