이 벤치마크는 실제로 무엇을 증명하나요?
이름이 밝혀진 스캐너에서 나온 이름이 밝혀진 파일이, 실제 크기 그대로, 출시용 빌드에서 열려 화면에 픽셀을 표시한다는 것. 그 이상도 이하도 아닙니다. 형식 지원 목록은 기능을 주장하지만, 이 벤치마크는 기능을 측정합니다. 제조사 레이아웃 때문에 디코더가 실패하면, 그 파일은 누락된 행이 아니라 사용자가 보게 될 오류 문구와 함께 실패 표에 나타납니다.
이것은 제조사가 직접 한 테스트입니다. 소프트웨어를 만든 것도, 테스트를 실행한 것도 저희입니다. 그래도 읽어 볼 가치가 있는 이유는 직접 확인할 수 있기 때문입니다. 코퍼스는 공개되어 있고, 실행기는 저희 데스크톱 저장소에 있으며, 파일별 원시 결과가 이 페이지에 있습니다.
파일을 테스트한 방법
각 파일은 희생용 자식 프로세스에 전달됩니다. 이 프로세스는 애플리케이션과 동일한 로더를 만들고, 이미지 차원을 읽고, 평면 하나를 디코딩한 뒤, 뷰어가 사용하는 것과 같은 Qt 렌더링 경로로 변환합니다. 잘못된 파일이 네이티브 코덱을 중단시켜도 그 자식 프로세스만 종료되며, 감독 프로세스는 처리 중이던 파일을 기록하고 계속 진행합니다. 이런 설계 덕분에 수 기가바이트 제조사 스캔에 대한 벤치마크를 끝까지 마칠 수 있었고, 이 표에서 "충돌" 항목을 정직하게 0으로 보고할 수 있습니다.
- 실행기:
slidescope-desktop/scripts/publish_format_benchmark.py — SlideScope 데스크톱 저장소에 있는 단일 명령으로, 세 단계를 모두 실행하고 이 페이지가 렌더링하는 JSON을 그대로 생성합니다: python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
- 코퍼스: Open Microscopy Environment 공개 참조 코퍼스, OpenSlide가 공개한 테스트 슬라이드,
czitools 및 nd2 라이브러리 테스트 데이터, 그리고 배포처와 sha256을 대조해 확인한 제조사 샘플.
- 범위: 전체 슬라이드 및 제조사 현미경 형식. 제조사가 대량으로 제공한 단일 평면 TIFF 파일은 제외했습니다. 피라미드형 WSI TIFF가 더 잘 보여주지 못하는 정보를 담고 있지 않기 때문입니다.
- 파일별 기록 항목: 감지된 형식, 로더, 디코딩된 T/Z/C/Y/X 차원, 픽셀 유형, 렌더링 크기, 그리고 실패 시 예외 유형과 사용자에게 표시되는 메시지.
전체 슬라이드 이미지 형식
스캐너 형식입니다. Aperio, Hamamatsu, 3DHISTECH, Leica, Ventana, Akoya, Agilent 장비에서 나오며 흔히 수 기가바이트에 이르는 파일들입니다.
현미경 및 의료 영상 형식
다차원 획득 형식입니다. 여기서 흥미로운 질문은 파일 크기가 아니라, 화면에 표시될 때까지 채널, Z 평면, 시점이 얼마나 온전히 유지되는가입니다.
열리지 않은 모든 파일과 그 이유
792개 중 25개 파일이 열리지 않았는데, 이는 한 가지가 아니라 두 가지 이야기입니다. 9개는 실제 한계로, 현재 읽을 수 없는 진짜 이미지입니다. 나머지 16개는 애초에 이미지가 없는 파일이어서 거부하는 것이 올바른 답입니다. 둘을 하나로 묶으면 오히려 저희를 실제보다 좋게 보이게 할 것입니다. 이번 실행의 정직한 실패 수는 25개가 아니라 9개입니다.
실제 한계: 읽을 수 없는 파일 9개
이 파일들은 모두 손상되지 않은 원본이며 체크섬이 배포처와 일치합니다. 따라서 손상된 샘플이 아니라 디코더와 제조사 레이아웃의 한계입니다. 회귀 테스트 범위로 코퍼스에 영구히 남겨 두며, 그래서 이 중 하나가 작동하기 시작하는 날 바로 알 수 있습니다.
패턴은 영상 방식이 아니라 제조사 레이아웃에 있습니다. 형광 NDPI와 형광 MIRAX는 모두 정상적으로 열립니다. 백엔드가 거부하는 것은 특정 구조 변형입니다. 식별 가능한 주 이미지가 없는 SCN, 예상치 못한 방향 속성을 가진 BIF, HDF5 이전의 "Imaris Classic" 컨테이너 등입니다. 각 메시지는 파일이 손상되었다고 하지 않고 원인을 밝힙니다. 이 모든 경우에 파일에는 문제가 없고, 문제는 저희 쪽에 있기 때문입니다.
실패가 아닌 것: 이미지가 없는 객체 16개
DICOM은 이미지 형식인 만큼 문서 형식이기도 합니다. DICOMDIR은 디스크의 색인이고, 프레젠테이션 상태(presentation state)는 누군가 검사에 창을 어떻게 적용했는지를 기록하며, 그 밖의 객체에는 보고서나 측정값이 들어 있습니다. 어느 것도 픽셀을 담고 있지 않습니다. 이를 연다 해도 뷰어가 보여줄 것이 없으므로 SlideScope는 설명과 함께 거부합니다. 이는 올바른 동작이며, 어느 쪽 열도 부풀리지 않도록 따로 집계합니다.
범주 뒤에 아무것도 숨기지 않도록 모두 이름을 밝힙니다: DICOMDIR, PS_0026, PS_0108, PS_0128, PS_0154, PS_0181, XX_0027, XX_0109, XX_0155, XX_0182, XX_0183.
SlideScope가 파일을 열었지만 잘못된 것을 보여준 경우
이것이 가장 중요한 실패 유형이자 형식 표가 결코 인정하지 않는 유형이므로, 저희 사례를 공개합니다.
멀티플렉스 Akoya .qptiff 스캔(Vectra 7색 참조 파일)이 아무 오류 없이 열렸습니다. 이 파일에는 전체 해상도 단일 채널 형광 페이지 다섯 개(DAPI, FITC, CY3, Texas Red, CY5)가 34,560 × 24,960 크기로 총 33페이지에 걸쳐 들어 있으며, 이는 tifffile로 독립적으로 확인했습니다. SlideScope는 모든 .qptiff를 명시야 리더인 OpenSlide 백엔드로 보냈기 때문에 채널이 하나라고 보고하고 RGB 슬라이스를 반환했습니다. 형광 채널에는 접근할 수 없었고 채널 컨트롤에는 제공할 것이 없었습니다.
아무런 경고도 없었습니다. 같은 코퍼스의 명시야 H&E QPTIFF 스캔은 완벽하게 열리기 때문에 바로 이 문제가 눈에 띄지 않았습니다.
SlideScope 1.8.48(2026년 9월 18일)에서 수정됨: 이제 백엔드를 확장자가 아니라 파일별로 선택합니다. 멀티플렉스 스캔은 다섯 채널을 모두 반환하는 리더로 가고, 명시야 QPTIFF는 OpenSlide와 그 전체 해상도 타일링을 그대로 사용합니다. 대가는 숨기지 않고 밝힙니다. 멀티플렉스 QPTIFF는 낮은 해상도로 표시되며, 파일 세부 정보 패널에 그 사실이 표시됩니다. 이 페이지의 실행 결과에는 이미 수정 사항이 반영되어 있어, QPTIFF 행에 두 로더와 다섯 채널이 모두 나와 있습니다.
파일이 열린다는 것은 이번 실행으로 증명됩니다. 픽셀이 정확한지는 별개의 문제이며 따로 테스트합니다. 두 번째 검사에서 같은 평면을 기반 라이브러리로 디코딩해 로더가 반환한 결과와 비교합니다. QPTIFF 사례도 이렇게 발견했습니다.
SlideScope가 열기를 거부하는 파일
범용 대체 리더는 없으며, 뷰어가 지원 대상이 아닌 파일을 어떻게 처리하는지는 지원 대상 파일을 처리하는 방식만큼 중요합니다. 참조 코퍼스에서 지원하지 않는 확장자마다 가장 작은 실제 파일을 하나씩, 총 93개를 골라 각각 출시용 로더 팩토리로 처리했습니다.
93개 중 93개 모두 명확한 메시지와 함께 거부되었습니다. 충돌은 없었습니다. 이미지처럼 보이지만 실제로는 이미지가 아닌 상태로 반쯤 열린 파일도 없었습니다. 목록에는 사람들이 시도해 볼 만한 형식(.jpg, .lof, .nii, .oib, .oir, .png, .psd, .raw, .vsi)이 포함되어 있으며, 이번 실행 당시에는 .png와 .jpg도 포함되어 추측해서 열지 않고 메시지와 함께 거부되었습니다.
이번 실행 이후: SlideScope 1.10.0(2026년 10월 16일)은 여기서 거부된 여러 형식을 포함해 18개 형식을 추가로 엽니다. Olympus .vsi, .oib, .oir, Leica .lof 및 .xlef, Hamamatsu .ndpis, 그리고 PNG, JPEG 등 일상적인 이미지입니다. 이 페이지의 수치는 9월 18일 실행에서 측정한 그대로이며, 1.10.0에서 추가된 형식은 포함되지 않았습니다. SlideScope 1.20.0은 이번 실행에서 테스트하지 않은 다섯 가지 형식을 더 엽니다. Philips .isyntax, KFBio .kfb, ICS/IDS, Gatan .dm3 및 .dm4, Olympus .sis입니다. 최신 목록은 파일 호환성 참고 자료를 확인하세요.
이 벤치마크가 알려주지 않는 것
- 두 형식은 실제 파일로 전혀 테스트하지 못했습니다. 공개된
.vmu 또는 .svslide 샘플이 없으며(OpenSlide도 둘 다 공개하지 않음), 따라서 해당 로더는 합성된 경계 사례로만 검증되었습니다. 이 형식들에 대해 테스트를 거친 지원이라고 주장하지 않습니다.
- 속도 벤치마크가 아닙니다. 첫 픽셀이 표시되기까지의 시간은 디스크에 따라 다르며, 이번 실행은 로컬에서 진행했습니다.
- 위에서 설명한 픽셀 비교 검사 외에는 정확도 감사가 아니며, 임상 검증도 아닙니다. SlideScope는 연구, 교육, 검토용이며 진단용이 아닙니다.
- 특정 시점의 스냅샷입니다. 2026-09-18에 그날의 최신 릴리스를 대상으로 실행했습니다. 디코더가 업그레이드되면 이 수치는 어느 방향으로든 바뀔 수 있습니다.
이 벤치마크에 관한 질문
SlideScope는 실제로 어떤 현미경 및 전체 슬라이드 형식을 여나요?
18개 파일 확장자: .svs, .ndpi, .mrxs, .scn, .bif, .vms, .vmu, .svslide, .qptiff, .avs, .czi, .nd2, .lif, .ims, .dcm, .dicom, .tif, .tiff. 범용 대체 리더는 없으며, 이 목록 밖의 파일은 제대로 열리지 않은 채로 표시되는 대신 알기 쉬운 메시지와 함께 거부됩니다.
이 벤치마크는 독립적인가요?
아니요. SlideScope가 SlideScope에 대해 공개하는 것이므로, 제3자 감사가 아니라 제조사 테스트로 받아들이세요. 독립성 대신 저희가 제공할 수 있는 것은 검증 가능성입니다. 코퍼스는 공개되어 있고, 실행기는 공개 스크립트 디렉터리에 있으며, 원시 결과 파일은 이 페이지에 링크되어 있고, 실패도 성공과 같은 수준으로 자세히 나열되어 있습니다.
일부 파일은 왜 실패하나요?
거의 언제나 제조사가 기반 오픈 소스 백엔드가 읽을 수 없는 레이아웃으로 파일을 작성했기 때문입니다. 예를 들어 형광 SCN에서 OpenSlide가 "Can't find main image"를 보고하는 경우입니다. 이는 저희가 숨기지 않고 드러내는 상위 프로젝트의 한계입니다. 실패한 파일은 손상되지 않은 원본이며, 체크섬이 배포처와 일치합니다.
파일이 열리면 이미지가 정확하다는 뜻인가요?
그것만으로는 아닙니다. 그래서 두 가지를 모두 테스트합니다. 파일이 열린다는 것은 이번 실행으로 증명되고, 픽셀 정확도는 sweep_format_reference.py로 따로 증명합니다. 이 스크립트는 같은 평면을 기반 라이브러리로 디코딩해 SlideScope가 렌더링한 결과와 비교합니다. 알려진 사례 하나, 즉 멀티플렉스 Akoya QPTIFF는 오류 없이 열렸지만 SlideScope 1.8.48에서 수정되기 전까지 잘못된 것을 보여주었습니다. 이 사례는 이 페이지에 기록되어 있습니다.
이 결과를 재현할 수 있나요?
네. Open Microscopy Environment 참조 코퍼스는 공개적으로 다운로드할 수 있고, 제조사 샘플은 OpenSlide와 형식 라이브러리 자체의 테스트 데이터에서 가져왔으며, 실행기는 SlideScope 데스크톱 저장소에 포함되어 있습니다. 이 페이지의 모든 표의 기반이 된 원시 JSON은 위에 링크되어 있습니다.
SlideScope는 임상 진단용으로 승인되었나요?
아니요. SlideScope는 연구, 교육, 검토용입니다. 진단 기기가 아니며 1차 진단에 사용해서는 안 됩니다.
중요한 테스트는 여러분의 테스트뿐입니다
저희 코퍼스는 여러분의 슬라이드 서랍이 아닙니다. SlideScope를 설치하고 실제로 문제를 일으키는 파일을 열어 보세요. 그중 하나가 실패하면 저희에게 보내 주세요. 이 페이지의 실패 사례도 누군가 그렇게 보내 준 덕분에 여기 실렸습니다.
SlideScope 다운로드