KR20230050362A - 조직병리학 슬라이드의 개선된 시각화 및 렌더링을 제공하기 위해 전자 이미지를 처리하는 시스템 및 방법 - Google Patents

Abstract

뷰어에 의해, 전자 이미지 및 FOV(시야)를 수신하는 단계-여기서, FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-, 뷰어에 의해, 상기 FOV 내에 복수의 타일들을 로딩하는 단계, 뷰어에 의해, 캐시의 복수의 타일들의 상태를 결정하는 단계, 및 캐시의 복수의 타일들의 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 뷰어에 의해, 복수의 타일들을 디스플레이에 렌더링하는 단계를 포함하는 전자 이미지를 처리하기 위한 방법.

Description

조직병리학 슬라이드의 개선된 시각화 및 렌더링을 제공하기 위해 전자 이미지를 처리하는 시스템 및 방법

관련 출원(들)

본 출원은 2020년 8월 11일에 출원된 미국 가출원 번호 제63/064,401호의 우선권을 주장하며, 이의 전체 개시 내용은 본 명세서에 참조로 포함된다.

본 개시의 기술분야

본 개시의 다양한 실시예는 일반적으로 조직병리학 슬라이드(histopathology slide)의 시각화(visualization) 및 렌더링(rendering)을 개선하는 것에 관한 것이다. 보다 구체적으로, 본 개시의 특정 실시예는 조직병리학 슬라이드의 개선된 시각화 및 렌더링을 제공하기 위해 전자 이미지를 처리하기 위한 시스템 및 방법에 관한 것이다. 본 개시는 조직병리학 슬라이드의 개선된 시각화 및 렌더링을 제공하기 위해 전자 이미지를 처리하기 위해 머신 러닝, 인공 지능 및 컴퓨터 비전을 사용하기 위한 시스템 및 방법을 추가로 제공한다.

조직병리학 슬라이드는 생검(biopsy)에서 추출한 조직 섹션(tissue section)으로 현미경 검사를 위해 유리 슬라이드에 놓여 진다. 조직을 현미경으로 볼 수 있도록 하기 위해, 이러한 섹션은 하나 이상의 색소(pigment)들로 염색되며, 그 중 가장 일반적인 것은 슬라이드에 놀라운 분홍색 색조를 제공하는 헤마톡실린 및 에오신(H&E)이다. 이 슬라이드는 역사적으로 현미경으로 검사될 수 있지만, 최근 몇 년 동안 디지털 병리학에 대한 압박이 있었다. 디지털 병리학에서, 슬라이드는 나중에 모니터에서 볼 수 있도록 매우 높은 해상도로 스캔될 수 있다. 디지털 병리학은 특정 이점을 제공하지만 원하는 이미지와 시야를 제공하기에 충분한 해상도로 슬라이드를 스캔하고 시각화하는 것은 어려울 수 있다.

전술한 일반적인 설명 및 다음의 상세한 설명은 단지 예시적이고 설명을 위한 것이며 본 발명을 제한하지 않는다. 본 명세서에 제공된 배경 기술은 본 개시의 맥락을 일반적으로 제시하기 위한 것이다. 본 명세서에 달리 명시되지 않는 한, 이 섹션에 설명된 자료는 이 출원의 청구범위에 대한 선행 기술이 아니며 이 섹션에 포함됨으로써 선행 기술 또는 선행 기술의 제안으로 인정되지 않는다.

본 개시의 특정 양태에 따르면, 조직병리학 슬라이드의 개선된 시각화 및 렌더링을 제공하기 위해 전자 이미지를 처리하기 위한 시스템 및 방법이 개시된다.

전자 이미지를 처리하기 위한 컴퓨터 구현 방법으로서, 상기 방법은: 뷰어에 의해, 전자 이미지 및 FOV(시야)를 수신하는 단계-여기서, FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-, 뷰어에 의해, 상기 FOV 내에 복수의 타일들을 로딩하는 단계, 뷰어에 의해, 캐시의 복수의 타일들의 상태를 결정하는 단계, 및 캐시의 복수의 타일들의 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 뷰어에 의해, 복수의 타일들을 디스플레이에 렌더링하는 단계를 포함한다.

전자 이미지를 처리하기 위한 컴퓨터 시스템에 있어서, 상기 컴퓨터 시스템은 명령어를 저장하는 적어도 하나의 메모리, 및 동작들을 수행하기 위해 명령어를 실행하도록 구성된 적어도 하나의 프로세서를 포함하고, 상기 동작들은: 상기 뷰어에 의해, 상기 전자 이미지 및 FOV(시야)를 수신하는 것-여기서, 상기 FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-, 상기 뷰어에 의해, 상기 FOV 내에 복수의 타일들을 로딩하는 것, 상기 뷰어에 의해, 상기 캐시의 복수의 타일들의 상태를 결정하는 것, 및 상기 캐시의 상기 복수의 타일들의 상기 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들을 디스플레이에 렌더링하는 것을 포함한다.

프로세서에 의해 실행될 때 상기 프로세서로 하여금 전자 이미지를 처리하기 위한 동작들을 수행하게 하는 명령어를 저장하는 비일시적 컴퓨터 판독가능 매체로서, 상기 동작들은: 상기 뷰어에 의해, 상기 전자 이미지 및 FOV(시야)를 수신하는 것-여기서, 상기 FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-, 상기 뷰어에 의해, 상기 FOV 내에 복수의 타일들을 로딩하는 것, 상기 뷰어에 의해, 상기 캐시의 복수의 타일들의 상태를 결정하는 것, 및 상기 캐시의 상기 복수의 타일들의 상기 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들을 디스플레이에 렌더링하는 것을 포함한다.

전술한 일반적인 설명 및 다음의 상세한 설명은 단지 예시적이고 설명을 위한 것이며 청구된 바와 같이 개시된 실시예를 제한하지 않는다는 것을 이해해야 한다.

본 명세서에 포함되어 그 일부를 구성하는 첨부 도면은 다양한 예시적인 실시예를 설명하고 개시된 실시예의 원리를 설명하는 역할을 한다.
도 1은 본 개시의 예시적인 실시예에 따른 전체 슬라이드 이미지의 피라미드 구조를 도시한다.
도 2는 본 개시의 일 실시예에 따른 예시적인 뷰어의 시야(FOV)를 도시한다.
도 3은 본 개시의 일 실시예에 따른 예시적인 뷰어의 아키텍처를 도시한다.
도 4는 본 개시의 일 실시예에 따른 뷰어로부터의 예시적인 타일 요청의 타이밍 분석(timing breakdown)을 도시한다.
도 5는 본 개시의 일 실시예에 따른 예시적인 타일 요청의 제어 흐름을 예시하는 흐름도이다.
도 6a는 본 개시의 일 실시예에 따른 뷰어의 아키텍처이다.
도 6b는 본 개시의 일 실시예에 따른 뷰어의 네이티브 애플리케이션의 아키텍처이다.
도 7a는 본 개시의 일 실시예에 따른 타일 요청의 제어 흐름을 예시한 흐름도이다.
도 7b는 본 개시의 일 실시예에 따른 레이턴시 표시(latency indication)가 있는 타일 요청의 제어 흐름을 예시하는 흐름도이다.
도 8은 본 개시의 일 실시예에 따른 타일 요청의 정적 제어 흐름을 예시하는 흐름도이다.
도 9는 본 개시의 일 실시예에 따른 뷰어 아키텍처의 메인 루프를 예시하는 흐름도이다.
도 10a는 본 개시의 일 실시예에 따른 뷰어에서 슬라이드를 처음 보는 모습을 도시한다.
도 10b는 본 개시의 일 실시예에 따른 뷰어에서 로딩 시야를 도시한다.
도 11은 본 개시의 일 실시예에 따른 예시적인 뷰어에서 프리로딩(preloading) 타일을 갖는 시야를 도시한다.
도 12는 본 개시의 일 실시예에 따른 뷰어 내에서 예시적인 타일 디코딩의 타이밍 분석을 도시한다.
도 13a는 본 개시의 일 실시예에 따른 동적 타일링을 갖는 예시적인 실시예에 대한 시야(FOV) 완성을 도시한다.
도 13b는 본 개시의 일 실시예에 따른 정적 타일링을 갖는 예시적인 실시예에 대한 FOV 완성을 도시한다.
도 14는 본 개시의 일 실시예에 따른 타일 프리로딩을 갖는 예시적인 실시예에 대한 FOV 완성을 도시한다.
도 15a 내지 15f는 본 개시의 일 실시예에 따른 예시적인 실시예에 대한 상이한 FOV 완성을 도시한다.
도 16은 본 개시의 일 실시예에 따른 스트리밍 뷰어의 예시적인 아키텍처이다.

이제 본 발명의 예시적인 실시예를 상세히 참조할 것이며, 그 예는 첨부된 도면에 예시되어 있다. 가능하면 동일하거나 유사한 부품을 나타내기 위해 도면 전체에서 동일한 참조 번호가 사용된다.

본 명세서에 개시된 시스템, 디바이스 및 방법은 예로서 그리고 도면을 참조하여 상세히 설명된다. 본 명세서에서 논의된 예는 단지 예일 뿐이며 본 명세서에서 설명된 장치, 디바이스, 시스템 및 방법의 설명을 돕기 위해 제공된다. 도면에 표시되거나 아래에서 논의되는 피쳐나 컴포넌트는 특별히 필수로 지정되지 않는 한 이러한 디바이스, 시스템 또는 방법의 특정 구현에 필수로 간주되어서는 안 된다.

또한, 설명된 임의의 방법에 대해, 그 방법이 흐름도와 함께 설명되는지 여부에 관계없이, 문맥상 달리 명시되거나 요구되지 않는 한, 방법의 실행에서 수행되는 단계들의 명시적 또는 암시적 순서 지정은 이러한 단계들이 제시된 순서대로 수행되어야 함을 의미하는 것이 아니라 다른 순서로 또는 병렬로 수행될 수 있음을 이해해야 한다.

본 명세서에서 사용되는 용어 "예시적인"은 "이상적인"이 아니라 "예시"의 의미로 사용된다. 또한, 본 명세서에서 단수 용어("a" 및 "an")는 수량 제한을 나타내지 않고 오히려 하나 이상의 참조 항목의 존재를 나타낸다.

스캐너 제조업체는 종종 스캐너와 함께 슬라이드를 시각화하기 위해 자체 소프트웨어를 유지 관리한다. 또한 그들은 타사 소프트웨어에서 거의 동일한 방식으로 이러한 슬라이드를 열고 판독할 수 있다. 이러한 소프트웨어 패키지 또는 모듈을 일반적으로 슬라이드 뷰어(slide viewer)라고 한다. 본 개시는 무엇보다도 다양한 스캐너들로부터 획득된 슬라이드들을 열 수 있는 새로운 슬라이드 뷰어의 예시적인 실시예를 포함한다. 이 뷰어는 모든 최신 인터넷 브라우저(예를 들어, Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari 등)에서 운영될 수 있다. 슬라이드 보기 기능 외에도, 슬라이드 뷰어는 암 검출을 위한 고급 의료 등급 인공 지능 추론 기능을 통해 다른 제품과 연결될 수도 있다.

슬라이드 스캔은 해상도가 20,000 x 20,000에서 120,000 x 120,000 픽셀 이상인 이미지이다. 이러한 이미지를 전체 슬라이드 이미지(WSI)라고 하며 손실 압축 후에도 디스크에서 여러 기가바이트의 크기(weigh)를 가질 수 있으며 적시에 볼 수 있도록 클라이언트에 효율적으로 전송할 수 없다. 큰 디지털 이미지를 처리하는 데 특정 기술적 장애물이 존재한다. 첫째, 대역폭은 특정 시간 동안 얼마나 많은 데이터를 전송할 수 있는지에 대한 제한 요소이다. 뷰어는 인터넷을 통해 액세스되기 때문에, 이 대역폭은 일반적으로 초당 몇 메가바이트의 상한선을 가진다. 이것은 기가바이트 이미지를 전송하는 데 몇 초 또는 몇 분이 걸린다는 것을 의미한다. 또한 이러한 이미지를 디코딩하려면 상당한 처리 능력이 필요할 수 있다. 작은 256x256 이미지는 밀리초 단위로 디코딩될 수 있지만, 기가픽셀 이미지를 디코딩하는 데 몇 분은 아니더라도 몇 초가 걸린다. 마지막으로 메모리 측면에서 압축된 이미지의 크기는 기가바이트 수준이지만 압축되지 않은 데이터는 훨씬 더 크다. 이러한 양의 데이터는 컴퓨터의 메모리에 한 번에 맞지 않는다.

한 가지 목표는 WSI와 관련하여 현재 기술 스택을 개선하는 방법을 찾는 것이다. 본 개시에 의해 다루어지는 몇 가지 관심 분야는 조직병리학 슬라이드 데이터를 스트리밍(streaming)하는 새로운 방식을 포함한다. 현재 슬라이드 뷰어는 오픈 소스 라이브러리 및 공급업체 소프트웨어 개발 키트(SDK)를 사용하여 슬라이드를 열고 판독할 수 있다. 이러한 옵션은 가장 효율적이지 않으며 더 나은 기술을 사용하면 스트리밍 속도를 크게 높일 수 있다.

예를 들어, 이는 새로운 최적화를 가능하게 하거나 기존 최적화를 최대한 활용하기 위해 슬라이드가 디스크에 저장될 때 슬라이드의 데이터 표현 형식을 변경하는 것을 포함할 수 있다. 역사적으로 슬라이드는 스캐너 공급업체에 전적으로 의존하는 원본 형식으로 저장되었다. 공급업체마다 제약조건이 다를 수 있으며 이는 통합된 형식이 없으면 가능한 모든 경로들을 최적화하기가 더 어려울 수 있음을 의미한다.

새로운 압축 기술은 또한 슬라이드 보기에서 현재 기술을 향상시킬 수 있다. 이 연구 축은 슬라이드 이미지 데이터를 보다 효율적으로 저장할 수 있는 새로운 압축 기술에 중점을 둔다. 예를 들어, 조직 검출 알고리즘은 조직이 검출되지 않은 이미지의 많은 부분을 저장하지 않아도 된다. 최신 이미지 형식은 인코딩 중에 고급 기술이나 컴퓨팅 성능을 활용하여 더 나은 압축률을 제공할 수도 있다.

또한, 서버측 렌더링은 현재의 슬라이드 보기 기술을 향상시킬 수 있다. 가상 네트워크 컴퓨팅(VNC) 기술은 시각적 피드를 클라이언트에 스트리밍하여 실시간 대화형 경험을 구축할 수 있음을 입증하였으며, 클라이언트는 차례로 서버에 사용자 입력을 발송한다. 이러한 접근법은 뛰어난 사용자 경험을 가능하게 하는 동시에 고성능 비디오 코덱 덕분에 데이터 전송을 최소화할 수 있다.

또한 슬라이드 보기 기술 개선은 프런트엔드(frontend) 렌더링 기술을 포함할 수 있다. 웹 브라우저는 이제 그래픽 처리 장치(GPU) 렌더링을 활용할 수 있다. WebGL 애플리케이션 프로그래밍 인터페이스(API)를 사용하면 자바스크립트(JavaScript) 애플리케이션이 3D 렌더링을 위한 산업 표준인 OpenGL에서 영감을 받은 관용구로 렌더링 명령어를 실행할 수 있다. 보다 최근에는, WebGL 2.0 및 WebGPU와 같은 새로운 API가 GPU 프리미티브(primitive)에 대한 저레벨 액세스를 허용함으로써 더욱 발전하였다. 슬라이드 뷰어 속도를 높이고 메모리 소비를 줄이기 위해 이러한 기술이 슬라이드 뷰어에 적용될 수 있다.

다음 섹션에서는, 예시적인 WSI 뷰어와 관련된 개념을 설명하기 위해 특정 용어가 사용된다.

전술한 바와 같이, WSI는 조직병리학 슬라이드의 고해상도 이미지 스캔이다. 이러한 이미지의 해상도는 기가픽셀 범위이다. 이 속성은 기존 방식으로 이러한 이미지를 저장하고 표시하는 것을 비현실적으로 만든다. 실제로, 메모리에서 전체 이미지를 디코딩하는 것은 그것이 수십 기가바이트를 차지하기 때문에 매우 어렵고, 이는 오늘날 사용 가능한 많은 개인용 컴퓨터의 메모리 자질 이상이다. 또한, 모니터 해상도가 메가픽셀에 가깝기 때문에 전체 이미지를 표시하는 것도 어려울 것이다.

따라서, WSI는 영역 디코딩을 허용하는 방식으로 인코딩된다. 전체 이미지를 판독하거나 디코딩하지 않고도 이미지의 각 영역이 표시될 수 있다. 앞서 언급된 바와 같이, 병리학자가 슬라이드를 보기 위해 사용하는 모니터는 일반적으로 전체 해상도 이미지를 표시할 수 없다. 결과적으로 일반적으로 현재 화면에 표시되는 영역만 디코딩되어 클라이언트로 전송될 수 있다. 이 최적화를 통해 실시간으로 WSI를 인덱싱하고 판독할 수 있다.

그러나, 병리학자가 줌 아웃(zoom out)하여 전체 슬라이드를 화면에 표시하기로 결정하는 경우 이러한 접근법은 부족한다. 전체 이미지의 다운샘플링된 버전을 표시하려면, 전체 이미지를 판독해야 할 수도 있다. 이를 해결하기 위해 WSI는 전체 해상도 베이스라인 이미지 위에 더 작은 해상도의 중간 배율 레벨을 포함하여 화면에 맞을 수 있는 썸네일 이미지까지 포함한다. 그러한 조직은 종종 피라미드 구조로 지칭되며, 여기서 피라미드의 베이스는 베이스라인 이미지이고 그 위의 각각의 레벨은 중간 배율 레벨일 수 있다.

영역 디코딩을 허용하기 위해, 각 레벨은 정규 그리드(regular grid)에서 타일들로 절단될 수 있다. 이러한 타일들은 무작위로 액세스될 수 있다. 이미지의 영역을 디코딩하기 위해, 겹치는 타일들만을 판독하고 디코딩해야 할 수 있다. 도 1은 이 피라미드 구조의 개략도이다.

도 1에 도시된 바와 같이, 피라미드 구조는 전체 해상도 이미지를 포함하는 베이스라인 이미지(1)를 갖는다. 적어도 하나의 다운샘플링된 이미지, 즉 도 1의 다운샘플링된 이미지들(2 및 3)은 베이스라인 이미지(1) 위에 배치될 수 있다. 베이스라인 이미지(1) 뿐만 아니라 다운샘플링된 이미지들(2 및 3)은 전술한 바와 같이 정규 그리드로 절단될 수 있다.

뷰어의 시야(FOV)는 현재 표시되는 이미지의 영역이다. 이는 좌표(x, y), 치수(w, h) 및 배율 인자(magnification factor) z의 그룹화로 생각될 수 있다. 배율 인자는 표시에 가장 적합한 WSI 레벨을 결정할 수 있는 반면, 좌표 및 치수는 레벨 이미지의 어느 영역이 디코딩되어야 하는지 결정할 수 있다.

도 2는 요청된 FOV(12)를 표시하기 위해 레벨 이미지(10)의 몇 개의 활성 타일들(11)만이 디코딩될 필요가 있는 방법을 도시한다. 유휴 타일(idle tile)(13)은 FOV(12)에 포함되지 않을 수 있다.

FOV(12)가 이동하면 활성 타일(11)이 변경된다. 현재 디스플레이에 필요한 타일들만이 메모리에 보관되어야 할 수 있다. 따라서 필요한 그래픽 메모리는 이미지 크기의 함수가 아니라 디스플레이의 해상도의 함수일 수 있다.

개선할 서로 다른 영역들을 더 잘 식별하기 위해, 한 가지 가능한 접근법은 예시적인 슬라이드 뷰어의 아키텍처를 자세히 살펴보는 것이었다. 예시적인 슬라이드 뷰어의 아키텍처는 도 3에 예시되어 있다. 예시적인 슬라이드 뷰어는 프런트엔드(20) 및 백엔드("타일 서버")(30)로 구성될 수 있다. 프런트엔드(20)는 사용자에게 WSI를 표시하는 일을 담당할 수 있는 반면, 백엔드(30)는 잠재적으로 필요한 데이터를 프런트엔드에 통신하는 일을 담당할 수 있다. 예시적인 컴포넌트에 대한 자세한 내용은 다음 섹션에서 설명된다.

사용자는 웹 브라우저를 통해 예시적인 슬라이드 뷰어에 액세스할 수 있으므로, 프런트엔드(20)(도 3에 도시된 바와 같음)는 자바스크립트로 기록된 웹 애플리케이션일 수 있다. 예시적인 슬라이드 뷰어는 고해상도 이미지를 위한 웹 기반 뷰어인 OpenSeadragon 오픈 소스 라이브러리와 같은 뷰어(21)를 광범위하게 사용할 수 있다.

예를 들어 OpenSeadragon과 같은 뷰어(21)는 "슬라이드 네비게이션(Slide Navigation)" 패널을 사용하여 패닝(panning), 주밍(zooming) 및 점핑 어라운드(jump around)과 같은 사용자 상호작용뿐만 아니라 WSI의 렌더링의 일부 또는 전부를 핸들링할 수 있다. 사용자는 마우스로 화면을 드래그하여 디스플레이를 패닝할 수 있으며, 스크롤링을 통해 줌 인 및 줌 아웃할 수 있다. 디스플레이 회전, 물리적 거리 측정, 캔버스에 주석 그리기 등과 같은 추가 피쳐가 있을 수 있다.

위에서 개시된 바와 같이, WSI는 다중 배율 레벨로 분할되고 타일들로 절단된다(도 1의 피라미드 참조). 주어진 FOV를 표시하기 위해, 뷰어(21)(예를 들어, OpenSeadragon)는 타일 서버라고도 하는 백엔드(30)로부터 FOV를 커버하는 모든 타일들을 로딩한다.

OpenSeadragon은 고해상도 이미지를 보기 위한 강력한 솔루션이다. 그러나 웹 플랫폼을 대상으로 하는 다른 고해상도 이미지 뷰어 솔루션과 비교할 때 OpenSeadragon은 사용자 상호작용 중에 항상 초당 60프레임(FPS)을 일정하게 유지할 수 없다. 이는 차선의 사용자 경험을 제공할 수 있다. 또한 Seadragon은 2D 브라우저 캔버스 애플리케이션 프로그래밍 인터페이스(API)만을 사용한 렌더링만 지원할 수 있다. 결과적으로 WebGL은 클라이언트의 그래픽 능력을 더 잘 활용할 수 있는 더 성능이 뛰어난 API로 사용될 수 있다.

OpenSeadragon은 브라우저에서 큰 이미지를 볼 수 있는 유일한 가능한 솔루션이 아니다. 다른 적합한 뷰어 솔루션은 OpenLayers, Leaflet, MapBox 및 DeckGL을 포함한다. 이러한 모든 솔루션은 지리적 데이터에 맞게 조정되지만 2D 픽셀 데이터를 지원하도록 적응될 수 있다. 이러한 솔루션 중 일부는 WebGL을 지원하고 성능이 좋다. 그러나 필요하지 않은 피쳐를 포함할 수 있다. 결과적으로 가능한 솔루션의 표면 영역이 상당히 클 수 있으므로, 이는 수정을 더 어렵게 만든다.

프런트엔드(20)는 또한 비즈니스 로직 알고리즘(22)을 포함할 수 있다.

예시적인 슬라이드 뷰어의 백엔드(30)는 C#으로 기록된 웹 서버(31)를 포함할 수 있다. 웹 서버(31)는 HTTP 요청을 효율적으로 서비스하기 위해 IIS 웹 서버(32) 상의 소프트웨어를 활용할 수 있다.

백엔드(30)는 예시적인 뷰어에서 관심 있는 하나의 컴포넌트다: 좌표(x, y) 및 배율 레벨 z에서 치수(w, h)의 타일에 대한 요청이 주어지면, 백엔드(30)는 대응하는 이미지를 반환한다. 예시적인 슬라이드 뷰어는 다수의 WSI 형식들을 지원할 수 있기 때문에, 백엔드(30)는 도 3에 도시된 바와 같이 딥 줌(Deep Zoom) 구현(34)과 같은 상이한 구현들(34)을 호출할 수 있다. 이러한 구현들(34)은 원본 WSI 파일로부터 요청된 이미지 영역을 디코딩하는 로직을 소유한다. 일반적으로 WSI 파일은 백엔드(30)와 관련된 파일 시스템(35)에 저장될 수 있다.

Deep Zoom은 매우 큰 이미지를 스트리밍하고 시각화하는 기술이다. Deep Zoom 이미지(DZI)는 DZI 파일과 디렉토리의 두 부분들로 구성된다. DZI 파일(.dzi)은 시각화 목적의 이미지 형식을 설명한다. 두 가지 중요한 속성들은 타일 크기와 베이스라인 해상도일 수 있으며, 베이스라인 해상도에 2의 음의 거듭제곱을 곱하여 일부 또는 모든 중간 배율 레벨을 추론할 수 있다. 예를 들어 베이스라인 해상도가 1024 Х 1024인 경우, 제1 중간 레벨의 해상도는 512 Х 512, 제2 중간 레벨의 해상도는 256 Х 256 등과 같다. DZI 파일 외에도 디렉토리에는 자체적으로 다른 배율 레벨에 대응하는 폴더에 정렬된 타일 이미지들의 일부 또는 전부가 포함될 수 있다. 예를 들어, tiles/3/1_2.jpg 경로 아래에 저장된 파일은 배율 레벨 z = 3 및 좌표 (x, y) = (1, 2)의 타일에 대응한다. z = 3에서, 레벨 해상도는 베이스라인 이미지의 1/8이다.

웹 서버의 성능 측면에서, 타일 요청은 거의 즉각적이어야 한다. 뷰어가 반응을 느끼려면, 타일 요청의 레이턴시가 짧고 처리량이 높아야 할 수 있다. 따라서 타일 검색 및 제공을 위한 파이프라인은 이용 가능한 가장 빠른 기술을 사용하여 가능한 한 짧게 유지해야 할 수 있다. 이 경우, IIS와 같은 모든 특성을 갖춘(full-blown) 웹 서버를 사용하는 것은 과잉(overkill)일 수 있다.

C#에서 레이턴시가 짧은 시스템을 구축하는 것이 가능할 수 있지만, 언어 때문에 어려울 수 있다. C#은 수집하기 어려운 언어이다: 메모리 할당은 자동으로 이루어지며 프로세스는 때때로 할당 해제 및 메모리 해제가 가능한 것을 결정하기 위해 할당된 오브젝트의 그래프를 탐색할 수 있다. 이는 C#이 완전히 메모리-안전(memory-safe)이며 프로그래머가 메모리 관리에 대해 거의 걱정할 필요가 없음을 의미한다. 그러나 이 절차는 비용이 들지 않는 것이 아니며, 요청이 계류 중인 동시에 실행될 때 레이턴시 급증을 유발할 수 있다. 또한 가비지 수집된 언어는 오브젝트 활성(object liveness)의 추적을 유지하기 위해 평균적으로 더 많은 메모리를 사용할 수 있다. 마지막으로 컴파일링된 C# 코드는 가상 머신에서 실행되며, 이는 자체 성능 및 메모리 사용에 영향을 미친다. 개인용 컴퓨터에서, 서버의 개발 버전은 HTTP 요청에 대한 응답을 시작하기 전에 1분이 소요될 수 있으며 최대 700MB의 메모리를 할당할 수 있다. 다른 구현 및 지원 기술을 사용하면 이 두 수치를 크게 줄일 수 있다.

도 4 및 5는 사용자 관점에서 타일 요청의 타이밍 및 제어 흐름에 대한 간략한 개요를 제공한다. 타일 요청의 제어 흐름은 기본 알고리즘의 단순화된 버전이다.

도 4에 도시된 바와 같이, 타임라인 메트릭은 요청(41), 첫 바이트에 대한 시간(TTFB)(42), 다운로드(43), 디코딩(44) 및 드로잉(45)에 대해 소요될 수 있는 상대 시간들을 포함할 수 있다. 다운로드(43)와 같은 느린 경로는 스트라이프 패턴으로 표시되고, TTFB와 같은 느린 동작은 더 두꺼운 스트라이프 패턴으로 표시된다. 요청(41)은 타일 요청의 제어 흐름 내에서 비교적 짧은 시간을 포함할 수 있는 반면, TTFB는 비교적 훨씬 더 긴 시간이 걸릴 수 있다. 첫 바이트에 대한 시간(TTFB)(42) 메트릭은 서버의 레이턴시를 나타내고 본 개시 내용의 나머지 부분과 관련하여 가장 중점을 둘 수 있는 메트릭이다. 다운로드(43)는 또한 제어 흐름 내에서 비교적 긴 시간이 걸릴 수 있는 반면, 디코딩(44) 및 드로잉(45) 단계는 비교적 빠르게 완료될 수 있다.

도 5는 사용자 관점에서 타일 요청의 타이밍 및 제어 흐름의 개요 방법(50)을 예시하는 흐름도이다.

단계(51)에서, 방법은 좌표(x, y, z)에서 타일을 요청하는 시청자를 포함할 수 있다. 이 요청은 HTTP 프로토콜을 통해 발송될 수 있다.

단계(52)에서, 도 3에 도시된 바와 같은 타일 서버 또는 백엔드(30)와 같은 서버는 요청을 수신할 수 있고 서버가 이미 요청된 타일을 준비했는지 여부를 결정할 수 있다.

단계(53a)에서, 서버가 슬라이드가 준비되지 않았다고 결정하면, 서버는 저장 디바이스로부터 슬라이드를 로딩할 수 있다.

단계(53b)에서, 대신에 서버가 슬라이드가 이미 준비되었다고 결정하면, 방법은 서버가 이미 요청된 좌표에 준비된 타일을 가지고 있는지 여부를 결정할 수 있다.

단계(54)에서, 슬라이드가 저장소로부터 로딩되었거나 서버가 이미 타일을 준비하지 않은 경우, 방법은 서버가 요청된 타일을 생성하고 그것을 저장하는 것을 포함할 수 있다.

단계(55)에서, 방법은 뷰어가 단계(54)에서 생성된 타일 또는 단계(53b)에서 서버에 의해 이미 처리된 타일을 서버로부터 수신하는 것을 포함할 수 있다.

슬라이드 뷰어의 예시적인 실시예는 두 가지 목표를 갖는다. 첫째, 슬라이드 뷰어는 빨라야 한다. 사용자는 FOV가 로딩되기 전에 오래 기다릴 필요가 없으며, 뷰어는 패닝 및 주밍 시 60FPS를 일정하게 유지해야 한다. 병리학자들은 레이턴시가 빛의 속도에 의해서만 제한되는 현미경에 익숙하다. 모범적인(exemplary) 뷰어와 함께, 이 경험을 가능한 한 가깝게 재현하기 위해 노력하는 것이 더 나을 수 있다. 최종 목표는 인지할 수 있는 레이턴시가 없도록 하는 것이다. 참고로 100ms의 응답 시간은 사용자에게 즉각적인 피드백 느낌을 주기 위한 상한선으로 간주된다.

둘째, 슬라이드 뷰어는 측정 가능할 필요가 있다. 모범적인 뷰어가 사용 중 수행하는 방식에 대한 정확한 메트릭을 제공할 수 있는 것이 중요할 수 있다. 기존 슬라이드 뷰어와 비교하려면 실제 로드를 나타내는 벤치마크 제품군이 필요하다.

일반적으로 슬라이드 뷰어와 같은 웹 애플리케이션에는 하나의 상수가 있다. JavaScript는 주로 웹 언어였으며 이전에는 브라우저가 기본적으로 실행되는 유일한 언어였다.

최근 브라우저는 웹 플랫폼을 대상으로 하는 어셈블리 코드의 일종인 WebAssembly(Wasm)를 운영하기 위해 가상 머신을 구현하기 시작했다. 보안은 브라우저에서 가장 중요하기 때문에, 완전히 샌드박스로 설계되었다. 머신을 통해 완전한 액세스 권한을 갖기 위해 웹사이트를 방문하는 것은 바람직하지 않다. Wasm의 이점 외에도: 이는 JavaScript보다 실행 속도가 훨씬 빠르다. 브라우저에서 JavaScript를 실행하려면 다음 단계가 실행될 수 있다:

a. 원본 JavaScript 소스를 다운로드.

b. JavaScript를 AST(Abstract Syntax Tree)로 파싱.

c. 구현마다 다를 수 있는, 머신 코드로 JavaScript를 컴파일링. 역사적으로 JavaScript는 완전히 해석되는 언어였다. JIT(Just In Time) 컴파일이 등장하면서, 이제 이를 컴파일링된 언어라고 부르는 것이 일반적이다.

d. 자바스크립트를 실행.

위의 단계들은 프로세스의 개요를 예시한다. 실제로 일부 단계들은 부분적으로 스킵될 수 있다. 예를 들어 브라우저의 JavaScript 엔진은 실행을 시작하기 위해 전체 JavaScript 소스를 파싱할 필요가 없다. 사실, 첫 번째 실행에 필요하지 않을 수 있는 코드의 전체 섹션을 빠르게 건너뛰기 위해 렉서(lexer)를 사용할 수 있다. 이것은 게으른 컴파일(lazy compilation)이라고 할 수 있다.

그러나 일부 단계들은 완전히 최적화될 수 없다. 최신 JavaScript 코드는 클라이언트로 발송되기 전에 축소되고 압축되지만, 원시 바이트코드보다 더 무겁다. 마찬가지로 어떤 경우에는 파싱이 스킵될 수 있지만, 이는 특정 포인트에서 수행되어야 한다. JIT 컴파일은 인상적인 성능을 제공할 수 있지만, 런타임 시 추가 단계가 필요하다.

바이트 코드로서 Wasm은 대부분의 이러한 문제에 대한 우아한 솔루션을 제공한다. 그러나 더 중요한 것은 Wasm이 컴파일 대상이라는 것이다. 이는 Wasm 백엔드를 구현하는 임의의 언어가 브라우저2에서 실행될 수 있음을 의미하며, 이는 웹 역사에서 매우 흥미로운 발전이다.

Rust는 많은 흥미로운 속성을 가진 새롭고 현대적인 언어이다: C 및 C++와 마찬가지로 이 언어는 프로그램의 메모리 소비 패턴을 정밀하게 제어할 수 있는 수동 메모리 관리 기능을 갖추고 있다.

그러나 C 및 C++와 달리 Rust는 메모리에 안전하다. 수명이라는 새로운 개념과 내장된 RAII(Resource Acquisition Is Initialization)가 포함된 덕분에 수동 메모리 관리의 복잡성과 변동성의 대부분이 컴파일러 자체에서 처리된다. 이것은 Rust의 정의 피쳐로 간주된다: 이는 기본적으로 안전하지 않은 것으로 증명된 동작을 금지하여 모든 종류의 프로그래머 오류를 제거한다.

Rust는 컴파일을 위해 LLVM(저레벨 가상 머신) 백엔드를 따른다. 따라서 Rust는 LLVM 컴파일러가 제공하는 많은 최적화를 활용할 수 있으며, 이는 결과적으로 C/C++에 상응하는 것보다 빠르고 때로는 더 빠른 코드가 생성될 수 있다. 또한 Linux, Windows, macOS 등을 포함한 모든 LLVM 대상이 기본적으로 지원될 수 있다. 이 목록은 또한 Wasm을 포함할 수 있다.

Rust는 또한, 이에 제한되는 것은 아니지만, 다음과 같은 현대 프로그래밍 언어에서 기대할 수 있는 많은 다른 피쳐를 포함한다: 고급 유형 시스템; 제로 비용 추상화; 패턴 매칭; 기능적 프리미티브; 비동기 프로그래밍; 내장 패키지 관리자 및 컴파일 툴체인; 내장 자동 코드 서식 및 린팅(linting); 및 자동 C 및 C++ 바인딩 생성. Rust는 여전히 빠르게 진화하고 있으며 엄격한 이전 버전과의 호환성 정책을 유지하면서 더 많은 개선 사항을 제공할 수 있다. Rust는 원시 성능과 반복 속도로 인해 인기가 높아졌다. 수동 메모리 관리와 기본 대상의 조합은 Rust가 얼마나 빨리 운영될 수 있는지에 대한 인위적인 경계가 없을 수 있음을 의미한다. 또한 Rust는 가비지 수집되지 않기 때문에 성능을 예측할 수 있다: "랙 스파이크(lag spike)" 효과가 없다. 중요한 것은 Rust가 안전하다는 것이다-모든 심각한 보안 버그의 70%가 메모리 안전 문제로 인해 발생한 것으로 나타났다. Rust는 또한 브라우저에서 운영될 수 있으며, 즉, 사용자는 웹 애플리케이션과 관련된 역사적 단점 없이 Rust 코드베이스 및 Wasm 성능의 모든 이점을 활용할 수 있다. 이것은 또한 브라우저와 기본 대상 간에 코드를 공유하는 것을 가능하게 한다. 전술한 내용에도 불구하고, 현재 존재하거나 미래에 개발될 임의의 원하는 언어 또는 코드 베이스가 본 발명의 실시예에 따라 웹 서버 및/또는 슬라이드 뷰어를 실행하는 데 사용될 수 있음이 고려된다.

도 6a는 슬라이드 뷰어(100)의 예시적인 실시예의 예시적인 개략도이다. 프런트엔드(60)에서, 코어 뷰어(61) 및 렌더링 로직은 Rust로 기록될 수 있는 반면, 상위 레벨 사용자 인터페이스 로직(62)은 React7를 사용하여 TypeScript6으로 기록될 수 있다. 타일 서버 또는 백엔드(70)로는 현재 가장 성능이 좋은 웹 서버 중 하나로 꼽히는 Actix 웹 서버와 같은 웹 서버(71)가 사용될 수 있다. 라우팅 로직(72), 이미지 디코딩 또는 슬라이드 판독기 로직(73) 및 파일 시스템 로직(74)은 모두 Rust로 기록될 수 있다. 그러나 이 예시적인 실시예의 범위 내에서 Aperio SVS 슬라이드에 대한 지원도 구현될 수 있다. 다른 슬라이드 형식에 대한 지원을 구현하려면 C++ 라이브러리(예를 들어, Philips iSyntax)에 대한 바인딩을 기록하거나 디코딩 로직을 수동으로 다시 구현해야 할 수 있다. 뷰어 코어 로직은 Rust로 기록되어 기본 렌더링과 같은 새로운 가능성을 열 수 있다. 프런트엔드와 타일 서버 코드베이스를 혼합하면, 뷰어의 기본 버전이 Linux, Windows 및 macOS의 윈도우에서 운영될 수 있다.

도 6b는 그러한 프로그램의 예시적인 아키텍처를 도시한다. 도 6b에서, 기본 애플리케이션(400)은 Rust로 기록되고 뷰어(401), 사용자 인터페이스(402), 슬라이드 판독기(403) 및 일반 파일 시스템(404)을 포함한다.

타일 요청의 분석

사용자가 좌표(z, x, y)라고 하는 좌표(x, y) 및 배율 레벨 z에서 타일을 요청하면, 타일 서버는 도 7a 및 도 7b에 도시된 절차를 시작한다. 이 절차는 여러 단계들과 분기들을 거쳐 요청된 타일에 대응하는 이미지를 사용자에게 제공하는 것으로 끝난다.

도 7a는 전술한 바와 같이 사용자로부터의 예시적인 타일 요청 절차(700)(예를 들어, 단계들(702 내지 710))를 예시하는 흐름도이다. 예시적인 타일 요청 절차(700)의 모든 단계들은 선택적일 수 있고 임의의 순서로 완료될 수 있다. 단계들 사이의 선 패턴의 차이로 표시되는 것처럼 각 단계의 발생도 다를 수 있다. 선의 대시 패턴 중 하나는 단계가 항상, 자주 또는 드물게 발생함을 나타내는 반면 연속적이고 끊김 없는 선은 단계가 매우 드물게 발생함을 나타낼 수 있다(즉, 단계들(705, 706 및 707)의 발생과 같이, 일반적으로 한 번만 발생).

예시적인 타일 요청 절차(700)에서, 사용자(701)는 서버로부터 타일을 요청할 수 있다. 특정 타일 요청은 병리 견본(specimen) 이미지와 연관된 디지털 이미지의 하나 이상의 타일들을 포함할 수 있거나 디지털 이미지의 단일 타일일 수 있다.

단계(702)에서, 절차는 타일 요청을 서버로 라우팅하는 것을 포함할 수 있다.

단계(703)에서 서버는 타일이 서버에 의해 생성되었는지 여부를 결정할 수 있다. 타일이 서버에 의해 생성된 경우, 절차는 후술하는 바와 같이 단계(709)로 진행될 수 있다.

타일이 아직 서버에 의해 생성되지 않았다면, 서버는 단계(704)에서 요청된 타일과 관련된 슬라이드가 캐시에 있는지 여부를 결정할 수 있다. 하나의 경우에, 요청된 타일이 생성되지 않았지만 WSI가 캐시에 있는 경우, 서버는 타일에 대응하는 영역을 판독할 수 있고 단계(708)에서 설명된 바와 같이 결과 이미지 파일을 사용자에게 제공할 수 있다. 이 파일은 단계(710)에서 설명된 바와 같이 클라이언트가 동일한 타일을 다시 요청하는 경우에 저장되며, 이 경우 절차는 영역 디코딩 단계를 완전히 바이패스할 수 있다.

요청된 타일과 관련된 슬라이드가 캐시에 없으면, 서버는 단계(705)에서 슬라이드가 로컬 파일 시스템(FS)에 있는지 여부를 결정할 수 있다. 슬라이드가 로컬 파일 시스템에 있는 경우 절차는 아래 설명된 대로 단계(707)로 진행될 수 있다.

슬라이드가 로컬 파일 시스템에 없으면, 서버는 단계(706)에서 슬라이드를 로컬 파일 시스템으로 다운로드할 수 있다. 슬라이드가 로컬 파일 시스템으로 다운로드되면 서버는 단계(707)에서 슬라이드를 열 수 있다.

단계(708)에서 서버는 타일 영역을 판독할 수 있고, 단계(710)에서 타일 파일 저장을 진행하거나 단계(709)에서 사용자(701)에게 파일을 다시 제공할 수 있다.

사용자가 처음으로 슬라이드를 요청하거나 슬라이드가 캐시를 떠나고 로컬 FS에서 지워졌다는 마지막 요청 이후 충분한 시간이 경과한 경우, 서버는 원격 FS(예를 들어, 아마존 웹 서비스(AWS) S3 버킷)에서 로컬 FS로 슬라이드를 검색하고 열어야 할 수 있다. 이 동작은 클라이언트가 WSI와 관련된 메타데이터를 처음 검색할 때 한 번만 발생할 수 있다.

동일한 예시적인 타일 요청 절차(700)를 예시하는 도 7b에 설명된 단계들은 각각의 단계와 관련된 시간 비용을 추가로 예시할 수 있으며, 이는 발생된 레이턴시라고 한다. 이 레이턴시는 사용자가 TTFB 메트릭으로 경험하게 될 전체 요청의 전체 레이턴시를 형성하기 위해 합산된다.

각 단계에 의해 발생하는 레이턴시는 각 단계 주위에 패턴화된 선으로 표시될 수 있다. 예를 들어, 점선 패턴이 있는 선은 단계의 레이턴시가 1밀리초 미만임을 나타낼 수 있는 반면, 가는 선은 1 내지 10밀리초 사이의 레이턴시를 나타낼 수 있다.

도 8은 모든 단계에서 발생한 레이턴시를 보여줌으로써 도 7을 보완한다. 가장 빠른 경로는 타일이 서버에 의해 이미 생성되었고(단계(703)에서 서버에 의해 결정됨) 서비스만 필요할 때일 수 있다. 이 경우 타일은 FS에 있으며 사용자에게 직접 스트리밍될 수 있다.

그러나 가장 빈번한 경우는 타일이 FS에 존재하지 않고 WSI에서 생성되어야 하지만 슬라이드가 캐시에서 사용 가능한 경우이다. 가장 빠른 경로와 비교할 때 이 경우에는 다음과 같은 두 가지 추가 단계가 필요하다:

a. 차단 중인 WSI에서 타일 영역을 디코딩.

b. 비차단중인 FS에 파일 저장: 동작이 파일 제공과 병렬로 발생한다.

마지막으로, 슬라이드가 캐시에 존재하지 않고(단계(704)에서 서버에 의해 결정됨) 로컬 FS에 존재하지 않을 가능성이 있는 드문 경우에, 서버는 FS로부터 WSI 파일을 검색할 필요가 있을 수 있다(단계(706)에서와 같이). 파일이 매우 크기 때문에 이는 몇 초 정도 걸릴 수 있다. 유익하게도 이 경우는 일반적으로 사용자가 슬라이드를 처음 요청할 때 한 번만 적중하므로 긴 레이턴시가 허용될 수 있다.

이 알고리즘은 도 5에 도시된 것과 유사할 수 있다. 나의 예시적인 실시예 구현예의 더 낮은 오버헤드 덕분에, 그 평균 레이턴시는 아래에서 설명되는 바와 같이 더 낮을 수 있다.

영역 디코딩

WSI의 영역을 디코딩하는 절차는 이미지의 형식에 전적으로 의존할 수 있다.

WSI의 이러한 형식들 중 하나는 SVS(ScanScope Virtual Slide) 이미지의 형태일 수 있고, 이는 TIFF 이미지 컨테이너 형식을 사용한다. 이러한 이미지는 다음 부분들로 구성된다:

a. 이미지 헤더의 레지스트리를 가리키는 헤더;

b. 이미지 메타데이터의 레지스트리를 가리키는 이미지 헤더;

c. 폭, 높이, 설명, 측색(colorimetry) 정보 등과 같은 세부 정보를 포함하는 이미지 메타데이터; 및

d 다음과 같은 두 가지 다른 형식들일 수 있는, 이미지 데이터:

i. 픽셀들의 연속된 로우들. 이 로우들을 수직으로 함께 적층하면 이미지가 다시 조립된다. 이 형식은 작은 이미지에 사용될 수 있다. SVS에서는 이들은 라벨, 썸네일 및 매크로 이미지이다.

ii. 위에서 아래로, 왼쪽에서 오른쪽으로 나열된, 타일들. 이 경우 이미지는 직사각형 타일들의 정규 그리드로 절단되며, 이는 별도로 인코딩될 수 있다. 이 형식은 이러한 큰 이미지의 부분 디코딩을 허용하기 위해 이미지의 다양한 배율 레벨들에 사용될 수 있다. 이 원리는 도 1에 예시되어 있다.

SVS 파일의 이미지 데이터는 세 가지 다른 방식들로 인코딩될 수 있다. 라벨 이미지는 LZW 압축 알고리즘을 사용하여 인코딩될 수 있으며, 썸네일 및 매크로 이미지는 JPEG로 인코딩될 수 있다. 베이스라인 이미지 및 상이한 배율 레벨들은 JPEG 또는 JPEG2000으로 인코딩될 수 있다.

타일 서버에 의해 노출된 배율 레벨 및 타일 치수는 WSI에 저장된 것과 다를 수 있으므로, 타일을 생성할 목적으로 이미지 영역을 디코딩하는 것은 단순히 올바른 배율 레벨에서 올바른 타일을 인덱싱하는 것보다 더 복잡하다:

a. 먼저, 절차는, 가능하다면, 더 높은 배율 파워의 사용자가 요청한 배율 파워에 가장 근접한 배율을 갖는 WSI 레벨을 선택할 수 있고: 낮은 배율 파워를 선택하면 정보가 손실될 수 있다.

b. 그런 다음, 요청된 영역을 커버하는 모든 WSI 타일들은 선택된 WSI 레벨의 배율 파워로 투영된 요청된 영역의 크기와 동일한 크기의 버퍼로 블리트된다(blitted).

c. 그런 다음 이 버퍼는 요청된 영역의 치수로 선형적으로 리샘플링된다. 클라이언트가 요청한 레벨의 배율 파워가 선택된 WSI 레벨의 것과 동일한 경우 이 단계가 필요하지 않을 수 있다.

마지막으로, 일단 영역이 디코딩되고 그것이 클라이언트에 제공될 수 있기 전에, 그것은 브라우저가 이해할 이미지 형식으로 다시 인코딩될 필요가 있을 수 있다. 이미지 형식에 대한 자세한 내용은 아래에서 확인할 수 있다. 예시적인 타일 서버에서, 이미지는 75의 품질 설정으로 JPEG로 인코딩된다.

이러한 일련의 동작들은 하나의 너무 많은 이미지를 디코딩하고 잠재적으로 이미지 크기를 조정하고 최종 결과를 인코딩하는 것을 포함할 수 있다. 이것은 10에서 100ms 사이의 어느 것이나 해당할 수 있으며, 때로는 병리학적인 경우에 더 오래 걸릴 수 있다. 이러한 단계들의 성능은 사용된 인코딩, 디코딩 및 크기 조정 알고리즘에 따라 달라진다. 타일 서버의 예시적인 실시예에서, MozJPEG5 이미지 디코더 및 인코더는 현재 최고의 Rust 구현보다 적어도 2배 빠르기 때문에 사용될 수 있다.

이미지 형식

다음과 같은 다양한 컨테이너 형식과 압축 기술을 사용하는 다수의 WSI 형식들이 존재한다: SVS(.svs); Philips iSyntax(.isyntax); Hamamatsu(.vms, .vmu, .ndpi); Leica(.scn); MIRAX(.mrxs); Sakura(.svslide); 및 기타 TIFF 변형.이러한 형식은 대응하는 제조업체의 스캐너 출력일 수 있다. 일부 슬라이드 뷰어는 원본을 저장하고 공급업체 프레임워크와 OpenSlide 오픈 소스 라이브러리를 사용하여 사용자가 슬라이드를 열고 볼 때마다 이미지를 열고 판독할 수 있다. 그러나 이 프로세스에는 여러 가지 단점이 있을 수 있다.

프레임워크가 슬라이드를 판독하기 위해서는, 슬라이드가 로컬 FS에 있어야 할 수도 있다. 타일을 다운로드하거나 원격 FS를 마운트하면 프로세스에 레이턴시가 추가된다. 또한 이러한 파일은 매우 크기 때문에 핫 스토리지(hot storage)에 보관하는 비용이 비경제적이다.

둘째, 이들 프레임워크는 각각 자신의 구현, 거동 및 API를 가질 수 있다. 이로 인해 그들 사이의 성능 프로필이 다를 수 있다. 결과적으로 일부 슬라이드 형식은 다른 형식보다 로딩하는 데 시간이 오래 걸리므로 사용자 경험이 슬라이드 형식 간에 다를 수 있다. 이는 또한 타일 서버의 복잡성을 크게 증가시키며, 이는 그들 모두를 호출해야 할 수도 있다.

마지막으로, WSI 형식에 의해 사용되는 압축 기술에 대한 제어가 적다. 일부 파일 형식은 오늘날 최적화되지 않은 오래된 압축 기술을 사용하므로 필요한 것보다 더 많은 공간을 차지하거나 디코딩하는 데 더 많은 처리 시간을 사용한다.

압축 방법

SVS와 Philips iSyntax에서 사용하는 주요 압축 기술은 DCT(Discrete Cosine Transform)(JPEG) 및 DWT(Discrete Wavelet Transform)(JPEG2000)이다. 둘 모두 무손실 압축(JPEG 무손실 확장을 통한 JPEG)을 지원하지만 손실 형식으로 사용된다.

JPEG2000은 JPEG보다 최신 기술이며 동일한 이미지 품질 레벨에서 JPEG보다 더 나은 압축률을 제공한다. 그러나 이는 계산상 비용이 더 많이 들며, 반복되는 인코딩 및 디코딩과 관련된 시나리오에서는 적합하지 않다. 또한 JPEG2000은 20년 전에 등장한 이후 널리 채택되지 않았으며 조직병리학 슬라이드 저장소와 같은 드문 경우에만 사용된다. 마지막으로 JPEG2000은 브라우저에서 기본적으로 지원되지 않지만 JPEG는 지원된다.

압축 방법

보다 최근의 이미지 압축 기술은 다음을 포함한다:

a. VP8 코덱을 사용하는 WebP. 이는 오늘날 가장 성능이 뛰어난 형식은 아니지만, 버전 14에서 이를 지원할 수 있는, Safari를 제외한 모든 주요 브라우저에서 지원된다.

b. HEVC 코덱을 사용하는 HEIF. 현재 모든 브라우저에서 지원되지 않는다.

c. AV1 코덱을 사용하는 AVIF. 현재 모든 브라우저에서 지원되지 않지만 Chrome 및 Firefox에서 지원할 예정이다.

d. FLIF. 모든 브라우저에서 지원되지 않는다.

e. JPEG XL. 확정되지 않았으며, 모든 브라우저에서 지원되지 않는다.

전술한 모든 형식은 일반적인 경우에 JPEG를 능가할 수 있으며, 종종 JPEG 2000을 능가할 수도 있다.

본 개시의 경우, JPEG XL이 가장 유망한 이미지 포맷일 수 있다. JPEG(Joint Photographic Experts Group)의 지원을 받아, 다음과 같은 속성을 약속한다:

a. 동급 최고의 이미지 압축률 및 이미지 품질;

b. 다중스레딩 및 SIMD(Single Instruction Multiple Data)에 적합한 설계 덕분에 빠른 인코딩 및 디코딩 성능;

c. JPEG 디코더와의 일부 이전버전 호환성(backwards compatibility); 및

d. 레거시 JPEG 파일의 무손실 트랜스코딩.

또한 JPEG XL은 Brunsli13 JPEG 리패커(repacker)를 포함할 수 있으며, 이는 원본 JPEG를 바이트 단위로 복구하면서 파일 크기를 줄일 수 있다. 본 개시의 예시적인 실시예가 저장하는 레거시 JPEG 이미지 스트림의 양을 고려하면, 그러한 포맷을 채택하는 것은 상당한 절약을 초래할 수 있다.

위에서 언급된 바와 같이, WebP를 제외하고 Safari를 제외하고, 현재 이러한 새로운 형식들 중 어느 것도 브라우저에서 기본적으로 지원되지 않는다. 그러나 이것이 반드시 그들의 사용을 제거하는 것은 아니다: Wasm 덕분에, 브라우저에서 이러한 형식 중 일부를 여전히 디코딩할 수 있다. 특히 참조 JPEG XL 구현은 WebAssembly를 지원한다.

브라우저의 기본 JPEG 디코더와 달리, Wasm 구현은 멀티스레딩 또는 SIMD를 이용할 수 없을 수 있는데, 이러한 피쳐는 현재 브라우저에서 부분적으로만 이용가능하기 때문이다. 따라서 이러한 구현이 빠른 클라이언트 측 디코딩에 필요한 성능을 제공할 수 있는지 여부는 불분명하다. 그럼에도 불구하고 이러한 형식 중 일부는 일반적으로 오늘날 사용 가능한 최고의 JPEG 디코더보다 빠르기 때문에 이것이 가능할 수 있다.

프리-타일링

타일 요청의 구조는 위에서 설명되었으며, 요청된 타일이 이미 생성되었을 때 더 빠른 경로가 발생한다고 설명된다. 이 아이디어가 더 나아가 사용자가 모든 타일들이 이미 생성된 것으로 예상하면, 타일 서버의 아키텍처가 단순화될 수 있다. 실제로 아키텍처는 정적 파일 서버, 즉 절대 변경되지 않는 콘텐츠를 제공하는 것이 목적인 서버가 되는 포인트까지 단순화될 수 있다. 이러한 서버는 요청이 매우 빠르도록 고도로 최적화되어 있을 수 있다. 이러한 서버의 아키텍처는 도 8에 예시되어 있다.

도 8은 서버 아키텍처의 예시적인 실시예를 도시하는 작업흐름이다. 작업흐름은 서버로부터 파일을 요청할 수 있는 사용자(801)로 시작할 수 있다. 단계(802)에서, 작업흐름은 파일이 서버에 존재하는지 여부를 결정하는 서버를 포함할 수 있다. 사용자가 존재하지 않는 타일을 요청하면 서버에서 해당 파일을 찾을 수 없으며 클라이언트에 오류(803)가 발송된다. 그러나 파일이 존재하는 경우 서버는 단계(804)에서 파일을 제공할 수 있다.

핫 경로(예를 들어, 단계들(802 및 804) 사이의 프로세스)는 파일을 직접 제공하고 있다. 그러나 이 경우는 클라이언트가 어떤 타일이 이용 가능한지 정확히 알고 있기 때문에 타일 서버의 정상적인 사용에서는 바람직하지 않을 수 있다.

이러한 아키텍처는 여전히 일부 포인트에서 타일이 생성되는 것을 포함한다. 이는 슬라이드 수집 파이프라인(slide ingestion pipeline)의 책임일 수 있으며 연관된 서버에서 슬라이드를 이용할 수 있게 되는 즉시 발생할 수 있다. 그렇게 함으로써, 가능한 한 빨리 사용자가 사용할 수 있게 된다.

사전-타일링이 적합한 솔루션처럼 보일 수 있지만 여전히 몇 가지 단점이 있다:

a. 사전-타일링은 슬라이드가 연결된 서버에 도착하는 시간과 사용자가 슬라이드를 사용할 수 있는 시간 사이에 약간의 추가 레이턴시를 수반한다. 그러나 이러한 프로세스는 연속적이고 자동화될 수 있고 사용자가 즉시 결과를 필요로 하지 않을 수 있으므로 실제로는 문제가 되지 않을 수 있다. 또한 이론상 타일을 아직 사용할 수 없을 때, 이는 원래 타일 서버 아키텍처로 팔백(falling back)함으로써 완화될 수 있다. 마지막으로 타일 생성 프로세스가 충분히 빠르면, 이는 수십 초만 지연될 수 있다.

b. 주문형 타일링과 달리, 사전-타일링은 슬라이드의 생성된 모든 타일들을 항상 저장하는 것을 의미할 수 있다. 실제로 이것은 슬라이드를 저장하는 데 필요한 공간의 양을 두 배로 늘리고 결과적으로 저장 비용을 증가시킨다. 결과적으로 타일들을 생성하는 데 필요한 처리 시간도 최대화된다.

뷰어 아키텍처

일부 실시예에서, 뷰어는 2개의 메인 루프들에서 운영될 수 있다. 하나의 루프는 백그라운드 루프이고, 이는 이미지 요청, 디코딩, 그래픽 메모리 로딩, 캐시 정리(pruning) 또는 캐시 정렬, 동작을 처리한다. 두 번째 루프는 디스플레이에 대한 렌더링만 처리할 수 있는 렌더링 루프이다.

그들의 실행 동안, 이들 2개의 루프들은 뷰어의 상이한 컴포넌트들을 호출할 수 있다. 코어는 타일 가시성과 디스플레이에 그들을 그리는 데 필요할 수 있는 드로잉 호출(draw call)을 계산한다. 렌더러는 2D Canvas, WebGL 또는 임의의 기본 그래픽 API가 될 수 있는 기본 그래픽 구현에 대한 바인딩 역할을 한다. 로드는 원격 소스(웹) 또는 로컬 파일 시스템(네이티브)에서 타일을 비동기식으로 로딩한다.

캐시는 타일 이미지와 GPU 텍스처를 저장하고, 때때로 최대 점유율에 도달하면 스스로 정리 또는 정렬한다. 캐시에 저장된 타일은 다음 두 가지 상태들 중 하나로 저장될 수 있다: (1) 타일 요청 상태 또는 (2) 완전히 로딩된 상태. 타일 요청 상태에서, 타일은 예를 들어 타일 서버 또는 다른 저장 디바이스로부터 로딩되는 프로세스에 있을 수 있다. 완전히 로딩된 상태에서, 타일 이미지가 완전히 로딩되었을 수 있다. 또한 예를 들어 이전 그룹으로부터의 타일이 아직 완전히 로딩되지 않은 경우, 뷰어는 다음 그룹으로부터의 타일을 저장할 수 없다.

추가적으로, 뷰어가 운영되는 플랫폼에 의존하는 제3 루프가 있을 수 있다: 마우스 이벤트 및 키보드 이벤트와 같은 사용자 이벤트를 처리하는, 이벤트 루프. 브라우저에서는, 이는 JavaScript 엔진에 의해 자동으로 처리될 수 있다. 이벤트 루프는 FOV 변경이 적용되는 곳이다: 사용자가 디스플레이를 클릭하고 드래그하면, 이벤트가 발생하고 애플리케이션 로직이 그에 따라 FOV를 업데이트한다.

도 9는 이들 루프들 모두의 흐름도의 요약(900)이다.

백그라운드 루프(901)

백그라운드 루프(901)는 대부분의 백그라운드 처리가 일어나는 곳일 수 있다. 이는 다음 프레임이 시작되기 전에 프로세스에 여유 시간이 있을 때마다 운영되도록 스케줄링될 수 있다. 이는 백그라운드 스레드에서 스케줄링될 수도 있다. 백그라운드 루프(901)는 다음과 같이 진행될 수 있다:

FOV(903)가 주어지면, 백그라운드 루프(901)는 그 안에 현재 보이는 타일들을 계산할 수 있다. 이것은 단계(905)에서 어느 타일이 보이는지를 결정하는 뷰어의 코어 프로세서에 의해 달성될 수 있다.

예를 들어, 뷰어의 FOV가 변경될 때, 뷰어는 다음의 우선 순위에 따라 캐시에서 타일들을 그룹으로 로딩할 수 있다:

a. FOV의 배율 인자보다 크거나 같을 수 있는 배율 레벨에서 FOV 내의 타일들;

b. FOV의 배율 인자보다 크거나 같을 수 있는 배율 레벨에서 FOV와 접하는 타일들;

c. 더 높은 배율 레벨에서 FOV 내의 타일들; 및

d. 더 낮은 배율 레벨에서 FOV 내의 타일들.

또한, 뷰어가 캐시로부터 타일을 로딩할 때, 타일이 이전에 캐시에 저장되어 있지 않은 경우, 타일은 자동으로 캐시에 저장될 수 있다.

예를 들어, 캐시에서 검색된 타일은 FOV의 배율 레벨 이상인 배율 레벨을 가질 수 있다. 그러나, 일부 실시예에서, 임의의 큰 배율 레벨의 무한대에 대해 타일이 계산되지 않을 수 있기 때문에 이것이 항상 가능한 것은 아니다. 이러한 상황에서 예를 들어 FOV의 배율 인자가 이용 가능한 최대 타일 배율 레벨을 초과할 수 있는 경우 이용 가능한 가장 큰 타일 배율 레벨로부터의 타일이 캐시로부터 검색될 수 있다.

FOV의 배율 인자는 연속적인 값일 수 있다. 예를 들어 FOV 배율 인자는 0.1, 2.0이거나 0.123456... 등일 수 있다. 타일 또는 WSI의 배율 레벨은 타일들의 세트일 수 있으며, 타일들의 세트는 예를 들어 1, 2, 4, 8 등과 같이 불연속적이고 제한된 배율 인자에 해당할 수 있다. 예를 들어 FOV의 배율 인자가 2이면, 배율 레벨이 2 이상인 타일이 로딩될 수 있다. 단, 그러한 타일이 존재하지 않는 경우, 이용 가능한 가장 큰 배율 인자를 갖는 배율 레벨의 타일이 로딩될 수 있다. 이러한 프로세스는 타일 서버 및/또는 뷰어에서 발생할 수 있다.

단계(909)에서 결정될 수 있는 바와 같이, 뷰어의 캐시에서 임의의 타일(907)이 발견되지 않으면, 캐시는 그들의 이미지를 비동기적으로 로딩하기 시작할 수 있다. 이미지는 뷰어의 로더에 의해 로딩될 수 있으며, 이는 단계(912)에서 이미지(910)를 요청할 수 있다. 이미지(910)는 요청이 이루어진 후에 캐시로 다시 발송될 수 있다.

이러한 타일(907) 중 임의의 타일이 캐시에 로딩된 이미지(910)를 갖지만 관련 텍스처(911)가 없는 경우, 이는 단계(913)에 도시된 바와 같이 뷰어의 GPU에 텍스처(911)를 비동기적으로 업로드하기 시작할 수 있다.

일단 모든 요청이 이루어지면, 필요하다면, 캐시는 단계(914)에서 미사용 타일 이미지 및 GPU 텍스처의 그래픽 및 시스템 메모리를 해제하기 위해 정리될 수 있다.

렌더 루프

렌더 루프(912)는 FOV(903)에 대한 변경을 반영하도록 디스플레이를 업데이트할 책임이 있을 수 있다. 렌더 루프(912)는 디스플레이 프레임당 한 번 운영하도록 스케줄링될 수 있으며, 이는 대부분의 모니터에서 초당 60회(60 FPS)이다. 렌더 루프(912)는 다음과 같은 프로세스를 가질 수 있다:

FOV(903)가 주어지면, 렌더 루프(912)는 FOV(903) 내에서 현재 보이는 타일을 계산할 수 있다. 프로세스는 단계(915)를 포함할 수 있으며, 여기서 뷰어의 렌더링은 어떤 타일이 보이는지 결정할 수 있다. 캐시에서 어떤 타일도 발견되지 않으면, 렌더 루프(912)는 대신 타일의 표면 영역을 덮는 다른 배율 레벨의 타일을 찾을 수 있다.

그 다음 렌더러는 단계(916)에 도시된 바와 같이 필요에 따라 텍스처를 검색할 수 있다. 렌더링 루프는 드로우 호출(917)을 생성할 수 있으며, 이는 단계(918)에 도시된 바와 같이 디스플레이에서 타일의 텍스처를 드로잉할 위치를 설명하고 실제로 타일을 실행하는 책임이 있는 렌더러에게 그들을 발송한다.

렌더링 기술

제네릭(generic)을 사용하여, 뷰어는 일부 또는 모든 렌더링 로직을 외부 구현에 위임할 수 있다. 이를 통해 예를 들어 기존 코드를 변경하지 않고 새로운 플랫폼을 지원하기 위해 새로운 그래픽 구현을 신속하게 추가할 수 있다.

역사적으로 2D 캔버스는 모든 주요 브라우저에서 지원되는 최초의 JavaScript 그래픽 API였다. 이는 그것을 가장 휴대하기 쉽게(portable) 만든다. 그러나 이름에서 알 수 있듯이, 이는 2D 컨텍스트만 지원할 수 있다. 따라서 이는 많은 응용 프로그램에 적합하지 않을 수 있다. 또한 높은 레벨의 추상화로서, 이는 성능 및 사용자 지정 가능성을 희생하면서 그래픽 렌더링의 복잡성을 많이 숨길 수 있다. 뷰어는 일부 실시예에서 2D 애플리케이션이기 때문에 캔버스는 이를 렌더링하는 데 특히 적합할 수 있다.

WebGL은 브라우저 컨텍스트에서 실행되도록 설계된 OpenGL ES 2.0 표준의 구현이다. 이는 3D 그래픽 렌더링을 위한 JavaScript API를 노출시키므로, 2D 그래픽에도 적합하다. 이는, 동작이 구성되고 메모리가 관리되는 방식을 더 잘 제어할 수 있는, 캔버스보다 낮은 레벨의 API이다. OpenGL보다 얇은 레이어인, WebGL은 대부분의 플랫폼에서 하드웨어 가속이라는 이점을 가지며, 이는 일반적으로 캔버스 API보다 성능이 더 좋다.

OpenGL과 유사하게, WebGL 프로그램은 작업을 스케줄링하는 JavaScript 코드와 사용자의 GPU에서 직접 실행되는 GLSL ES(OpenGL ES Shading Language)로 기록된 셰이더의 구성이다. WebGL 백엔드는 캔버스 구현보다 비교적 훨씬 더 복잡하다. 그러나 캔버스 대안에 비해 WebGL이 제공하는 많은 이점은 특정 상황에서 더 나은 선택이다. 앞서 언급된 바와 같이 WebGL은 캔버스 API보다 성능이 뛰어나고 메모리 효율성이 높다. WebGL은 뛰어난 서브 픽셀 렌더링을 지원하지만 캔버스 구현의 지원은 브라우저마다 다르다. 부동 소수점 정밀도 문제 때문에, 이로 인해 서로 옆에 있는 타일을 합성할 때 눈에 보이는 타일 이음새가 발생할 수 있으며 이러한 특수한 경우를 처리하기 위해 렌더러 부분에서 더 많은 로직이 필요할 수 있다. WebGL API는 거의 1:1로 OpenGL API에 매핑되므로, 이는 네이티브 컨텍스트와 브라우저 컨텍스트 간에 구현이 공유될 수 있음을 의미한다. 또한 셰이더는 후처리 및 고급 합성을 이미지에 추가하는 매우 효율적인 방법을 제공하며, 이는 이미지 뷰어의 기본 피쳐이다.

가장 큰 브라우저 버전 영역을 지원하기 위해, 웹 개발 세계에서 빈번한 패턴은 WebGL 구현으로 기본 설정될 수 있으며 WebGL이 현재 브라우저에서 지원되지 않는 경우 캔버스 구현으로 대체될 수 있다. 그러나, 이는 캔버스가 지원하는 WebGL의 피쳐들의 서브세트만 사용하는 것을 포함할 수 있으며 프로그램에 복잡한 셰이더 코드가 있는 경우 작동하지 않을 수 있다.

WebGL 2.0은 OpenGL ES 3.0 표준을 기반으로 하는 새로운 사양이다. 그러나, 이는 모든 주요 브라우저에서 지원되는 것은 아니며 Safari가 주목할만한 홀드아웃이다.

WebGPU는 더 낮은 레벨의 그래픽 기능을 웹 애플리케이션에 노출하는 곧 출시될 API이다. 이는 Direct3D(Windows) 및 Metal API에도 효율적으로 매핑하는 것을 목표로 부분적으로 Vulkan 사양을 기반으로 한다.

WebGPU는 오늘날 대부분의 브라우저에서 바로 사용할 수 없지만, 최신 브라우저의 실험적 설정에서 활성화하는 것은 여전히 가능하다. WebGPU는 그래픽 프로그래밍 세계에서 유망한 발전을 나타낸다: 모든 그래픽 백엔드를 대상으로 하여 다양한 플랫폼에서 원활하게 작동할 수 있는 통합 API의 약속이다.

본 발명은 wgpu5 Rust 크레이트를 사용하여 WebGPU 백엔드를 구현한 실시예를 포함한다. 현재, 이 백엔드는 뷰어의 기본 버전에만 파워를 공급한다. 하나의 구현으로, 네이티브 뷰어는 브라우저에서 OpenGL, WebGL 및 향후 WebGPU 구현을 대상으로 할 수 있다는 약속과 함께 Linux, Windows 및 macOS에서 운영될 수 있다.

훨씬 더 낮은 레벨의 API를 대상으로 하므로, 개시된 WebGPU 구현은 캔버스 또는 WebGL 구현보다 더 복잡하다. 그러나 WebGPU API는 잘 설계되었으며 wgpu 크레이트에서 제공하는 추상화로 인해 비교적 사용하기 쉽다. 향후 몇 년 동안 WebGPU 개발은 더 나은 도구와 지원이 가능해짐에 따라 더욱 쉬워질 것이다.

최적화 기술

성능은 핵심 컴포넌트일 수 있으며 슬라이드 뷰어의 예시적인 실시예에서 기술적 선택을 가이딩하는 역할을 한다. 그러나 제품 제약으로 인해, 이러한 선택 중 일부는 이미 이루어졌다. 아마도 가장 중요한 것은 뷰어가 웹 애플리케이션일 수 있다는 것이다.

뷰어가 웹 애플리케이션인 경우, 뷰어에서 사용할 수 있는 기술의 수가 제한될 수 있다. 그러나 부분적으로는 WebAssembly, WebGL 및 잠재적인 WebGPU로 인해, 이는 여전히 고성능 그래픽 웹 애플리케이션을 기록할 수 있다. 그럼에도 불구하고 이러한 애플리케이션의 일부는 여전히 네트워크를 통해 통신해야 하므로 브라우저의 네트워크 스택과 클라이언트의 인터넷 연결 모두에 의해 제약을 받는다. 웹 애플리케이션은 아마도 웹 API에만 액세스할 수 있는 할당된 브라우저의 메모리에 맞아야 하는 필요성으로 인해 더욱 제약을 받을 수 있다.

캐시 휴리스틱(Cache Heuristics)

브라우저, 더 넓은 의미에서 사용자의 컴퓨터는 사용 가능한 메모리 양이 제한될 수 있다. 따라서 전체 슬라이드 이미지를 사용자 디바이스에 저장하는 것과 유사하므로, 사용자 세션의 일부로 로딩될 모든 이미지를 메모리에 저장하는 것이 불가능할 수 있다. 이러한 이미지는 기가바이트 규모로 인코딩되고 수십 기가바이트 규모로 디코딩될 수 있다. 따라서 위에서 언급된 바와 같이 캐시 점유를 관리 가능한 크기로 유지하기 위해 캐시 정리 또는 캐시 정렬 휴리스틱을 구현해야 할 수 있다.

캐시 정리 또는 정렬은 현재 캐시에 저장되어 있는 각 타일의 우선 순위를 결정하고 필요에 따라 캐시를 정리하는 동작을 의미할 수 있다. 캐시가 최대 점유율을 초과하면 캐시 정렬이 트리거될 수 있다. 예를 들어, 뷰어는 캐시가 완전히 찼을 때 최대 용량에 도달했다고 결정할 수 있다. 대안적으로, 뷰어는 최대 점유율이 캐시 용량의 특정 레벨임을 결정할 수 있다. 캐시가 최대 점유율 및/또는 이의 초과일 때, 캐시의 내용을 검사하여 가장 낮은 우선 순위를 갖는 타일을 결정할 수 있다. 우선 순위가 가장 낮은 타일은 캐시가 최대 점유율 이하가 될 때까지 캐시에서 제거될 수 있다.

일 실시예에서, 캐시에서의 타일 우선순위의 순서는 다음을 포함할 수 있다:

a. FOV의 배율 인자보다 크거나 같을 수 있는 배율 레벨에서 FOV 내의 타일들;

b. FOV의 배율 인자보다 크거나 같을 수 있는 배율 레벨에서 FOV와 접하는 타일들;

c. 더 높은 배율 레벨에서 FOV 내의 타일들;

d. 낮은 배율 레벨에서 FOV 내의 타일들; 및

e. 다른 모든 타일들.

다른 실시예에서, 각각의 캐시 사이클 동안, 타일은 3개의 카테고리로 분류될 수 있다:

a. 현재 디스플레이에 직접 필요한 타일. 도 2를 다시 보면, 이들은 "활성"으로 표시된 타일(11)이다. 이러한 활성 타일(11)은 도 11에서도 볼 수 있다.

b. 도 10a에 도시된 바와 같이, 슬라이드 이미지가 처음 로딩되면, 이는 전체가 표시될 수 있다. 이 첫 번째 표시 중에, 타일들의 세트가 낮은 배율 레벨로 로딩될 수 있다. 이러한 타일은 올바른 배율 레벨의 타일이 로딩되고 대신 무언가를 표시해야 할 때 보간 목적으로 사용될 수 있다. 도 10b는 고배율 타일이 로딩되는 동안 저배율 타일이 보간되어 표시되는 예를 보여준다.

c. 다른 타일은 중요도의 내림차순으로 4개의 서브카테고리로 정렬된다:

i. FOV에 직접 접하는 타일;

ii. FOV 내에 있지만 배율 레벨이 더 높은 타일;

iii. FOV 내에 있지만 배율이 낮은 타일;

iv. 다른 모든 타일.

카테고리 1 및 2에 속하는 타일은 즉시 필요하거나 보간 목적을 위해 결국 항상 필요할 수 있기 때문에 항상 메모리에 보관될 수 있다. 카테고리 3에 속하는 타일은 최대 점유율까지만 유지될 수 있으며, 그 이후에는 우선 순위가 낮은 것으로 간주되는 타일이 정리되기 시작한다.

또한 이러한 휴리스틱은 디코딩된 이미지 이상에 적용된다. 실제로 이미지 요청은 카테고리 3의 요청이 카테고리 1과 2의 요청과 동시에 실행될 수 없다는 제약이 추가된 동일한 휴리스틱을 따른다. 우선 순위가 높은 타일에 대한 요청이 들어오면 우선 순위가 낮은 타일에 대한 계류 중인 요청이 취소된다. 이렇게 하면 필요한 타일에 대한 요청이 항상 우선 순위가 될 수 있다.

타일 프리로딩

도 2는 뷰어가 특정 FOV(12)를 렌더링하기 위해 로딩할 수 있는 활성 타일(11)을 나타낸다. 그러나 예시적인 실시예는 뷰어가 사용자가 다음에 방문할 것이라고 예측하는 타일을 로딩하기 시작할 수 있다.

도 11은 작동 중인 이러한 거동의 예를 보여준다. 슬라이드 뷰어는 사용자가 FOV(12)를 어느 시점에서 패닝할 것으로 예상할 수 있으므로 프리로드 영역(112)과 같은 "프리로드 영역"을 형성하기 위해 크기를 증가시킬 수 있다. 프리로드 영역(112)의 타일(111)은 사용자가 필요할 때 즉시 이용가능하도록 백그라운드에서 로딩될 수 있다.

전술한 바와 같이, 이러한 타일(111)은 서브카테고리 (c)(i)의 일부로 간주될 수 있다. 이와 같이, 이러한 타일(111)을 요청하는 것은 다른 타일 요청을 늦추지 않을 수 있고 다른 더 중요한 타일을 정리하는 비용이 들지 않을 수 있다.

사용자 경험의 잠재적 이득에도 불구하고, 이 접근법은 또한 결점을 가질 수 있다. 이러한 단점 중 하나는 이미지의 더 큰 영역을 선제적으로 로딩하는 것일 수 있으며, 이는 타일 서버에 더 많은 요청이 이루어지고 이러한 요청 중 일부가 낭비됨을 의미한다. 따라서 타일을 프리로딩한 데이터 전송 비용은 그렇지 않은 것보다 높다. 또 다른 단점은 너무 큰 영역을 프리로딩하면 사용자와 서버 모두에 부담을 줄 수 있다는 것이다. 실제로 이로 인해 프런트엔드에서 끊김이 발생하고 백엔드에서 레이턴시가 증가할 수 있다. 그러나 이는 서버 측에서 CDN(Content Delivery Network)을 사용하고 클라이언트 측에서 적절한 요청 스케줄링을 통해 완화될 수 있다.

병렬 타일 로드 및 디코딩

최신 브라우저에서, 리소스 로딩은 백그라운드에서 비동기적으로 발생하지만, 이미지 디코딩은 메인 스레드에서 발생할 수 있다. 따라서 많은 수의 이미지를 디코딩하면 레이턴시가 증가하고 렌더링 루프가 지연되어 결과적으로 FPS가 떨어질 수 있다. 도 12는 상부 절반(120)에 있는 순차적 요청(121, 122 및 123) 및 하부 절반(125)에 있는 순차적 요청(126, 127 및 128)을 갖는 순차적인 방식으로 타일을 요청, 로딩 및 디코딩하는 예시적인 타임라인을 도시한다. 이미지 디코딩이 메인 스레드에서만 발생한다면, 순전히 순차적일 수 있으며 렌더링 루프를 실행할 수 있기 전에 디코딩이 완료될 때까지 기다려야 할 수도 있다.

도 12의 상부 절반(120)에서, 순차 요청(121, 122, 123)은 메인 스레드 또는 다른 스레드 내에 있을 수 있다. 순차 요청(121, 122, 123)은 디코딩되어 순차적으로 저장될 수도 있고, 다른 순서로 디코딩되어 메인 스레드의 일부로서 순차적으로 저장될 수도 있다. 순차 요청(121, 122, 123)의 병렬 로딩은 다양한 시간을 포함할 수 있지만 순차 순서로 시작할 수 있다.

이것은 도 12의 상부 절반(125)과 유사하며, 순차 요청(126, 127, 128)은 메인 스레드 또는 다른 스레드 내에 존재할 수 있다. 순차 요청(126, 127, 128) 사이의 간격은 메인 스레드 내에서 달라질 수 있다. 다른 스레드 내에서 순차적 요청에 대한 병렬 로딩 및 디코딩 시간도 다를 수 있으며 스레드의 동일한 단계 내에서 완료될 수 있다. 순차 요청에 대한 추가 세부 정보는 아래에 제공된다.

WebWorker는 최근 웹 API 제품군에 추가되었다. WebWorkers는 최신 프로세서의 멀티스레딩 기능을 활용하여 메인 스레드와 병렬로 JavaScript 및 Wasm 코드를 실행할 수 있다. JavaScript는 본질적으로 단일 스레드이므로 단일 스레드에서만 실행될 수 있다. JavaScript에서 병렬 컴퓨팅을 허용하려면, 다중 처리 및 메시지 전달을 사용해야 할 수 있다. 이것이 WebWorker의 기본 개념이다: 이는 독립적인 JavaScript 컨텍스트에서 운영될 수 있으며 채널을 통해 메인 스레드로 데이터를 앞뒤로 전달할 수 있다.

WebWorkers를 사용하면, 메인 스레드에서 이미지를 디코딩하는 것이 가능해질 수 있다. 작업을 다른 스레드로 오프로딩하면 메인 스레드가 이벤트 처리 및 렌더링을 포함하여 더 중요한 책임을 자유롭게 실행할 수 있다. 도 12는 디코딩을 다른 스레드로 연기함으로써 더 높은 빈도로 더 빠른 렌더링이 달성됨을 보여준다.

이 기술은 최근 OffscreenCanvas API의 추가 덕분에 렌더링에도 사용될 수 있다. 하지만 현재 렌더링은 뷰어에게 병목 현상이 아닐 수 있으므로, 이는 구현되지 않았다.

마지막으로 JavaScript는 스레드를 가질 수 없지만 SharedArrayBuffer API 덕분에 미래에는 여전히 메모리를 직접 공유할 수 있다는 것에 유의한다. 또한 Wasm 사양은 스레딩 모델을 지원하며 Wasm 스레드는 Chrome 및 Firefox에서 이미 사용 가능할 수 있다.

예시적인 실시예

예시적인 실시예는 FOV가 (4, 4), (5, 4), (4, 5), (5, 5)와 같은 그리드의 좌표로 인덱싱된 4개의 타일들을 포함하도록 사용자가 FOV를 조정하는 것을 포함한다. 뷰어는 FOV 내에 모두 위치할 수 있는 타일들 (4, 4), (5, 4), (4, 5), (5, 5)를 로딩할 수 있다. 타일들 (4, 4) 및 (5, 4)는 이미 완전히 로딩된 상태로 캐시에 저장되어 있을 수 있다. 타일들 (4, 5) 및 (5, 5)는 캐시에 저장되지 않을 수 있으며, 이로 인해 이러한 타일들이 타일 요청 상태로 저장될 수 있다. 타일 요청 상태는 뷰어 또는 타일 서버에 저장될 수 있다. 예를 들어, 뷰어는 타일들 (4, 5) 및 (5, 5)를 로딩하기 위해 타일 서버에 타일 요청을 발송할 수 있다. 타일 요청은 특정 FOV 좌표 또는 다른 고유 식별자와 같은 타일 식별자를 포함할 수 있다. 타일 서버는 뷰어에게 데이터를 전송할 수 있다. 이러한 데이터는 타일이 완전히 로딩되기 위한 완전한 타일 정보를 포함할 수 있다. 뷰어는 타일들 (4, 5) 및 (5, 5)를 완전히 로딩된 상태로 이동시킬 수 있다. 이제 모든 타일들이 완전히 로딩된 상태이므로 뷰어는 경계 타일들 (3, 4), (4, 3) 등을 로딩할 수 있고, 여기서 이전에 설명된 방법은 경계 타일 및 후속 타일 그룹에 대해 반복될 수 있다. 또한 사용자는 FOV를 다시 조정할 수 있고 뷰어는 새 FOV에 대해 캐시에서 타일을 로딩할 수 있다.

캐시는 이전 방법에서 최대 점유 상태일 수 있다. 예를 들어 방법으로부터 로딩된 모든 타일이 캐시를 최대 점유율로 채웠을 수 있다. 새로운(또는 현재) FOV를 사용하여, 캐시는 저장된 타일을 정렬하고 캐시가 더 이상 최대 용량이 아니게 될 때까지 우선 순위가 낮은 타일을 제거할 수 있다. 이러한 정렬 프로세스는 프로세스 중 언제든지 발생할 수도 있다.

또한, 뷰어는 전술한 프로세스 동안 임의의 포인트에서 타일을 렌더링할 수 있다. 뷰어는 완전히 로딩된 상태의 타일을 디스플레이 또는 저장 디바이스에 렌더링할 수 있다. 이것은 렌더링 루프의 실행이 백그라운드 루프 방법과 독립적일 수 있는 렌더링 루프일 수 있다.

작업 스케줄링

위에서 언급했듯이 백그라운드 루프는 현재 프로세스에 여유 시간이 있을 때마다 실행해야 할 수 있다. 이는 웹 뷰어에서 렌더링 루프 직전에 실행되도록 스케줄링될 수 있다. 이는, 작동하는 동안, 백그라운드 루프가 너무 오래 걸리면 렌더 루프가 프레임을 놓칠 수 있으므로 최적이 아닐 수 있다.

작업 스케줄링의 초기 예는 실험적인 requestIdleCallback API이다. 이 API를 사용하면 브라우저가 유휴 기간을 가질 때마다 백그라운드 루프를 호출할 수 있다. 또한 여러 개의 작은 작업 유닛을 실행하기 때문에 백그라운드 루프는 본질적으로 일시 중지 가능하다. 타임아웃에 도달하면 실행이 일시적으로 일시 중지된 다음 다음 프레임에서 다시 시작될 수 있다. 따라서 가까운 장래에 해당 모델은 새로운 브라우저 스케줄링 API를 활용할 수 있다.

성능 메트릭

계측(instrumentation) 프레임워크의 트레이서 컴포넌트는 타일에 대한 첫 번째 요청이 이루어진 순간, 타일이 서버로부터 로딩되는 순간, 그리고 최종적으로 화면에 렌더링되는 순간 사이의 지속시간을 타이밍하는 역할을 한다. 이러한 이벤트는 도 9에 예시되어 있다. 로딩 및 렌더링은 뷰어의 다른 컴포넌트에서 발생할 수 있으므로, 트레이서는 애플리케이션 전체에 광범위하게 적용된다. 트레이서는 모두 제네릭 API를 노출하는 측정해야 하는 다양한 컴포넌트를 래핑함으로써 이를 달성할 수 있다. 따라서 트레이서를 비활성화하려면, 사용자가 이러한 래퍼를 제거하기만 하면 된다.

계측 프레임워크에 의해 수집된 중요한 메트릭은 FOV 완료 시간이다. FOV 완료 시간은 사용자 상호작용으로 인해 FOV가 변경되는 순간과 새로운 FOV가 화면에 완전히 렌더링되는 순간 사이에 경과된 시간을 측정할 수 있다.

일부 상호작용은 FOV를 표시하는 데 필요한 타일이 이미 캐시에 있을 수 있으므로 즉각적인 FOV 완료를 초래할 수 있다. 따라서 프레임워크는 불완전한 FOV가 사용자에게 최소한 한 프레임 동안 표시되었을 때만 FOV 완료 이벤트를 고려할 수 있다. 불완전한 FOV는 타일 텍스처가 아직 로딩되지 않은 것이며 캐시에서 더 낮은 배율 타일의 보간된 버전으로 대체될 수 있다.

FOV 완료 시간은 턴어라운드 시간(turnaround time)이라고도 한다. FDA(Food and Drug Administration)에는 다양한 사용자 상호작용에 대한 뷰어 애플리케이션의 처리 시간 허용에 관한 구체적인 가이드라인이 있다. 예시적인 실시예는 FDA 턴어라운드 타임라인 가이드라인의 일부만을 사용한다.

FOV 완료 시간은 순전히 정량적 측정 기준이지만, 보다 정성적인 사용자 경험 지표는 사용자의 세션에 대한 FOV 완료의 평균 백분율을 측정하는 것이다. 이 메트릭의 목적은 사용자가 불완전한 FOV에서 보낸 시간과 언제든지 화면에 표시되는 부분 정보의 양을 정량화하는 것이다.

화면에 렌더링된 모든 프레임에 대해, 트레이서는 현재 FOV 배율 레벨보다 낮은 배율 레벨에 있는 텍스처를 참조하는 드로우 호출을 확인하기 위해 타일 드로우 호출을 볼 수 있다. 전체 FOV는 자체보다 같거나 높은 배율 레벨에서만 텍스처를 표시할 수 있으므로, 더 낮은 배율 텍스처를 포함하는 프레임은 필연적으로 불완전하다. 이러한 드로우 호출이 적용되는 영역은 FOV의 미완료(및 반대로 완료) 비율을 나타내는 FOV 영역으로 측정되고 및 나누어질 수 있다. 고배율 텍스처가 저배율 텍스처에 중첩될 수 있으므로 알고리즘은 약간 더 복잡할 수 있다: 타일을 렌더링하는 데 필요한 정확한 텍스처를 아직 사용할 수 없는 경우, 캐시에서 더 높은 배율의 서브타일과 더 낮은 배율의 슈퍼타일을 사용할 수 있다.

마지막으로, 측정하기 가장 간단한 메트릭은 단일 타일을 로딩하고 렌더링하는 데 걸리는 시간이다. 이 메트릭은 대부분 타일 서버의 성능을 나타낼 수 있지만 타일 로딩 및 렌더링 파이프라인의 문제를 나타낼 수도 있다.

예를 들어, HTTP/1.1 프로토콜을 사용하면, 대부분의 브라우저는 특정 호스트에 병렬로 이루어질 수 있는 요청의 수를 제한할 것이다. Chrome에서, 해당 숫자는 6일 수 있다. 빠른 타일 서버를 사용하더라도, 이러한 제한은 6개 이상의 타일을 병렬로 로딩할 때 나중에 요청이 브라우저에 의해 대기열에 추가되기 때문에 타일 로딩 시간을 인위적으로 부풀릴 수 있다. 본 명세서에 기술된 예시적인 실시예에서, 타일 서버는 HTTP/2.0 프로토콜을 배타적으로 사용하며, 이는 이러한 제한을 받지 않을 수 있다.

사용자 세션 기록 및 재생

의미 있는 비교 벤치마크를 컴파일링하기에 충분한 데이터를 수집하는 것은 항상 어려운 일이다. 따라서 현실적인 사용 데이터를 빠르고 효율적으로 생성하는 방법이 필요하다.

한 솔루션을 다른 솔루션과 비교하는 한 가지 접근법은 추적이 활성화된 일반 사용자 세션의 단계를 수동으로 재생하여 샘플을 본 후 어떤 솔루션이 최상의 성능을 보이는지 확인하는 것이다. 이러한 접근법은 완전히 수동이므로 사용자가 추가로 소요하는 시간을 포함하여 몇 가지 단점이 있을 수 있다. 또한 이 방법은 과학적이지 않을 수 있으며 중요한 차이를 보여주기에 충분한 샘플을 수집하지 못할 수 있다.

이러한 결점을 피하기 위해, 세션 레코더와 플레이어가 사용될 수 있다. 사용자 상호작용은 발생한 순간과 함께 기록될 수 있으므로, 나중에 동일한 속도로 재생될 수 있다. 원래 사용자 세션과 재생된 세션 간의 주요 차이점 중 하나는 세션 플레이어가 FOV가 완전히 해결되었음을 알게 되면 사용자 상호작용 사이에 더 이상 기다리지 않는다는 것이다. 이는 재생된 세션이 일반적으로 원본보다 빠를 수 있음을 의미할 수 있다. 이는 또한 이벤트가 평균적으로 더 빠른 속도로 발생하기 때문에 뷰어 부분에 더 많은 부담을 줄 수 있음을 의미할 수 있다. 따라서, 이는 완전히 현실적인 사용 시나리오를 대표하지는 않지만 최악의 경우 시스템에 또 하나의 스트레스를 준다.

벤치마크

다음 벤치마크는 다음 사양의 컴퓨터에서 캡처되었다:

모델: MacBook Pro, 13인치, 2019

CPU 2.8GHz 쿼드 코어 Intel Core i7

그래픽 Intel Iris Plus Graphics 655(통합)

그래픽 메모리 1536MB

메모리 16GB 2133MHz LPDDR3

인터넷 대역폭 300Mbps

서버 측에서, 인스턴스는 다음 사양의 m5a.4xlarge 유형의 AWS EC2 인스턴스에서 운영된다:

CPU 2.5GHz AMD EPYC 7571, 16 스레드

메모리 64GB

벤치마크는 상이한 조직으로부터의 10개의 SVS 슬라이드의 세트에 캡되었다. 모든 슬라이드는 40x 배율 파워로 스캔되었다. 아래 표는 조직 유형, 슬라이드 크기 및 해상도를 자세히 설명한다.

조직 유형	크기(GB)	폭	높이
부신	2.1	129 480	95 624
방광	2.4	141 432	78 605
뇌, 소뇌	3.1	129 480	82 966
뇌, 피질	3.0	99 600	92 207
콜론	2.6	111 552	96 671
심장	2.3	123 504	81 983
신장	2.8	141 432	67 614
간	3.1	113 544	82 680
폐	1.2	131 472	71 639
림프절	1.4	89 640	79 414

예시적인 뷰어/타일 서버 콤보를 벤치마킹하기 위해, 프로세스는 두 부분으로 나누어진다. 먼저, 일련의 사용자 작업이 기록되며 나중에 재생될 수 있도록 사용자 세션으로서 저장된다. 그런 다음 데이터 세트의 모든 슬라이드에 대해 사용자 세션이 생성되면 사용자 세션이 재생된다.

사용자 세션을 기록하는 프로세스는 다음 단계를 포함할 수 있다:

a. 슬라이드 트레이에서 슬라이드를 클릭하여 이를 열고 기록을 시작.

b. 3분 동안 일련의 줌 및 팬을 사용하여 슬라이드 탐색.

c. 사용자 세션을 저장.

d. 다음 슬라이드에 대해 프로세스를 반복.

벤치마크를 생성하는 프로세스는 다음 단계를 포함할 수 있다:

a. 이전에 생성된 타일을 모두 소거.

b. 뷰어를 벤치마킹할 원하는 설정으로 구성.

c. 재생할 사용자 세션을 선택.

d. 뷰어는 선택된 세션을 여러 번 자동으로 재생하고 결과를 디스크에 저장할 수 있다.

FOV 완료

줌 작업은 FOV를 완전히 무효화할 수 있으므로 패닝 작업보다 완료하는 데 평균적으로 느릴 수 있다: 뷰어가 한 배율 레벨에서 다른 배율 레벨로 전환하고 있기 때문에 이전에 표시된 타일을 재사용할 수 없다. 이는 새 FOV 주변에서 이러한 타일 중 일부를 여전히 재사용할 수 있는 팬 작업과 대조된다.

다음 구성이 정확히 동일한 일련의 작업을 따를 수 있지만, 수집된 샘플 수는 구성 간에 크게 다를 수 있다. 궁극적으로 샘플 수는 사용자에게 불완전한 FOV가 표시되는 작업의 수를 나타낸다. 따라서, 더 적은 수의 샘플은 더 적은 백분율의 작업이 수행되었음을 나타낼 수 있다. 이 효과는 위에서 설명된 타일 프리로딩 구성에 대해 특히 눈에 띌 수 있으며 여러 가지 방법으로 설명될 수 있다. FOV 완료 시간이 매우 빠른 경우, 사용자가 패닝 또는 주밍할 때 완료 이벤트가 여러 번 발생할 수 있다. 그들의 속도가 느리면 사용자가, 그들은 사용자가 이러한 작업을 완료한 후에만 발생할 수 있다. 더 적은 수의 불완전한 FOV를 표시해야 하는 구성에는 FOV 완료 이벤트 샘플이 더 적을 수 있다.

도 13a에 도시된 바와 같이, 예시적인 뷰어는 결코 타일 캐시를 사용하지 않고 대신 항상 주문형 타일을 생성하도록 구성될 수 있다. 이것은 동적 타일링 벤치마크의 경우일 수 있다.

정적 타일링 벤치마크에 대해 구성된 예시적인 뷰어가 도 13b에 예시되어 있다. 정적 타일링 벤치마크의 경우, 뷰어에 필요한 모든 타일이 미리 생성되어 타일 서버를 통해 S3로부터 스트리밍되었다. 이는 앞으로 나아갈 가장 현실적인 접근법으로 간주될 수 있으므로, 다음 벤치마크는 모두 정적 타일링을 사용한다.

프리로딩 벤치마크는 프리로드 오프셋을 위한 4가지 다른 구성과 함께 타일 프리로딩을 믹스에 추가한다. 프리로드 오프셋은 구성된 타일 크기의 인자로 표현될 수 있다. 예를 들어, 타일 크기가 512 Х 512이고 프리로드 오프셋이 0.5로 구성된 경우 픽셀 단위의 실제 프리로드 오프셋은 512 Х 0.5 = 256픽셀일 수 있다.

구성 프리로드 오프셋

프리로드, 1 0.5

프리로드, 2 1.0

프리로드, 3 1.5

프리로드, 4 2.0

도 14는 프리로드 오프셋의 값이 FOV 완료 레이턴시에 직접적으로 영향을 미칠 수 있음을 보여준다. 또한, 프리로드 오프셋은 더 큰 프리로드 오프셋이 필연적으로 더 빠른 완료 시간을 포함한다는 직관을 무효화할 수 있다. 이는 여러 가지 방법으로 설명될 수 있다. 프리로드 오프셋이 클수록 궁극적으로 더 많은 타일을 로딩해야 할 수 있다. 로딩할 타일의 수는 프리로드 오프셋에 따라 2차적으로(quadratically) 증가할 수 있으며, 이로 인해 타일 수가 많으면 성능 문제가 발생할 수 있다. 또한, 동시에 많은 수의 타일을 로딩하면 타일 서버에 부담이 가중되고 요청의 레이턴시가 추가될 수 있다. 예시적인 실시예에서, 모든 프리로드 타일은 동일한 우선순위를 가질 수 있다. 이는 더 큰 프리로드 오프셋 값의 경우 FOV에서 더 멀리 떨어져 있어 필요하지 않은 일부 타일이 더 가까운 타일보다 먼저 해결될 수 있음을 의미할 수 있다. 마지막으로 벤치마크의 작업은 FOV 완료 이벤트 사이를 기다리지 않고 매우 빠르게 연속적으로 운영될 수 있다. 이는 사용자가 작업 사이에 최소 0.5초를 기다려야 하는 타일 프리로딩의 병리학적 경우이다. 이 시간 동안, 대부분의 프리로드 타일은 적절하게 로딩되어야 한다.

느린 인터넷 연결 벤치마크는 느린 연결을 시뮬레이션하기 위해 인터넷 대역폭을 10Mbps로 인위적으로 제한할 수 있다.

도 15a는 공지된 슬라이드 뷰어 대 동적 타일링을 갖는 예시적인 실시예의 성능의 비교이다. 결과는 예시적인 실시예가 FOV의 로딩에서 항상은 아니지만 거의 항상 알려진 사이드 뷰어보다 더 빠르다는 것을 보여줄 수 있다.

도 15b는 동적 타일링 대 정적 타일링을 사용한 실시예의 성능 비교이다. 디스플레이를 완전히 무효화해야 하는 이벤트(예를 들어, 초기 로드 및 주밍)에서 차이가 눈에 띌 수 있다. 반면에 디스플레이의 부분적 무효화(패닝)가 필요한 이벤트는 식별할 수 있는 차이가 거의 또는 전혀 없을 수 있다. 이는 이러한 이벤트가 서버에 가해지는 부담의 차이로 설명될 수 있다: 디스플레이를 완전히 무효화하려면 부분 무효화보다 더 많은 타일을 병렬로 로딩해야 할 수 있으며 결과적으로 레이턴시 스파이크가 발생할 수 있다.

현재 정적 타일링 구현은 타일 서버가 백업 저장소(AWS S3)와 클라이언트(브라우저) 사이에서 프록시 역할을 해야 할 수 있으므로 완벽하지 않을 수 있다. 이로 인해 모든 요청에 약간의 레이턴시가 추가될 수 있다. 이 레이턴시를 제거하는 방법은 백업 저장소로부터 직접 타일을 제공하는 것 및/또는 AWS CDN(Content Delivery Network), CloudFront를 통해 타일을 제공하는 것을 포함할 수 있다. CDN은 정적 콘텐츠를 제공하는 데 최적화될 수 있으며, 해당 데이터를 클라이언트에 더 가까운 서버로 물리적으로 이동시켜 자주 질의되는(queried) 콘텐츠의 지연 시간을 크게 개선할 수 있다.

이러한 접근법은 인증 로직을 타일 서버(이는, 이 시점에서는, 인증 제공자에 가깝다)로부터 클라이언트가 궁극적으로 통신할 서비스(예를 들어, S3 또는 CloudFront)로 부분적으로 이동시켜야 할 수 있다.

도 15c는 프리로딩이 디스에이블되고 1의 프리로딩 오프셋으로 인에이블된 예시적인 실시예의 성능의 비교이며, 여기서 위 설명의 벤치마크는 레이턴시와 로딩된 타일 수 사이에서 타협점을 찾는 것으로 나타났다. 이 구성에서, 1의 프리로딩 오프셋은 FOV 주변에 512x512의 프리로드 경계를 추가하는 것을 의미한다.

예상된 바와 같이, 현재 프리로딩의 구현은 동일한 배율 레벨의 경계 타일에서만 동작할 수 있으므로 줌 작업의 성능은 거의 변하지 않는다. 그러나 프리로딩하면 패닝 동작 속도가 상당히 빨라지는 것을 볼 수 있다. 초기 로드에 대한 레이턴시의 차이는 이러한 이벤트에 대한 적은 수의 샘플로만 설명될 수 있다.

마지막으로, 예시적인 실시예가 알려진 슬라이드 뷰어보다 상당히 빠를 수 있음을 추가로 설명하기 위해, 도 15e는 300Mbps 연결에서 운영되는 공지된 슬라이드 뷰어와 10Mbps 연결에서 운영되는 예시적인 실시예 사이의 비교를 도시한다. 예시적인 실시예는 초기 로드 및 패닝 작업 둘 모두에서 더 빠르지만, 주밍 작업에서 공지된 슬라이드 뷰어만큼 잘 수행한다. 앞에서 설명된 것처럼 이러한 작업을 수행하려면 더 많은 타일을 로딩해야 하므로 제한된 대역폭이 포화 상태가 된다.

타일을 로딩하는 데 걸리는 시간은 뷰어의 체감 성능에 중요한 인자이다. 도 15f에 나타낸 바와 같이, 예시적인 실시예의 타일 서버 구현은 알려진 타일 서버보다 훨씬 빠르게 타일을 제공할 수 있으며, 이는 사용자에 대한 로딩 시간이 줄어들 수 있다. 필요에 따라 타일을 생성하는 동적 타일 서버와 모든 타일이 이미 미리 생성된 정적 타일 서버 사이의 차이는 그다지 뚜렷하지 않다.

채택할 구성을 결정할 때, 발생하는 주요 타협점은 사용자 경험의 품질 대 유지관리 비용이다.

사용자 경험의 품질은 평균 타일 로딩 시간과 같은 보다 정량적인 메트릭에 따라 달라질 수 있지만, 이러한 메트릭이 모든 것을 말해주지는 않는다. 보다 대표적인 메트릭을 얻기 위해, 예시적인 실시예는 사용자 세션 동안 사용자에게 불완전한 FOV가 제시되는 시간의 백분율을 사용할 수 있다. 이 메트릭은 평균 FOV 완료이며 위에서 자세히 설명되어 있다. 한편, 뷰어 부분의 유지관리 비용의 주요 인자는 세션 동안 로딩된 평균 타일 수이다. 타일을 로딩하면 처리 능력과 데이터 송신 비용이 모두 발생한다.

아래 표는 서로 다른 테스트 구성에 대한 이 두 가지 메트릭을 분석한 것이다.

구성	FOV 완료	요청된 타일	로딩된 타일
풀포커스	0.7909	707.1	707.1
동적	0.9952	2706.9	2222.9
정적	0.9953	2704.0	2247.8
프리로드, 1	0.9963	2849.3	2514.2
프리로드, 2	0.9961	3262.2	2834.5
프리로드, 3	0.9963	3739.8	3186.5
프리로드, 4	0.9961	4044.1	3338.2
10Mbps	0.9943	2717.9	2161.4

프리로드 오프셋 설정이 높을수록 결국 더 많은 타일이 로딩된다는 직감이 있을 것이다. 이는, 더 이상 필요하지 않은 것으로 판명되면 계류 중인 타일 요청을 뷰어가 자동으로 취소할 수 있으므로, 반드시 그런 것은 아니다. 이는 슬라이드 뷰어의 예시적인 실시예에 대해 요청된 타일 및 판독된 타일 값이 다른 이유일 수 있다. 이 효과는 타일을 프리로딩할 때 특히 두드러질 수 있다.

유사하게, 플레이된 사용자 세션이 동일하고 절대적으로 필요한 것 외에는 어떤 타일도 로딩되지 않기 때문에, 요청된 타일 값은 예시적인 실시예의 동적, 정적 및 10Mbps 구성 간에 동일할 것으로 예상될 수 있다. 그러나 브라우저의 스케줄링 API는 완전히 결정적이지 않을 수 있으므로, 동일한 세션의 서로 다른 운영 간에 약간의 차이가 발생한다. 타일 요청을 담당하는 백그라운드 루프는 다른 시간에 운영되고 다른 FOV를 캡처할 수 있다. 이 효과는 무시할 수 있을 정도로 작다. 이러한 점을 염두에 두면, 예시적인 실시예는 겉보기에 비슷한 데이터 송신 비용에서도 훨씬 더 부드러운 사용자 경험을 제공할 수 있다.

스트리밍 뷰어

사용자가 슬라이드 뷰어를 직접 렌더링하는 대신, 스트리밍 뷰어에서 그 책임은 사용자에 대해 표시할 비디오 스트림을 다시 발송하는 서비스로 이전된다. 구현 시 GStreamer 및 WebRTC 지원과 같은 스트리머 라이브러리를 광범위하게 사용하여, 최소 레이턴시(<100ms)로 사용자에게 라이브 비디오 인코딩 및 스트리밍을 가능하게 할 수 있다. 이는 부분적으로 VP8 및 VP9와 같은 새로운 비디오 코덱 지원 덕분일 수 있다.

스트리밍 슬라이드 뷰어의 예시적인 실시예의 아키텍처가 도 16에 도시되어 있다. "빈(bin)"으로 표시된 상이한 부분은 스트리머 라이브러리 컴포넌트를 나타낸다.

예시적인 실시예에서, 사용자의 브라우저는 WebRTC를 통해 비디오 피드를 수신할 수 있고, 그에 따라 FOV를 업데이트하기 위해 서버에 대한 뷰어(163)와의 사용자 상호작용에 대응하는 이벤트를 다시 발송한다.

WebRTCBin(161)은 WebRTC를 통해 웹 플레이어(162)로 패킷을 발송할 수 있다. 웹 플레이어(162)는 차례로 웹소켓을 통해 뷰어(163)로 이벤트를 발송할 수 있다. 뷰어(163)는 WebGPU 렌더러(164)로부터 호출을 드로잉할 수 있다. 프레임은 WebGPU 렌더러(164)에서 비디오 빈(165)으로 발송될 수 있으며, FFGI는 소스(166), 인코더(167) 및 페이로더(168)를 포함할 수 있다.

예시적인 실시예는 GStreamer를 위한 플러그인의 생태계 및 Rust와 GStreamer의 통합 품질에 기초하여 구현이 쉬울 수 있다. 기본적으로 브라우저에서 동일한 코드를 운영하면 뷰어의 거동이 모든 렌더링 백엔드 간에 동일하게 유지된다.

본 발명의 예시적인 실시예의 상기 설명에서, 본 발명의 다양한 피쳐는 종종 개시 내용을 간소화하고 하나 이상의 다양한 발명적 양태의 이해를 돕기 위해 단일 실시예, 도면 또는 그의 설명으로 함께 그룹화된다는 것을 이해해야 한다. 그러나 이러한 개시의 방법은 청구된 발명이 각 청구범위에 명시적으로 인용된 것보다 더 많은 특징을 요구한다는 의도를 반영하는 것으로 해석되어서는 안 된다. 오히려, 다음의 청구범위가 반영하는 바와 같이, 발명의 양태는 앞서 개시된 단일 실시예의 모든 피쳐보다 적다. 따라서, 상세한 설명 다음의 청구범위는 본 명세서에 명시적으로 포함되며, 각 청구범위는 본 발명의 별도의 실시예로서 그 자체로 서 있다.

또한, 본 명세서에 설명된 일부 실시예는 일부를 포함하지만 다른 실시예에 포함된 다른 피쳐는 포함하지 않지만, 상이한 실시예의 피쳐의 조합은 본 발명의 범위 내에 있는 것으로 의미되고, 당업자에 의해 이해되는 바와 같이 상이한 실시예를 형성한다. 예를 들어, 다음 청구범위에서, 청구된 실시예 중 임의의 것이 임의의 조합으로 사용될 수 있다.

따라서, 특정 실시예가 설명되었지만, 당업자는 본 발명의 사상을 벗어나지 않고 그에 대한 다른 추가 수정이 이루어질 수 있음을 인식할 것이며, 이러한 모든 변경 및 수정이 본 발명의 범위 내에 속하는 것으로 주장하는 것으로 의도된다. 예를 들어, 블록도에서 기능이 추가되거나 삭제될 수 있으며 기능 블록 간에 동작이 교환될 수 있다. 본 발명의 범위 내에서 설명되는 방법에 단계가 추가되거나 삭제될 수 있다.

상기 개시된 주제는 예시적인 것으로 간주되어야 하며 제한적이지 않으며, 첨부된 청구범위는 본 발명의 진정한 사상 및 범위 내에 속하는 이러한 모든 수정, 향상 및 기타 구현을 포함하도록 의도된다. 따라서, 법이 허용하는 최대 범위 내에서, 본 발명의 범위는 다음 청구범위 및 그 균등물의 가장 넓은 허용 가능한 해석에 의해 결정되어야 하며, 전술한 상세한 설명에 의해 제한되거나 제한되어서는 안 된다. 본 개시의 다양한 구현예가 설명되었지만, 본 개시의 범위 내에서 더 많은 구현예가 가능하다는 것이 당업자에게 명백할 것이다. 따라서, 본 개시는 첨부된 청구범위 및 그 등가물에 비추어 제한되지 않는다.

Claims (20)

1. 전자 이미지(electronic image)를 처리하기 위한 컴퓨터 구현 방법(computer-implemented method)으로서, 상기 방법은:
   뷰어(viewer)에 의해, 상기 전자 이미지 및 FOV(시야)를 수신하는 단계-여기서, 상기 FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-;
   상기 뷰어에 의해, 상기 FOV 내에 복수의 타일(tile)들을 로딩하는 단계;
   상기 뷰어에 의해, 캐시(cache)의 복수의 타일들의 상태를 결정하는 단계; 및
   상기 캐시의 상기 복수의 타일들의 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들을 디스플레이(display)에 렌더링(rendering)하는 단계를 포함하는, 컴퓨터 구현 방법.
2. 제1항에 있어서,
   상기 뷰어에 의해, 상기 캐시의 상기 복수의 타일들의 타일의 상기 상태를 타일 요청 상태로 결정하는 단계;
   상기 결정에 응답하여, 상기 뷰어에 의해, 상기 타일 요청 상태를 타일 서버에 발송하는 단계;
   상기 뷰어에 의해, 상기 타일 서버로부터 데이터 전송을 수신하는 단계-여기서, 상기 데이터 전송은 상기 타일 서버가 상기 타일 요청 상태를 수신하는 것에 응답하며, 상기 데이터 전송은 상기 복수의 타일들의 타일에 대응하는 타일 데이터를 포함함-;
   상기 뷰어에 의해, 상기 복수의 타일들의 상기 타일을 완전히 로딩된 상태로 이동시키는 단계; 및
   상기 뷰어에 의해, 상기 복수의 타일들을 렌더링하는 단계를 더 포함하는, 컴퓨터 구현 방법.
3. 제1항에 있어서, 상기 전자 이미지를 수신하는 단계는 낮은 배율 레벨의 타일들의 세트를 상기 캐시에 로딩하는 단계를 포함하는, 컴퓨터 구현 방법.
4. 제1항에 있어서, 상기 FOV 내에 상기 복수의 타일을 로딩하는 단계는:
   상기 뷰어에 의해, 상기 캐시가 상기 복수의 타일들의 타일을 저장하고 있는지 여부를 결정하는 단계;
   상기 캐시가 상기 타일을 저장하고 있다고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 타일이 상기 배율 인자보다 크거나 같은 배율 레벨을 갖는지 여부를 결정하는 단계; 및
   상기 타일이 상기 배율 인자보다 크거나 같은 상기 배율 레벨을 갖는다고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 캐시로부터 상기 타일을 로딩하는 더 단계를 포함하는, 컴퓨터 구현 방법.
5. 제4항에 있어서,
   상기 타일이 상기 배율 인자보다 크거나 같은 상기 배율 레벨을 갖지 않는다고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들의 상기 타일에 대응하는 저장된 타일을 검색하는 단계를 더 포함하고, 상기 저장된 타일은 가장 높은 저장된 배율 레벨을 갖는, 컴퓨터 구현 방법.
6. 제1항에 있어서, 상기 전자 이미지는 WSI(전체 슬라이드 이미지)인, 컴퓨터 구현 방법.
7. 제6항에 있어서, 상기 WSI는 복수의 이미지들의 피라미드 구조(pyramidal structure)를 포함하고, 상기 복수의 이미지들의 상기 피라미드 구조는 적어도 하나의 WSI 배율 레벨을 포함하고, 상기 적어도 하나의 WSI 배율 레벨은 상기 배율 인자에 대응하는 타일들의 세트를 포함하는, 컴퓨터 구현 방법.
8. 제1항에 있어서,
   상기 뷰어에 의해, 상기 캐시가 최대 점유율을 갖는지 여부를 결정하는 단계; 및
   상기 캐시가 상기 최대 점유율을 갖는다고 결정한 것에 응답하여, 상기 뷰어에 의해, 상기 FOV에 기초하여 상기 캐시를 정렬하는 단계를 더 포함하는, 컴퓨터 구현 방법.
9. 제8항에 있어서, 상기 FOV에 기초하여 상기 캐시를 정렬하는 단계는:
   상기 뷰어에 의해, 상기 캐시에 저장된 상기 복수의 타일들의 적어도 하나의 타일을 퇴거시키는 단계(leaving)-여기서, 상기 퇴거시키는 단계는 우선 순위를 따르고, 상기 캐시가 상기 최대 점유율 이하가 될 때까지 상기 퇴거시키는 단계가 계속됨-; 및
   상기 캐시가 상기 최대 점유율 이하인 것으로 결정한 것에 응답하여, 상기 뷰어에 의해, 상기 캐시로부터 상기 복수의 타일들의 임의의 남아있는 타일들을 제거하는 단계를 더 포함하는, 컴퓨터 구현 방법.
10. 제9항에 있어서, 상기 우선 순위는 상기 배율 인자보다 크거나 같은 배율 레벨을 갖는 FOV 타일, 상기 배율 인자보다 크거나 같은 상기 배율 레벨을 갖는 FOV 경계 타일, 내림차순(descending) 배율 레벨 순서로, 상기 배율 인자보다 작은 배율 레벨을 갖는 복수의 FOV 타일들, 및 적어도 하나의 다른 타일을 포함하는, 컴퓨터 구현 방법.
11. 전자 이미지를 처리하기 위한 컴퓨터 시스템에 있어서, 상기 컴퓨터 시스템은:
    명령어(instruction)를 저장하는 적어도 하나의 메모리; 및
    동작들을 수행하기 위해 상기 명령어를 실행하도록 구성된 적어도 하나의 프로세서를 포함하고, 상기 동작들은:
    뷰어에 의해, 상기 전자 이미지 및 FOV(시야)를 수신하는 것-여기서, 상기 FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-;
    상기 뷰어에 의해, 상기 FOV 내에 복수의 타일들을 로딩하는 것;
    상기 뷰어에 의해, 상기 캐시의 복수의 타일들의 상태를 결정하는 것; 및
    상기 캐시의 상기 복수의 타일들의 상기 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들을 디스플레이에 렌더링하는 것을 포함하는, 컴퓨터 시스템.
12. 제11항에 있어서,
    상기 뷰어에 의해, 상기 캐시의 상기 복수의 타일들의 타일의 상기 상태를 타일 요청 상태로 결정하는 것;
    상기 결정에 응답하여, 상기 뷰어에 의해, 상기 타일 요청 상태를 타일 서버에 발송하는 것;
    상기 뷰어에 의해, 상기 타일 서버로부터 데이터 전송을 수신하는 것-여기서, 상기 데이터 전송은 상기 타일 서버가 상기 타일 요청 상태를 수신하는 것에 응답하며, 상기 데이터 전송은 상기 복수의 타일들의 타일에 대응하는 타일 데이터를 포함함-;
    상기 뷰어에 의해, 상기 복수의 타일들의 상기 타일을 완전히 로딩된 상태로 이동시키는 것; 및
    상기 뷰어에 의해, 상기 복수의 타일들을 렌더링하는 것을 더 포함하는, 컴퓨터 시스템.
13. 제11항에 있어서, 상기 전자 이미지를 수신하는 것은 낮은 배율 레벨의 타일들의 세트를 상기 캐시에 로딩하는 것을 포함하는, 컴퓨터 시스템.
14. 제11항에 있어서, 상기 FOV 내에 상기 복수의 타일을 로딩하는 것은:
    상기 뷰어에 의해, 상기 캐시가 상기 복수의 타일들의 타일을 저장하고 있는지 여부를 결정하는 것;
    상기 캐시가 상기 타일을 저장하고 있다고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 타일이 상기 배율 인자보다 크거나 같은 배율 레벨을 갖는지 여부를 결정하는 것; 및
    상기 타일이 상기 배율 인자보다 크거나 같은 상기 배율 레벨을 갖는다고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 캐시로부터 상기 타일을 로딩하는 것을 더 포함하는, 컴퓨터 시스템.
15. 제14항에 있어서,
    상기 타일이 상기 배율 인자보다 크거나 같은 상기 배율 레벨을 갖지 않는다고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들의 상기 타일에 대응하는 저장된 타일을 검색하는 것을 더 포함하고, 상기 저장된 타일은 가장 높은 저장된 배율 레벨을 갖는, 컴퓨터 시스템.
16. 제11항에 있어서, 상기 전자 이미지는 WSI(전체 슬라이드 이미지)인, 컴퓨터 시스템.
17. 프로세서에 의해 실행될 때 상기 프로세서로 하여금 전자 이미지를 처리하기 위한 동작들을 수행하게 하는 명령어를 저장하는 비일시적 컴퓨터 판독가능 매체로서, 상기 동작들은:
    뷰어에 의해, 상기 전자 이미지 및 FOV(시야)를 수신하는 것-여기서, 상기 FOV는 적어도 하나의 좌표, 적어도 하나의 치수 및 배율 인자를 포함함-;
    상기 뷰어에 의해, 상기 FOV 내에 복수의 타일들을 로딩하는 것;
    상기 뷰어에 의해, 상기 캐시의 복수의 타일들의 상태를 결정하는 것; 및
    상기 캐시의 상기 복수의 타일들의 상기 상태가 완전히 로딩된 상태라고 결정하는 것에 응답하여, 상기 뷰어에 의해, 상기 복수의 타일들을 디스플레이에 렌더링하는 것을 포함하는, 비일시적 컴퓨터 판독가능 매체.
18. 제17항에 있어서,
    상기 뷰어에 의해, 상기 캐시가 최대 점유율을 갖는지 여부를 결정하는 것; 및
    상기 캐시가 상기 최대 점유율을 갖는다고 결정한 것에 응답하여, 상기 뷰어에 의해, 상기 FOV에 기초하여 상기 캐시를 정렬하는 것을 더 포함하는, 비일시적 컴퓨터 판독가능 매체.
19. 제18항에 있어서, 상기 FOV에 기초하여 상기 캐시를 정렬하는 것은:
    상기 뷰어에 의해, 상기 캐시에 저장된 상기 복수의 타일들의 적어도 하나의 타일을 퇴거시키는 것(leaving)-여기서, 상기 퇴거시키는 것은 우선 순위를 따르고, 상기 캐시가 상기 최대 점유율 이하가 될 때까지 상기 퇴거시키는 것이 계속됨-; 및
    상기 캐시가 상기 최대 점유율 이하인 것으로 결정한 것에 응답하여, 상기 뷰어에 의해, 상기 캐시로부터 상기 복수의 타일들의 임의의 남아있는 타일들을 제거하는 것을 더 포함하는, 비일시적 컴퓨터 판독가능 매체.
20. 제19항에 있어서, 상기 우선 순위는 상기 배율 인자보다 크거나 같은 배율 레벨을 갖는 FOV 타일, 상기 배율 인자보다 크거나 같은 상기 배율 레벨을 갖는 FOV 경계 타일, 내림차순 배율 레벨 순서로, 상기 배율 인자보다 작은 배율 레벨을 갖는 복수의 FOV 타일들, 및 적어도 하나의 다른 타일을 포함하는, 비일시적 컴퓨터 판독가능 매체.

Images