다음은 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을 강제 변화 후 전송하는 방식으로 문제를 해결한 적이 있습니다.

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

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