From Mirek Socha zapraszam!

DICOM: Wszystkie tematy DICOM na jednej stronie

DICOM Digital Imaging and Communications in Medicine,
standard cyfrowej wymiany informacji medycznych

Opracował: mgr inż. Mirosław Socha

Informacje zawarte poniżej pochodzą z mojej pracy dyplomowej, obronionej w 2005r. Zawarte informacje mogą być częściowo nieaktualne, zwłaszcza w kwestii szczegółowych rozwiązań. Sądzę jednak, że mogą być cenna dla osób, które zaczynają swoją przygodę z DICOM'em.


1. Wprowadzenie

Wraz z rozwojem tomografii komputerowej w latach siedemdziesiątych konieczne stało się opracowanie standardu umożliwiającego wymianę informacji graficznych oraz towarzyszących im danych medycznych między różnymi urządzeniami i systemami informatycznymi. Pierwszy zarys standardu został opracowany w 1983 roku przez American College of Radiology (ACR) oraz National Electrical Manufacturers Association (NEMA) i został opublikowany pod nazwą ACR-NEMA Standards Publication No. 300-1985. W 1988 roku powstała druga wersja dokumentu, zaś w 1993 roku powstała wersja trzecia, znacznie rozbudowana i uzupełniona o nowe możliwości. Zmieniono wówczas nazwę standardu na Digital Imaging and Communications in MedicineDICOM.

Standard DICOM powstał w celu popularyzacji cyfrowej wymiany danych, ułatwienia tworzenia oraz rozbudowy systemów archiwizacji obrazów PACS (ang. Picture Archiving and Comunication Systems) oraz wymiany informacji medycznych z innymi systemami informatycznymi stosowanymi w medycynie (ang. Hospital Information SystemHIS). DICOM jest uzupełnieniem standardu Health Level SevenHL7 o zasady komunikacji i wymianę obrazów w medycynie, nie występujących w normie HL7 .

Osoby zainteresowane analizą danych medycznych bardzo szybko spotkają się z plikami DICOM. Obecnie istnieje duża liczba różnego rodzaju oprogramowania, które umożliwia zaglądnięcie do plików DICOM. Przykładowo program Matlab posiada funkcje umożliwiające analizę (dicominfo) oraz wczytywanie (dicomread) danych medycznych z plików DICOM. Jednak po zaglądnięciu bardzo szybko okazuje się, że informacji jest tak dużo, że ich analiza jest bardzo trudna.

W niniejszym opracowaniu chciałem przybliżyć podstawy DICOMu - ich poznanie może znacznie ułatwić zrozumienie struktury danych zawartych w plikach DICOM. Mam nadzieję, że założenie to przynajmniej w niewielkiej części mi się udało :) Zapraszam do lektury!

2. Tematyka

3. Biblioteki

4. Informacje w sieci


5. Opinie

Komentarz: 
Autor: 
Przepisz code 671

6. Dokumentacja standardu DICOM

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

Dokumentacja opisująca DICOM jest redagowana przez NEMA Diagnostic Imaging and Therapy Systems Division i dostępna w postaci zestawu następujących dokumentów:

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

7. Opis standardu DICOM

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

Standard DICOM powstał w celu odzwierciedlenia rzeczywistych informacji medycznych w postaci spójnego systemu informatycznego. Rysunek 1, zaczerpnięty z dokumentu PS 3.3, przedstawia model rzeczywistych danych zaimplementowany w standardzie DICOM. Model przedstawia sposób łączenia różnych informacji medycznych oraz zależności występujące między nimi. Wartości liczbowe obok strzałek określają możliwą liczbę połączeń między informacjami.


Rysunek 1. Model rzeczywistych danych medycznych zaimplementowany w standardzie DICOM, zaczerpnięty z dokumentu PS 3.3 standardu DICOM.

Do najistotniejszych informacji można zaliczyć:


Rysunek 2 przedstawia przykład powiązania danych rzeczywistych z modelem informatycznym zastosowanym w DICOM.

Struktura danych DICOM jest zbieżna z informacjami rzeczywistymi. Dane powiązane są w hierarchiczne drzewa ułatwiające interpretację oraz umożliwiające łatwą ich modyfikację.

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

8. Budowa standardu DICOM

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

DICOM został przystosowany do sieciowej wymiany informacji (on-line) w architekturze klient-serwer, poprzez protokół TCP/IP oraz do współpracy z nośnikami wymiennymi (off-line), takimi jak dyskietki, dyski CD czy MOD. Wymiana danych na tych nośnikach odbywa się poprzez systemy plików ISO 9660 oraz FAT16. Dodatkowo dla nośników fizycznych tworzony jest plik DICOMDIR przechowujący informację o wszystkich plikach DICOM na nośniku.

Powiązania między częściami standardu przedstawia powiązania między dokumentami standardu przy wymianie danych przez sieć oraz przez nośniki fizyczne. Tłumaczenia pojęć występujących na schemacie znajdą się w dalszym tekście.


Rysunek 3. Zależności między dokumentami standardu DICOM przy wymianie informacji przez sieć (a) oraz przez nośniki fizyczne (b). Źrodło: dokument PS 3.1

Dla metod wymiany danych, zdefiniowano wspólną reprezentację danych (format danych, ang. Information Object, dokument PS 3.3) oraz rodzaje usług-serwisów (ang. Service Classes, PS 3.4) opisujących sposób współdziałania aplikacji. Współpraca aplikacji polega na wymianie specyficznych rozkazów (ang. DICOM Commands, PS 3.7). Dokładnie zdefiniowany jest poziom zgodności – wyszczególniono, jakie informacje muszą być zawarte w konkretnych przypadkach (PS 3.7, 3.8 i 3.10). Aby komunikacja była możliwa, dwa połączone systemy ustalają role jakie będą pełnić podczas komunikacji. Określają, który system jest serwerem danych (ang. Service Class Provider - SCP), a który klientem (ang. Service Class User - SCU). Określają również metodę kodowania przesyłanych danych (little endian, big endian, JPG itp.).

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

9. Model informacji

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

Wprowadzono jasno sprecyzowany i dokładnie określony model informacji (ang. Information Objects Definition – IOD, dokument PS 3.3), określający format danych dla różnych typów informacji, takich jak: obrazy, przebiegi czasowe, obiekty graficznych, raporty, wydruki itp. Model informacji IOD grupuje dane w tematycznych zbiorach, zwanych Entities oraz podzbiorach zwanych modułami. Każdy moduł tworzony jest przez zbiór atrybutów. Rysunek 4 prezentuje budowę obiektu IOD.


Rysunek 4. Struktura modelu informacji IOD - Information Object Definition, PS 3.3.

9.1. Podstawowa jednostka danych – Data Element

Atrybut jest opisywany formatem elementu danych tzw. Data Element, zdefiniowanym w słowniku danych (PS 3.6) i stanowi podstawową jednostkę danych. Data Element opisywany jest przy pomocy:

9.2. Strumień informacji – Data Set

Strumień informacyjny (ang. Data Set) jest uporządkowanym strumieniem elementów danych (ang. Data Element) co przedstawiono na rysunku 5. Norma w dokumencie PS 3.3 w pełni opisuje katalog typów danych, rodzaju danych, itp.


Rysunek 5.

Oprócz definicji obiektu danych istotne jest skojarzenie z nim elementu usługi czyli tzw. Service Element. Obiekt Service-Obiect Pair (SOP) łączy dane z serwisami i definiuje różne usługi związane z modelem informacji IOD. W standardzie DICOM wprowadzono również techniki umożliwiające jednoznaczną identyfikację oraz ochronę danych (PS 3.15), pozwalające na sprecyzowanie zależności między danymi, np. podczas transmisji przez sieć. Norma nie definiuje szczegółów implementacji, wymogów dotyczących możliwości i funkcji urządzeń oraz sposobu testowania, czy zatwierdzania zgodności konkretnej implementacji ze standardem DICOM. Z tego też powodu zdarza się, że dwa różne urządzenia, będące zgodnie ze standardem DICOM, nie są zdolne do wymiany informacji! Jest to przejawem walki różnych producentów o wpływy na rynku.

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

10. Dane CT zapisane na nośniku fizycznym

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

Dane będące wynikiem badania CT mogą być zapisane na płycie CD-R w standardzie DICOM. Zawartość płyty zdefiniowana jest w dokumentacji standardu w dokumencie PS 3.10.


Rysunek 6. Struktura danych na nośniku fizycznym danych DICOM, z dokumentu PS 3.10.

Fizyczny nośnik danych zawiera pliki w formacie opisanym w obiekcie DICOM File Format. Obiekt służy do przechowywania informacji w postaci plików. Każdy plik zawiera informację na temat jednego obiektu Service-Obiect Pair instance (SOP instance) oraz informacje o pliku, tzw. DICOM File Meta Information.

Każdy obiekt DICOM File Meta Information zbudowany jest ze 128 bajtowej preambuły wypełnionej zerami, identyfikatora pliku DICOM (ang. DICOM prefix) zawierającego czteroliterowy ciąg liter „DICM” oraz zestawu elementów danych (ang. Data Element) opisujących plik. Elementy te mają identyfikator postaci (0002,xxxx). Po elementach danych należących do informacji o pliku (DICOM File Meta Information), znajduje się zakodowany zgodnie z dokumentem PS 3.5 ciąg elementów danych (DICOM Data Set) prezentujący jeden obiekt Service- Obiect Pair instance. Obiektem SOP może być np. jeden slajd CT (obraz jednej rekonstrukcji danych CT) lub obiekt opisujący dane na nośniku, tworzący plik DICOMDIR.

Nośnik fizyczny zawiera katalogi z plikami, w których to znajdują się właściwe informacje medyczne. Oprócz nich zawsze zapisywany jest specjalny plik o nazwie DICODIR, opisujący zawartość nośnika. Rysunek 7 przedstawia zawartość pliku DICOMDIR oraz sposób powiązania zawartości z innymi plikami na nośniku.


Rysunek 7. Przykład struktury nośnika fizycznego z danymi DICOM, przedstawiający zawartość pliku opisu nośnika DICOMDIR oraz powiązania między danymi, PS 3.10.

Plik DICOMDIR zawiera informacje na temat wszystkich plików na nośniku. Niektóre Data Elements obiektów SOP znajdują się tylko w pliku danych, a niektóre tylko w DICOMDIR. Dane w pliku DICOMDIR powiązane są w hierarchiczne drzewo, którego korzeniem są Direktory Information. Kolejnym poziomem są dane o pacjentach, następnym badania, potem serie, a na koniec obrazy. Przejścia między kolejnymi poziomami zaznaczone są na rysunku pogrubioną linią, zaś przejścia między obiektami na tym samym poziomie liniami z numerami poziomów. W obiektach zapisanych w DICOMDIR przechowywane są wskaźniki do danych na tym samym i kolejnym poziomie. Dzięki temu, możliwe jest szybkie przeszukiwanie danych w bardzo dużych plikach. Każdy obiekt SOP zapisany w DICOMDIR posiada również informację o pliku na nośniku (w postaci ścieżki dostępu oraz nazwy), w którym znajduje się pełna informacja o nim.

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

11. Binarna zawartość pliku DICOM

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

11.1. Przykład zawartości pliku DICOM

Tabela 1 prezentuje binarną budowę przykładowego pliku w standardzie DICOM. Prezentowany fragment jest początkiem pliku DICOMDIR.


Tabela 1. Przykład binarnej budowy pliku DICOM.

W przedstawionym fragmencie można wyróżnić: 128 bajtową pustą preambułę pliku, identyfikator w postaci czterech liter w kodzie ASCII „DICM”, po którym następuje ciąg danych (strumień informacji – ang. Data Set) w postaci tzw. atrybutów – elementów danych (ang. Data Element). Na rysunku XX przedstawiono schematyczną budowę strumienia danych, prezentowaną wcześniej we wstępie teoretycznym pracy.


Rysunek 8. Budowa strumienia danych DICOM.

Każdy element danych (ang. Data Elements) zawiera czterobajtowy identyfikator elementu danych, tzw. Tag, (wyróżniony kolorem żółtym), składający się z: identyfikatora grupy (dwa bajty) oraz z identyfikatora elementu grupy (dwa bajty). Następnie można wyróżnić, zaznaczony zielonym kolorem tła, dwubajtowy kod typu danych (VR – ang. Value Representation). W zależności od wartości VR występuje od dwóch do dziesięciu bajtów przeznaczonych na długość danych (niebieski kolor tła). Na końcu Data Element znajduje się obszar z danymi, zaznaczony pogrubieniem czcionki. Powyższą strukturę mają wszystkie pliki DICOM zapisane na płycie CD-R.

11.2. Kody Value Representation

Standard DICOM wyróżnia następujące kody VR oraz odpowiadające im typy danych:

VRrozwinięcie symboluopis
ASAge Stringwiek wyrażony w dniach (nnnD), tygodniach (nnnW), miesiącach (nnnM) lub latach (nnnY), np. 018D oznacza osiemnaście miesięcy.
ATAttribute Tagpara 16bitowych liczb całkowitych bez znaku, kodujących identyfikator elementu danych: numer grupy oraz numer elementu grupy
CSCode Stringciąg maksymalnie 16 znaków w kodzie ASCII
DADatadata w formacie rrrrmmdd (rok, miesiąc, dzień) w kodzie ASCII
DSDecimal Stringciąg znaków ASCII reprezentujący liczbę zmiennoprzecinkową
DTDate Timeciąg znaków ASCII zawierający datę oraz czas w formacie: rrrrmmddggmmss.ffffff&hhmm, gdzie ffffff to ułamkowe części sekundy, & jest znakiem „+” lub „­­–”, zaś hhmm jest offsetem godzin i minut
FLFloating Point Single32bitowa binarna liczba zmiennoprzecinkowa pojedynczej precyzji, zdefiniowana w dokumencie IEEE 754:1985
FDFloating Point Double64bitowa binarna liczba zmiennoprzecinkowa podwójnej precyzji, zdefiniowana w dokumencie IEEE 754:1985
ISInteger Stringciąg znaków ASCII reprezentujący liczbę całkowitą ze znakiem
LOLong Stringciąg maksymalnie 64 znaków, bez znaków kontrolnych
LTLong Textciąg maksymalnie 10240 znaków ze znakami kontrolnymi
OBOther Byte Stringciąg bajtów zakończony znakiem NULL
OFOther Float Stringciąg 32bitowych binarnych liczb zmiennoprzecinkowych pojedynczej precyzji
OWOther Word Stringciag 16bitowych słów binarnych
PNPerson Nameciąg znaków zawierający dane personalne pacjenta. Sposób kodowania znaków opisany jest w elemencie danych (0008,0005)
SHShort Stringciąg maksymalnie 16 znaków
SLSigned Long32bitowa liczba całkowita ze znakiem
SQSequence of Itemssekwencja grup elementów danych (ang. Items)
SSSigned Short16bitowa liczba całkowita ze znakiem
STShort Textciąg znaków, zawierający znaki sterujące, o maksymalnej długości 1024. Sposób kodowania znaków opisany jest w elemencie danych (0008,0005)
TMTimeciąg znaków ASCII reprezentujący godzinę w formacie: ggmmss.ffffff, gdzie fffff to milionowe części sekundy
UIUnique Identifier (UID)ciąg znaków zawierający unikatowy identyfikator UID, identyfikujący obiekty DICOM
ULUnsigned Long32bitowa liczba całkowita bez znaku
UNUnknownciąg bajtów o nieznanym sposobie kodowania
USUnsigned Short16bitowa liczba całkowita bez znaku
UTUnlimited textciąg znaków, zawierający znaki sterujące, przechowujący jeden lub wiele akapitów takstu. Sposób kodowania znaków opisany jest w elemencie danych (0008,0005).

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

12. Zawartość DICOMDIR

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

Tabela 3 zawiera zdekodowany fragment pliku DICOMDIR, otrzymany przy pomocy programu dcmdump v3.5.3, będącego częścią projektu DICOM ToolKit(dcmtk) . Program dcmdump pracuje w trybie tekstowym i umożliwia analizę zawartości plików DICOM. Przy pomocy wcięć tekstu program zaznacza kolejne poziomy hierarchii danych. Zastosowano tu również kolorowanie danych, zawartych w przytoczonym wcześniej przykładzie binarnej zawartości pliku.

W prezentowanym fragmencie pliku DICOMDIR usunięto część informacji o podobnej budowie, a pozostawiono jedynie bloki prezentujące podstawowe struktury informacji, takie jak: grupę opisującą pacjenta, badanie, serię czy obrazy. Dokładna analiza oraz wyjaśnienie zawartości przeprowadzone zostaną w dalszej części pracy.


Tabela 3. Zdekodowana zawartość przykładowego pliku DICOMDIR.

Każda linia zawiera informację o jednym elemencie danych (ang. Data Element) i zbudowana jest z dwóch głównych części rozdzielonych znakiem #:

Poniższa tabela zawiera trzy wybrane elementy danych DICOM zaczerpnięte z pliku DICOMDIR oraz prezentuje sposób interpretacji informacji zawartych w wierszu.

zdekodowany element danych – Data Elementinformacje dodatkowe
identyfikator: Tag (group,element)typ danych: VR -Value Representationdane: Valuedługość danych w bajtachliczba pod-ciągówopis elementu danych na podstawie Tag
(0002,0000)UL17841MetaElement-GroupLength
(0020,0032)DS[-167.66797\-294.66797\-290]263ImagePosition-Patient
(7fe0,0010)OW0a0a\0a0a\0a0a\...40961PixelData

Tabela 4. Interpretacja wybranych elementów danych DICOM.

Pierwszy przykład zawiera informację o długość nagłówka pliku – Tag (0002,0000) identyfikuje informację nazwaną MetaElementGroupLength. Dane zakodowane są w postaci czterobajtowej liczby całkowitej bez znaku unsigned-long, co wynika z Value Representation równego UL (UL – unsigned-long). Drugi przykład zawiera informację o współrzędnych obrazu ((0020,0032) = ImagePositionPatient), dane zakodowane są w postaci łańcucha znaków (VR=DC, decimal string) o długości 26 znaków i zawierają trzy zmienne liczbowe, rozdzielone znakiem „\”. Ostatni z przykładowych Data Element zawiera dane w postaci 4096 pikseli obrazu ((7fe0,0010) = PixelData), zakodowane w postaci ciągu 16bitowych słów (VR = OW, other word string).

Z przytoczonych przykładów wynika, że koncepcja elementu danych jest bardzo elastyczna i umożliwia zapisanie bardzo różnych danych: od pojedynczych liczb, przez łańcuchy znakowe po dane o znacznej objętości.

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

13. Logiczna budowa pliku

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

Dane zawarte w każdym pliku DICOM podzielone są na dwie części:

Obydwie części zawierają dane w postaci strumienia informacji (ang. Data Set), który jest uporządkowanym strumieniem elementów danych (ang. Data Element). Strumień elementów danych można zaobserwować w przytoczonym powyżej binarnym fragmencie pliku DICOM.

Informacje o pliku (Dicom-Meta-Information-Header) są wymagane dla każdego pliku DICOM. Dokument PS 3.10 ściśle określa zawartość tej części pliku. Część zawierająca dane (Dicom-Data-Set) przechowuje informacje o jednym obiekcie typu Service-Obiect-Pair instance (SOP instance). Obiektem tym może być np.: pojedynczy przekrój CT, pojedyncza klatka wirtualnej bronchoskopii wygenerowana na aparacie CT lub opis zawartości nośnika, tak jak ma to miejsce w przypadku pliku DICOMDIR.

14. Analiza zawartości pliku DICOMDIR

<< Analiza zawartości pliku DICOMDIR | DICOM | >>

W przytoczonym zdekodowanym fragmencie pliku DICOMDIR, w części zawierającej dane, po czterech rekordach opisujących strukturę pliku, następuje sekwencja danych określająca strukturę danych na nośniku. Zaczyna się od elementu danych (0004,1220), opisującego DirectoryRecordSequence. Każda sekwencja danych zawiera zestawy danych nazywane Item, zaczynające się od elementu danych o identyfikatorze (ang. Data Element Tag) równym (fffe,e000), a kończone tzw. ItemDelimitationItem, elementem danych o identyfikatorze (fffe,e00d). W praktyce, element określający koniec zestawu danych (ItemDelimitationItem) nie występuje w plikach.

W prezentowanym przykładzie, pierwszy zestawy danych (ang. Item) przechowuje informacje o pacjencie. Zawartość poszczególnych zestawów danych definiuje element danych nazywany DirectoryRecordType o identyfikatorze (0004,1430). Poniżej, w tabeli 5 powtórnie przytoczono fragment opisujący pacjenta.


                                     Tabela 5. Zestaw elementów danych opisujący dane pacjenta. 
   (fffe,e000) na     "Directory Record" PATIENT #=9     #   138,  1  Item 
   #    offset= $384 
       (0004,1400) up     $0                             #      4, 1  OffsetOfTheNextDirectoryRecord 
       (0004,1410) US     65535                          #      2, 1  RecordInUseFlag 
       (0004,1420) up     $530                           #      4, 1  OffsetOfReferencedLowerLevelDirectoryEntity 
       (0004,1430) CS     [PATIENT]                      #      8, 1  DirectoryRecordType 
       (0008,0005) CS     [ISO_IR 100]                   #     10, 1  SpecificCharacterSet 
       (0010,0010) PN     [C*******^M*****]              #     16, 1  PatientsName 
       (0010,0020) LO     [1234/56/7890]                 #     12, 1  PatientID 
       (0010,0030) DA     [19010101]                     #      8, 1  PatientsBirthDate 
       (0010,0040) CS     [M]                            #      2, 1  PatientsSex 
  (fffe,e00d) na     "ItemDelimitationItem for re-encoding" #     0,  1 ItemDelimitationItem 

Zestaw danych (ang. Item) zawiera: informacje na temat hierarchii danych (elementy danych o numerze grupy 0004), sposób kodowania danych (SpecificCharacterSet - (0008,0005)) oraz dane o pacjencie (o numerze grupy 0010), takie jak: nazwisko pacjenta (0010,0010), identyfikator pacjenta (0010,0020), data urodzenia (0010,0030), płeć (0010,0040). Ze względu na ochronę danych osobowych, rzeczywiste informacje zostały w tabeli zastąpione wartościami przypadkowymi.

Kolejny zestaw danych opisuje badanie (ang. Study). Budowa zestawu jest podobna do informacji o pacjencie, tzn. najpierw występują informacje organizujące strukturę pliku (grupa numer 0004), standard kodowania znaków, a następnie właściwe informacje o badaniu, takie jak: data i godzina badania, opis badania, unikatowy kod UID (ang. Unique Identifier) oraz numer badania.

Trzeci zestaw danych opisuje serię danych (ang. Series). Również w tym przypadku występują informacje organizujące dane, a także opis konkretnej serii danych: data i czas, pochodzenie serii (modalność, dane CT), nazwa oraz adres instytucji wykonującej badanie, opis serii (w tym przypadku jest to wirtualna bronchoskopia wykonana na aparacie CT – SSD Collection, ang. Shaded Surface Display), unikatowy kod UID (ang. Unique Identifier) oraz numer serii.

Po opisie serii, następuje opis poszczególnych obrazów. W przytoczonym w tabeli 3 fragmencie pliku DICOMDIR znajdują się dwa zestawy danych opisujące pliki z danymi graficznymi – elementy danych DirectoryRecordType o identyfikatorach (0004,1430) zawierają wpis Image. Pierwszy opisuje wirtualną bronchoskopię, drugi pojedynczy przekrój tomografii komputerowej. Typ przechowywanych danych określany jest w elemencie danych ImageType o identyfikatorze (0008,0008). Jedną z ważniejszych informacji zawartych w zestawie danych jest ścieżka dostępu oraz nazwa pliku z danymi. Informacja ta zawarta jest w elemencie danych ReferencedFileID, o identyfikatorze (0004,1500), w postaci łańcucha znaków (VR = CS, code string). W obydwu przytoczonych w tabeli 3 przykładowych zestawach danych, występują informacje o dacie i czasie powstania obrazów, unikatowych numerach UID, numerze obrazu w serii (InstanceNumber) oraz rozdzielczości (ilość wierszy i kolumn obrazów).

W zestawie danych opisującym obraz z tomografii komputerowej występują dwie sekwencje danych:

Dodatkowo, zapisane są informacje o przestrzennych współrzędnych obrazu (ImagePositionPatient), orientacji obrazu w przestrzeni (ImageOrientationPatient) oraz odległości między pikselami (PixelSpacing).

Powyżej przedstawiono i omówiono przykład zawartości pliku DICOMDIR. Plik zawiera strumień informacji w postaci ciągu elementów danych, które z kolei tworzą sekwencje i zestawy danych (ang. Item), opisujące informacje medyczne (np. pacjenta, badanie czy obraz CT). Zestawy danych tworzą hierarchię odzwierciedlającą zależności między danymi. Podobną budowę ma każdy plik standardu DICOM.

14.0.0.1. Witek Szczypka?14 September 2017, 14:57

Witam wszystkie potrzebne informacje na początek są na stronie Dziękuję -Link do gdcm nie działa

14.0.0.2. jfklda?11 February 2019, 17:19

dcmtk jest nadal rozwijany, proszę o korektę.

Retrieved from http://home.agh.edu.pl/~socha/pmwiki/pmwiki.php/DICOM/Caly
Data ostatniej modyfikacji: 11.02.2019, 17:19