10. DICOM 파일 내부 구조 분석 예제

DICOM은 단순히 이미지 파일로 보기에는 너무나 복잡한 구조를 가지고 있다.
그 이유는 DICOM 파일이 단순한 픽셀 데이터만을 담고 있는 것이 아니라, 
의료 영상과 관련된 모든 메타데이터를 태그(Tag) 구조로 저장하고 있기 때문이다.
DICOM 파일의 내부는 규칙적인 형식을 따르며, 실제로는 Tag – VR – Length – Value라는 구조가 반복적으로 이어진다.
이번 글에서는 실제 DICOM 파일을 바이트 수준에서 분석하면서 각 정보가 어떻게 저장되어 있는지를 단계별로 해석해 본다.
이 과정을 이해하면, 특정 태그 값을 수동으로 수정하거나, 파싱 오류의 원인을 직접 진단할 수 있는 실력을 갖출 수 있다.

 

 

1. DICOM 파일 구조 복습

DICOM 파일은 다음과 같은 순서로 구성된다:

구역	설명
Preamble (128 bytes)	파일 시작부 – 대부분 비어 있음
DICM (4 bytes)	파일 식별 문자
File Meta Information	파일 정보 (Transfer Syntax, UID 등)
Data Set	실제 메타데이터 + 이미지 데이터 (태그 기반)
Pixel Data	이미지 바이너리 데이터

이번 글에서는 File Meta Information + Data Set을 중심으로 분석한다.

 

2. 분석 예시: 실제 DICOM Hex 구조 일부

아래는 실제 DICOM 파일의 일부를 Hex 편집기로 열었을 때 보이는 내용 일부이다:

08 00 16 00 55 49 1A 00 31 2E 32 2E 38 34 30 2E 
31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 
32

이 Hex 값을 표준에 정의된 길이의 바이트 별로 구분한 뒤, 각 부분을 해석하면 다음과 같은 구조가 된다:

08 00 16 00 /*tag*/ 
55 49 /*VR*/
1A 00 /*Length*/
31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 
32 /*Value*/

1단계: Tag

태그는 4바이트로 구성되며, 앞 2바이트는 Group Number, 뒤 2바이트는 Element Number다.

• 예: 0008,0016 → SOP Class UID
• 예: 0010,0010 → Patient's Name

2단계: VR (Value Representation)

VR은 데이터 형식을 나타낸다. 예: PN, DA, UI, CS, LO 등

바이트값	ASCII	해석
5	55	ASCII 문자 U
6	49	ASCII 문자 I

위 예시에서는 UI가 VR로 들어가 있다. 이는 UID 형식의 문자열이라는 뜻이다.

 

3단계: Length

이후 2~4바이트는 **데이터의 길이(Length)**를 나타낸다.
예: 00 1A → 26바이트 (UID 문자열 길이)

 

4단계: Value

마지막으로 실제 값이 저장된다. 

31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 32
// 1.2.840.10008.5.1.4.1.1.2

→ 이는 DICOM에서 정의한 CT Image Storage의 SOP Class UID이다.

 

 

3. 전체 해석 정리 

항목	값	설명
Tag	(0008,0016)	SOP Class UID
VR	UI	UID 형식
Length	26	값의 길이
Value	1.2.840.10008.5.1.4.1.1.2	CT Image Storage

이 구조가 DICOM 전체에 반복되며, 이러한 방식으로 수백 개의 데이터 요소가 이어져 저장된다.

 

 

4. Python으로 구조 분석 예시

import pydicom

ds = pydicom.dcmread("sample.dcm")
print(ds[0x00080016])  # SOP Class UID
print(ds[0x00100010])  # Patient's Name
print(ds[0x00080060])  # Modality

→ 이렇게 태그 번호를 16진수로 직접 지정해 접근할 수도 있다.

 

5. 실무에서의 활용 포인트

 

• Hex 에디터에서 직접 DICOM을 열어 수동 분석할 수 있다.
  → 값 위조, 태그 오류 추적에 매우 유용
• PACS 오류 원인 파악
  → VR이 잘못 들어갔거나, UID가 누락되었을 경우 쉽게 확인 가능
• 익명화 처리 전 구조 점검
  → (0010,0010) 환자 이름, (0010,0020) ID 등 민감 태그 위치 확인 가능

 

6. 주의사항

• 일부 VR은 고정 길이를 사용하고, 일부는 가변 길이다.
• Transfer Syntax에 따라 VR 방식이 Implicit일 수도 있다.
  → 이 경우 VR 정보는 생략되고 PACS나 뷰어가 암묵적으로 해석함
• 데이터 해석이 틀리면 파일 전체 파싱이 실패할 수 있다.

---

결론

DICOM 파일은 내부적으로 매우 정교한 구조를 가지고 있다.
각 데이터는 Tag, VR, Length, Value의 조합으로 저장되며,

이러한 구조를 이해하면 Hex 에디터로 직접 파일을 분석하거나, 오류 추적 및 구조 점검을 수행할 수 있다.
이번 예제를 통해 구조 해석 능력을 갖추면 실제 의료 영상 데이터를 보다 정확하고 안정적으로 다룰 수 있다.
다음 글에서는 환자 정보, 검사 정보, 이미지 정보의 구조 이해라는 주제로 DICOM 내 데이터 계층 구조를 더욱 깊이 있게 살펴볼 예정이다.