[React] Cornerstone3D에서 NIfTI를 쓴다면? 1024×1024 해상도까지

기술 검토 (Tech Review)

Cornerstone3D에서 NIfTI를 쓴다면?
1024×1024 해상도까지

DICOM 메타데이터 없이 NIfTI 파일을 Cornerstone3D에 로드할 때 발생하는 구조적 차이, 제약사항, 그리고 1024×1024 고해상도 로드 시 예상되는 문제를 기술적으로 검토합니다.

NIfTI vs DICOM 메타데이터 부재 좌표계 충돌 1024×1024 메모리 GPU 텍스처 한계 WebGL OOM

01 · Background

왜 이 검토가 필요한가

Cornerstone3D는 DICOM을 기반으로 설계된 프레임워크입니다. 내부 렌더링 파이프라인, 메타데이터 시스템, 측정 도구, 어노테이션 저장 모두 DICOM 태그 구조를 전제로 동작합니다. 그런데 AI 추론 결과물, 연구용 데이터, 뇌영상 분석 등 다양한 시나리오에서 DICOM이 아닌 NIfTI(.nii, .nii.gz) 포맷을 Cornerstone3D로 렌더링해야 하는 요구가 생깁니다.

여기에 1024×1024 해상도라는 조건이 추가되면, 일반 CT 표준(512×512)의 4배 픽셀 수가 메모리와 GPU 텍스처에 어떤 압박을 주는지도 함께 분석해야 합니다. 이 글은 해당 조합이 실제 프로덕션에서 어떤 리스크를 내포하는지 기술적으로 점검합니다.

4×

512→1024 픽셀 증가

2GB+

Float32 볼륨 예상 메모리

없음

환자 메타데이터

RAS↔LPS

좌표계 충돌 위험

02 · Format Difference

NIfTI와 DICOM — 구조적 차이

두 포맷은 설계 철학이 다릅니다. DICOM은 임상 환경의 모든 정보를 담는 포괄적 표준이고, NIfTI는 신경영상 연구자를 위한 미니멀한 포맷입니다. Cornerstone3D가 전제하는 메타데이터의 상당수가 NIfTI에는 존재하지 않습니다.

항목	DICOM	NIfTI	Cornerstone3D 영향
파일 구조	슬라이스당 1개 파일	볼륨 전체 1개 파일	ImageId 생성 방식 상이
환자 정보	PatientName, PatientID, StudyDate 등	없음	뷰포트 오버레이 표시 불가
모달리티	CT, MR, PET 등 명시	없음	자동 W/L 프리셋 적용 불가
Window/Level	WindowCenter, WindowWidth 태그	없음	직접 계산해서 주입 필요
좌표계	LPS (Left-Posterior-Superior)	RAS (Right-Anterior-Superior)	축 반전 없으면 좌우 뒤집힘
Spacing/Origin	PixelSpacing, ImagePosition	pixdim, sform/qform 행렬	변환 처리 필요
슬라이스 순서	SliceLocation으로 명시	배열 순서 의존	MPR 방향 오류 가능성
압축	HTJ2K, JPEG2K 등 (Progressive 지원)	gzip 전체 압축만	Progressive Loading 불가
측정값 저장	DICOM SR 표준 형식	없음	어노테이션 표준 저장 불가
세그멘테이션	DICOM SEG 표준	별도 .nii 파일	CS3D SEG 어댑터 연동 불가

03 · Coordinate System

좌표계 충돌 — RAS vs LPS

가장 먼저 마주치는 기술적 함정입니다. DICOM은 LPS(Left-Posterior-Superior), NIfTI는 RAS(Right-Anterior-Superior)를 사용합니다. X축과 Y축 방향이 정반대여서, 변환 처리를 하지 않으면 뷰포트에서 이미지가 좌우·전후 반전되어 나타납니다.

🚨 좌표계 변환 없이 NIfTI를 그대로 로드하면 Axial 뷰에서 환자의 왼쪽/오른쪽이 뒤집혀 표시됩니다. 임상 판독 환경에서는 치명적 오류입니다. nifti-volume-loader는 내부적으로 sform/qform 행렬로 변환을 처리하지만, 커스텀 파이프라인 구성 시 반드시 직접 검증해야 합니다.

Cornerstone3D의 @cornerstonejs/nifti-volume-loader는 v2.0부터 sform/qform 행렬을 읽어 LPS로 자동 변환을 시도합니다. 단, 비표준적으로 생성된 NIfTI 파일은 sform_code가 0이거나 행렬이 잘못 설정된 경우가 있어 수동 검증이 필요합니다.

04 · Missing Metadata

메타데이터 부재가 만드는 기능 공백

DICOM의 수백 개 태그와 달리 NIfTI 헤더는 공간 정보(spacing, origin, direction)와 데이터 타입 정도만 포함합니다. Cornerstone3D가 DICOM 태그를 기반으로 제공하는 기능들이 하나씩 무너집니다.

✗

Window/Level 자동 설정 불가

DICOM의 WindowCenter/WindowWidth 태그가 없습니다. CT는 Hounsfield Unit 기반 프리셋(폐 창, 뼈 창 등)이 자동 적용되지 않습니다. 데이터 범위를 직접 분석해 수동으로 W/L을 계산해야 합니다.

✗

뷰포트 환자 정보 오버레이 표시 불가

PatientName, StudyDate, Modality, SeriesDescription 등 임상 식별 정보가 없습니다. 뷰포트 코너 오버레이(왼쪽 상단 환자명 등)가 모두 공백으로 표시됩니다.

✗

측정 어노테이션 DICOM SR 저장 불가

Ruler, ROI 측정값을 DICOM SR(Structured Report) 형식으로 저장하는 Cornerstone3D Adapters 기능을 사용할 수 없습니다. 어노테이션을 별도 포맷(JSON 등)으로 자체 관리해야 합니다.

!

모달리티별 기능 자동 적용 안 됨

PET SUV 계산, CT HU 단위 표시, MR 강도 정규화 등 모달리티 특화 기능은 DICOM 태그(RescaleSlope, RescaleIntercept 등)를 기반으로 합니다. NIfTI에는 scl_slope/scl_inter만 있어 한계가 있습니다.

!

Progressive Loading 적용 불가

DICOM의 HTJ2K처럼 바이트 일부만 수신해서 저해상도를 먼저 표시하는 Progressive Loading이 NIfTI gzip에는 없습니다. .nii.gz를 서버에서 스트리밍하더라도 gzip 특성상 전체를 수신해야 압축 해제가 가능합니다.

💡 NIfTI의 메타데이터 공백은 별도 사이드카 파일(JSON)로 보완하는 패턴이 일반적입니다. AI 파이프라인에서 NIfTI를 생성할 때 환자 정보, 모달리티, W/L 범위 등을 JSON으로 함께 생성하고, Cornerstone3D의 MetaData Provider에 수동으로 등록하면 일부 기능을 복구할 수 있습니다.

05 · NIfTI in CS3D

Cornerstone3D의 NIfTI 로드 아키텍처

@cornerstonejs/nifti-volume-loader는 v2.0에서 imageId-first 방식으로 전면 재설계되었습니다. 기존 volume-first 방식과 달리 NIfTI 파일을 슬라이스 단위 imageId로 분해하여 일반 DICOM 볼륨과 동일한 파이프라인에서 처리합니다.

1

NIfTI URL → 첫 바이트 스트림 파싱

전체 파일을 다운로드하지 않고 헤더 부분만 스트림으로 먼저 수신해 메타데이터(dims, pixdim, sform 등)를 추출합니다.

2

슬라이스 단위 imageId 생성

nifti:https://server/file.nii.gz#0, #1, ... 형태로 각 슬라이스를 imageId로 분해합니다. DICOM과 동일한 imageId 기반 시스템을 재사용합니다.

3

MetaData 캐시 등록 (LPS 변환 포함)

sform/qform 행렬을 읽어 LPS 좌표계로 변환한 ImagePositionPatient, ImageOrientationPatient 등을 MetaData Provider에 등록합니다.

4

Volume 사전 할당 & 스트리밍 로드

DICOM 볼륨과 동일하게 createAndCacheVolume → load()로 슬라이스 단위 스트리밍 로드합니다. 단, 개별 슬라이스 fetch 시 전체 .nii.gz에서 해당 오프셋을 Range Request로 가져옵니다.

// @cornerstonejs/nifti-volume-loader v2 사용법
import {
  cornerstoneNiftiImageLoader,
  createNiftiImageIdsAndCacheMetadata,
} from '@cornerstonejs/nifti-volume-loader';
import { imageLoader, volumeLoader } from '@cornerstonejs/core';

// 1. NIfTI 이미지 로더 등록
imageLoader.registerImageLoader('nifti', cornerstoneNiftiImageLoader);

// 2. 헤더 파싱 & imageId 배열 생성 (슬라이스 수만큼 생성됨)
const imageIds = await createNiftiImageIdsAndCacheMetadata({
  url: 'https://server/brain_1024.nii.gz',
});
// → ['nifti:https://...#0', 'nifti:https://...#1', ... '#N']

// 3. Stack Viewport (v2 신규 — Volume 없이도 사용 가능)
viewport.setStack(imageIds);

// 4. Volume Viewport (기존 방식)
const volume = await volumeLoader.createAndCacheVolume(volumeId, { imageIds });
await volume.load();

// ⚠️ Window/Level은 직접 계산 후 설정 필요
viewport.setProperties({ voiRange: { lower: -1000, upper: 3000 } });

⚠️ NIfTI 슬라이스를 Range Request로 가져오려면 서버가 Accept-Ranges: bytes를 지원해야 합니다. 미지원 시 슬라이스 요청마다 전체 파일을 재다운로드하는 최악의 상황이 발생합니다. REST API로 제공하는 경우 반드시 Range Request 지원 여부를 확인하세요.

06 · 1024×1024 Memory Analysis

1024×1024 해상도 — 메모리 실측 계산

표준 CT는 512×512 해상도입니다. 1024×1024는 픽셀 수가 4배이며, 메모리 증가는 단순히 4배가 아니라 CPU + GPU 양쪽에서 복합적으로 발생합니다.

1024×1024×300슬라이스 Float32 상세 계산

복셀 수1,024 × 1,024 × 300 = 314,572,800 복셀

CPU 메모리 (Float32)314,572,800 × 4 bytes ≈ 1.2 GB

GPU 3D 텍스처동일 볼륨 추가 ≈ 1.2 GB

세그멘테이션 오버레이RGBA × 같은 크기 ≈ 1.2 GB 추가

총 예상 메모리≈ 2.4 ~ 3.6 GB

512×512 표준 CT

~300 MB

1024×1024 Int16

~600 MB

1024×1024 Float32

~1.2 GB

+SEG 오버레이

~2.4 GB+

* CPU + GPU 합산 / 300슬라이스 기준

07 · GPU Limits

WebGL 3D 텍스처 한계 — 가장 먼저 막히는 벽

메모리 이전에 WebGL 3D 텍스처 크기 제한이 먼저 문제가 됩니다. 브라우저와 GPU에 따라 최대 텍스처 크기가 다르며, 1024×1024×300 볼륨을 단일 3D 텍스처로 올리려고 하면 내장 그래픽 환경에서 실패할 수 있습니다.

환경	MAX_3D_TEXTURE_SIZE	1024×1024×300 가능 여부	비고
외장 GPU (데스크탑)	2048 ~ 16384	대부분 가능	고성능 GPU는 문제없음
내장 GPU (Intel/AMD)	512 ~ 2048	환경 의존	512 제한 시 실패
Apple Silicon (M1/M2)	2048	가능	통합 메모리 공유
모바일 (iOS Safari)	512 ~ 1024	위험	OOM 크래시 빈번
모바일 (Android Chrome)	512 ~ 2048	기기 의존	메모리 압박 심각

🚨 WebGL에서 gl.MAX_3D_TEXTURE_SIZE가 512인 기기에 1024×1024 텍스처를 올리려 하면 GL_INVALID_VALUE 에러와 함께 텍스처 생성이 실패합니다. Cornerstone3D는 이 상황에서 렌더링이 완전히 중단됩니다. 프로덕션 배포 전 반드시 최소 사양 기기에서 검증하세요.

// 런타임에서 WebGL 최대 텍스처 크기 확인
const canvas = document.createElement('canvas');
const gl = canvas.getContext('webgl2');
const maxTexSize = gl.getParameter(gl.MAX_3D_TEXTURE_SIZE);
console.log(`MAX_3D_TEXTURE_SIZE: ${maxTexSize}`);

// 1024×1024 적재 가능 여부 사전 체크
if (maxTexSize < 1024) {
  // 다운샘플 버전으로 폴백
  loadLowResolutionVolume();
} else {
  loadFullResolutionVolume();
}

08 · Pros & Cons

NIfTI 1024×1024 — 장점과 단점 종합

✅ 장점

• AI 파이프라인과의 직접 연결
  AI 모델이 NIfTI로 결과를 출력하는 경우 변환 없이 바로 렌더링 가능
• 단일 파일 관리
  DICOM처럼 슬라이스마다 파일이 분리되지 않아 파일 관리가 단순
• 고해상도 세부 표현
  1024×1024는 512×512 대비 미세 구조(혈관, 병변 경계) 표현력 4배 향상
• 연구/분석 도구 호환성
  FSL, FreeSurfer, ANTs 등 신경영상 분석 도구와 포맷 일치

⚠️ 단점 / 위험

• 메모리 2~4GB 요구
  세그멘테이션 포함 시 저사양 기기에서 탭 크래시 위험
• Progressive Loading 불가
  gzip 전체 압축 특성상 점진적 렌더링 없어 초기 로딩 느림
• 좌표계 변환 오류 위험
  sform/qform 비표준 파일 시 영상 좌우 반전 등 임상적 오류
• 임상 메타데이터 완전 부재
  환자 정보, W/L 프리셋, 모달리티 기반 기능 모두 수동 구현
• DICOM 표준 도구 미호환
  측정값 SR 저장, DICOM SEG 연동, PACS 연동 불가
• WebGL 텍스처 한계 충돌
  내장 그래픽·모바일 기기에서 텍스처 생성 실패 가능

09 · Issues & Mitigations

예상 문제점과 대응 전략

1

문제: gzip 전체 다운로드 → 초기 로딩 수십 초

1024×1024×300 Float32 볼륨은 압축 전 ~1.2GB입니다. gzip 압축률 3:1 가정 시 약 400MB를 네트워크로 수신한 후 브라우저에서 압축 해제해야 첫 렌더가 가능합니다. 4G 환경 기준 1분 이상 소요될 수 있습니다.

대응: 서버에서 Content-Encoding: gzip으로 전송하면 브라우저가 자동 해제하므로 nifti-reader-js의 JS gzip 해제 오버헤드를 제거할 수 있습니다. 또는 서버에서 Progressive 방식 다운샘플 버전(256×256)을 먼저 제공하고 백그라운드에서 고해상도를 로드하는 2단계 전략을 도입합니다.

2

문제: 세그멘테이션 오버레이 포함 시 OOM

볼륨(1.2GB) + 세그멘테이션 RGBA(1.2GB) + GPU 텍스처 복사(1.2GB+) = 3.6GB+. 16GB RAM 기기도 브라우저 탭 메모리 한도(일반적으로 2~4GB)에 걸릴 수 있습니다.

대응: 세그멘테이션을 픽셀 데이터로 올리지 않고 BBox/Contour 좌표 JSON으로 받아 Canvas 2D로 그리는 방식으로 전환합니다(이전 Cornerstone3D 논의에서 검토한 접근). 세그 메모리를 사실상 0에 가깝게 줄일 수 있습니다.

3

문제: Window/Level 자동 설정 없음

NIfTI 헤더에 WindowCenter/Width가 없어 Cornerstone3D가 기본값(전체 데이터 범위)으로 설정합니다. CT 영상이 완전히 하얗게 또는 검게 표시되는 현상이 발생합니다.

대응: 볼륨 로드 후 샘플링 기반 백분위수 계산으로 W/L을 자동 추정합니다. 또는 서버에서 W/L 추천값을 JSON 사이드카로 함께 제공하고 Cornerstone3D MetaData Provider에 등록합니다.

4

문제: 좌표계 반전 (임상 안전 위험)

sform_code = 0이거나 비표준 NIfTI 파일은 nifti-volume-loader의 자동 변환이 실패해 좌우 반전이 발생할 수 있습니다.

대응: 로드 후 반드시 해부학적 랜드마크(코, 귀 등)를 기준으로 뷰포트 방향을 시각적으로 검증하는 QA 단계를 추가합니다. L/R 방향 레이블 표시 여부를 자동 테스트에 포함시킵니다.

5

문제: Range Request 미지원 서버에서 슬라이스 로드 폭발

nifti-volume-loader v2는 슬라이스별 imageId로 분해 후 각각 Range Request를 시도합니다. 서버가 미지원하면 슬라이스 300개 × 전체 파일 크기 요청이 발생합니다.

대응: 서버에 Accept-Ranges: bytes 헤더 지원을 반드시 추가하거나, Range Request 미지원 시 전체 파일 1회 다운로드 후 클라이언트에서 슬라이스 분할하는 폴백 로직을 구현합니다.

10 · Conclusion

기술 검토 결론 — 도입 가능하지만 조건부

Cornerstone3D에서 NIfTI + 1024×1024 조합은 기술적으로 불가능하지 않습니다. @cornerstonejs/nifti-volume-loader v2가 imageId-first 방식으로 재설계되면서 DICOM 파이프라인과 상당 부분 통합되었습니다. 단, 아래 전제 조건이 충족되어야 프로덕션 적용이 가능합니다.

항목	상태	필요 조치
기본 렌더링 (MPR)	가능	nifti-volume-loader 설치 + imageId 등록
좌표계 (LPS 변환)	주의	sform/qform 유효성 검증 + 시각 QA 필수
Window/Level	수동 필요	백분위수 추정 or 서버 JSON 사이드카
Progressive Loading	불가	2단계 해상도 전략(256→1024) 설계 필요
메모리 (1024×1024)	위험	대상 기기 최소 사양 정의 + OOM 폴백 필수
GPU 텍스처 한계	기기 의존	런타임 MAX_3D_TEXTURE_SIZE 체크 + 폴백
세그멘테이션 오버레이	메모리 위험	픽셀 대신 BBox/Contour JSON 방식 전환 검토
DICOM SR 측정 저장	불가	자체 JSON 포맷으로 어노테이션 관리
Range Request 서버	서버 설정 필요	Accept-Ranges: bytes 헤더 지원 추가

🧭 현재 VTK.js 커스텀 뷰어처럼 NIfTI REST API + 비표준 렌더링이 핵심인 프로젝트라면, Cornerstone3D의 DICOM 중심 제약보다 직접 구현이 여전히 유리합니다. 반면 향후 DICOM 기반 PACS 연동, 세그멘테이션 편집 도구, 다중 뷰포트 동기화 확장이 예정되어 있다면 지금부터 Cornerstone3D 기반으로 NIfTI 지원을 구축하는 것이 장기적으로 이득입니다.

참고: CS3D NIfTI Loader v2 · Cache API · NIfTI Standard

2026 · NIfTI Viewer 프로젝트 — Cornerstone3D NIfTI 기술검토