다음은 Length 입니다.

여기서 Length는 Value의 길이를 byte 단위로 표시한 것입니다. Length 자체의 Byte길이는 4byte이고요.

그리고 실제 데이터는 Length뒤에 Length byte 만큼 위치하게 됩니다.

그럼 지금까지 Element구조를 아래와 같은 테이블로 나타냅니다. (DICOM Stadard에서 참조)

그런데 여기서 테이블 이름을 자세히 보시면 With Explit이라는 문구가 눈에 들어옵니다.

Explit이 있다면 반대인 Implicit이 존재하겠네요.

실제 Implicit 테이블 구조 입니다.

두 테이블의 차이점을 비교해보면 implicit인경우 VR이 빠져있습니다.

즉 Explicit은 명시적으로 File로 저장시에 VR을 포함하여 저장하고, Implicit인경우에는 VR을 빼고 저장합니다.

반대로 File을 읽을 때도 마찬가지고요.

그럼 만약 파일을 읽을 때 VR이 없으면 해당 Element의 Value가 나이 인지 날짜인지 데이터 타입이 뭔지 어찌 알까요?

그건 어차피 각 Element Tag에 대한 의미가 이미 정의가 되어 있기에 각 Element의 VR 종류도 정해져 있어서

뺀상태로 저장하는 겁니다. 아마 제 개인적인 생각으로는 파일저장 or DICOM 통신시에 데이터를 조금이라도 줄여보려는

목적인듯한데.. 실제 필드에서는 이런것 때문에 간혹 문제가 생기는 경우가 있습니다.
(각 Element Tag의 VR값은 DICOM Standard Part6. Data Dictionary 에서 확인 할 수 있습니다.)

한단계 더 전으로 가면 그럼 이 파일이 Explicit VR인지 Implicit VR인지 어떻게 구분할까요?

DICOM Tag중 Transfer Syntax UID(0020,0010)를 보고 판단 합니다.

위 표가 Transfer Syntax가 가지는 UID값의 종류입니다.
(전체는 DICOM Standard Part6. Data Dictionary에서 확인하세요)

해당 DICOM파일의 Transfer Syntax UID값이 1.2.840.10008.1.2 인경우 이 파일은 Implicit VR 형태의 파일이라는 의미입니다.

추가적으로 Little Endian 인지 Big Endian인지도 구분합니다.

간혹 GE장비 같이 Global 장비와 연동시 Linux Server를 사용하는경우 Big Endian을 사용하는경우가 아주 간혹 있습니다.

이런식으로 Little Endian과 Big Endian이 서로 호환되지 않아 문제가 생기면 CT영상같은경우 Pixel Data가 2byte이기에

서로 다른값으로 해석되게 되어 영상이 이상하게 깨지면서 하얗게 표시되거낭 영상이 깨지면서 너무 어둡게 표시되는 경우

Endian쪽을 의심해 볼만 합니다.

전 초기 GE PACS와 연동시 붉은색 계통의 내시경 영상이 푸른색 계통의 줄무늬가 가있는 형태의 영상으로 보이는

난감한 문제가 있었습니다.

결국 Pixel Data를 확인해 보니 byte의 순서가 다르게 저장되어 발생되는 거였죠. 근데 왜 그렇게 저장되는지는 원인을

찾을 수 없어서 무식하게 내부적으로 Byte Endian을 강제 변화 후 전송하는 방식으로 문제를 해결한 적이 있습니다.

한 참을 지난 후에야 근본적인 원인을 파악하여 해결 하였던 기억이 나네요.

그냥 제 개인적인 경험담 이었습니다.

다음은 VR입니다. VR은 Value Refresentation의 약자로 즉 Element가 가지고 있는 Data(Value)가 어떤형태인지를 나타냅니다.

단지 Programming에서 정수형, 문자열, 소수점형 처럼 구분하지 않고 의미로 구분합니다.

예를들어, 고유이름, 정수형 문자, 소수점형 문자, 날짜, 시간, 나이…. 와 같은 형태를 가집니다.

DICOM Standard Part5. Data Structures and Encoding에 보시면 모든 종류의 VR이 나와있습니다.

대충 훓터 보면 총 20~30개의 VR이 존재하며 VR Name이 AS인경우 Age String을 의미합니다.

즉 VR이 AS인 Element에 Value값이 “32”라는 문자열이 저장되어 있다면 32세를 의미한다는 겁니다.

실제로는 AS는 나이를 표현할때 숫자를 적고 다음 y를 같이 적어줍니다.즉 32세라면 “32y”라는 형식으로

저장합니다. 여기서 y는 year를 의미하죠. 혹 아기의 나이를 적을때는 32개월인경우 Month의 약자인 “32m”이라고

적고, “32d”는 Day의 약자로 32일을 의미합니다.

아래의 그림과 같이 DICOM Standard Part5 에 보시면 각 VR값의 Value가 가질수 있는 Data의 범위, byte수 및 Max길이등등

자세히 나와있으니 참고하세요.

이 블로그 자체가 정리 및 기록의 목적을 두기에 이 아래부분은 제가 나름 생각나는데로 두서 없이 적은 내용이니

굳이 보시지 않으셔도 됩니다.

—————— 정 리 ————————
각 Value가 String형식중에 Item이 여러개인경우 Backslash (“\”)로 구분한다.
UID VR은 고유값을 의미하며, SOP Instance UID, Study Instance UID와 같은 값에서 사용.
여기서 구분자(.)의 다음 값은 ‘0’을 가지면 안됨
Date 같은 VR은 2010년 03월 02일시 “20100302”와 같이 다 붙여서 사용하고 03과 같이 총 8자리의 자리수를 맞춰주자
Person Name에서 구분자로 “^”(5EH)를 사용하자. space를 사용해도 되긴 함. 하지만 US장비와 같이
DICOM QR측에서 인식하지 못하는 경우가 자주 발생.

DICOM File은 확장자로 일반적으로 DCM, DIC 두가지를 사용합니다.

즉, 파일이름이 test.dcm 또는 test.dic는 일반적으로 DICOM파일을 의미합니다.

하지만 실제로 Programming에서 DICOM파일 여부는 파일내부에 Header를 보고 DICOM파일 여부를 확인합니다.
(이건 다시 자세히 설명 드리죠)

dic확장자는 좀 예전에 초기에 사용했었고, 요즘 대부분은 dcm을 사용하니 참고로만 알고 계세요.

그럼 DICOM파일의 안을 들여다 보면 우선 아래와 같은 구조를 가지고 있습니다.

DICOM파일은 Element라는 단위로 구성되어있습니다. 그림에서 보는바와 같이 많은 Element들이 모여 하나의

DICOM파일을 구성합니다.

다음은 Element 구조입니다.

하나씩 살펴보죠.

Tag는 이 Element를 구분하는 이름표 입니다. 쉽게 유니클로 같은 매장에서 각 옷의 종류를 구분하기위해서 붙여 놓은 상표 태그로

생각하 시면 되겠네요.

이 Tag는 다시 Group Tag와 Element Tag로 구분되죠.

Group Tag는 Tag가 너무 많다보니 비슷한 종류를 묶어 Group화 시켜 놓은겁니다. 예를들어 환자와 관련된 Tag, Image와 관련된

Tag, 초음파 검사와 관련된 Tag등을 Group화 한것이죠.

다음 Element Tag는 그 Group에서 고유하게 값을 가져서 다른 Tag와 구분하게 됩니다.

이런 Group Tag와 Element Tag는 각각 2byte씩의 크기를 가지며 보통 아래형식으로 표기합니다.

0010, 0020
여기서 의미는 0010이 Group Tag 입니다. 0010 Group은 Patient(환자)와 관련된 Group 을 뜻합니다.

0010, 0020은 Patient ID를 의미합니다.

각 Tag는 DICOM Standard라는 표준집에 정의되어 있습니다. 즉 0010,0020 Tag를 가진 Element는

Patient ID를 뜻하는 Element
라고 이해하게 되는겁니다.

Group Tag(2byte) + Element Tag (2byte) 가 총 4byte이기에 Element가 가질수 있는 Tag는

0000, 0000 ~ FFFF, FFFF 까지의 Tag를 가지게 됩니다.

추가적으로 DICOM Standard에서 정의된 Tag는 Group Tag값이 짝수를 가지며 (이걸 Public Tag라고 구분지어 얘기합니다.)

개별적으로 작성한 Tag는 Group Tag가 홀수 입니다.(이걸 Private Tag라고 구분합니다.)

이런 모든 Tag의 정의는 DICOM Standard Part3. Information Object Definitions를 참조하시던가,

DICOM Standard Part 6.Data Dictionanry를 참조하세요.

각 Tag에 대한 구체적인 설명 및 사용법은 Part3를 보시고, 일반적인 Tag의 제목 및 형식 같은 구조만

보시길 원하시면 Part.6를 참조하시면 됩니다.

또한, Element와 관련된 자세한 설명은 DICOM Standard Part 5. Data Structures and Encoding을 참조하세요.

항상 어느 주제를 가지고 말하다보면 첫 마디에 “OOOO란?” 식의 글이 나타납니다.

저도 어쩔수 없이 첫 시작은 “DICOM이란?” 주제를 가지고 시작 하려고 합니다.

우선 DICOM이란 약자입니다. 이 Full Name이 뭘까요? 아래와 같습니다.

• Digital Imaging and Communications in Medicine

하나씩 풀어 볼까요?

Digital Imaging은 영상을 뜻합니다. 맨 뒤에 In Medicine이 붙어 있기에 의료영상이라는

분류를 하게 됩니다. 의료영상이라는것은 의료장비에서 나오는 이미지 데이터를 뜻하지요.

의료 장비는 CT, MR, 내시경, 초음파… 등등 영상이 나오는 모든 장비를 뜻합니다.

새로 개발되는 의료장비인 PET 혹은 심지어 적외선 카메라도 의료장비로 사용됩니다. 즉 적외선 카메라로 획득된 영상을

의료 영상 이라고 할 수 있습니다.

다음 Digital Imaging에는 저장이라는 의미가 함축되어 있습니다. 의료영상을 저장 하는 방식 이라고 생각하면 쉬울까요?

아니면 의료영상을 저장하는 파일형식 이라고 생각해도 이해하기 쉽겠네요.

다음 Communications는 통신입니다. 즉 의료영상의 통신을 의미하죠. 여기에 DICOM이 왜 사용하는지 궁극적인

목적이라고 할 수 있습니다.

DICOM의 사용목적을 대충 자료를 찾아보면

이 기종간의 의료영상 장비간의 영상데이터의 자료교환을 위한 표준
이런식으로 얘기를 하죠.

즉 이말은 전세계에 CT, MR등 많은 의료장비들이 있고 또한 각 CT장비에도 Toshiba, GE, Simense와 같이

많은 업체들이 있습니다. 그럼 이런 모든 업체들의 장비들끼리 데이터를 공유한다면 하나의 규칙이 필요하게 됩니다.

보통 사진 찍는 카메라가 보통 JPEG이라는 표준으로 사용하듯이 의료장비들은 DICOM이라는 표준을 따르는 것이지요.

그런데 여기서 JPEG과 다른점은 DICOM은 마지막 통신에 대한 규칙도 정의되어 있다는 겁니다. 장비와 장비끼리

혹은 장비와 PACS끼리 이 영상데이터를 주고 받는데 필요한 규칙까지도 같이 정의 되어있는겁니다.

그래서 DICOM은 아래처럼 나타낼 수도 있겠네요.

DICOM 파일 포맷 + DICOM 통신 프로토콜

앞으로 정리 할 내용도 먼저 DICOM 파일 포맷에 대해 설명하고, DICOM 통신에 대해서도 정리하고자 합니다.