Otwórz jeden rzeczywisty obraz CT i odczytaj jego kontrakt

Dotychczasowe wyjaśnienia tworzyły model myślowy. Ten przypadek nadaje mu konkretną postać, prowadząc jeden publiczny obiekt CT przez kontrole poprzedzające jakiekolwiek zaufanie do jego tablicy. Celem nie jest zapamiętanie tagów ani uznanie przeglądarki za źródło prawdy. Chodzi o wyrobienie odruchu czytania metadanych przed zaufaniem pikselom.

Odczytaj jeden rzeczywisty obiekt, nie ufając mu bezkrytycznie

Nazwany przypadek pochodzi ze zbioru Zhao B, Schwartz LH, Kris MG i Riely GJ, Coffee-break lung CT collection with scan images reconstructed at multiple imaging parameters (Version 3) [Dataset], The Cancer Imaging Archive, identyfikowanego przez stabilny DOI. Publiczny rekord potwierdza wykonywanie powtórnych badań CT tego samego dnia oraz dostępność danych CT, danych SEG i konturów zmian. Wskazuje, że dane obrazowe Version 3 są dostępne na licencji CC BY 4.0. Rekord TCIA pozostaje źródłem rozstrzygającym o aktualnych warunkach dostępu; warunki te nie są tutaj wnioskowane. Do tego repozytorium nie dodaje się danych pacjentów, a przypadek nie zależy od dostępu do pliku prywatnego ani lokalnego dla projektu.

Mapa nauki TRACE-CT dokumentuje ścieżkę implementacyjną, ale nie jest warunkiem wstępnym dla czytelnika. Tę samą metodę odczytywania kontraktu można zastosować do jednoplikowego obrazu DICOM CT pozyskanego z publicznej serii TCIA zgodnie z warunkami jej źródła.

Krok 1 studium przypadku: odczytaj obiekt jako kontrakt

Zacznij od odczytania obiektu jako łańcucha, a nie listy pól. Ustal jego SOP Class i Modality, a następnie umieść go w hierarchii za pomocą PatientID, StudyInstanceUID i SeriesInstanceUID. SOPInstanceUID identyfikuje konkretny obiekt źródłowy. Jest to część kontroli dotycząca tożsamości, a nie wniosek o równoważności klinicznej. Wersjonowany przykład inspekcji dla pydicom 3.0.2 znajduje się w materiale towarzyszącym do 3D Slicer; stabilna interpretacja przedstawiona tutaj nie zależy od konkretnego wydruku API. Odpowiadającą jej ścieżkę do zdekodowanej tablicy dokumentuje oficjalny przewodnik pydicom po danych pikselowych.

PixelRepresentation określa, czy zapisane PixelData jest ze znakiem, czy bez znaku (0 oznacza bez znaku, a 1 ze znakiem), czyli opisuje część pułapki wartości zapisanej dotyczącą typu danych. BitsAllocated, Rows i Columns opisują reprezentację tablicy, natomiast RescaleSlope i RescaleIntercept określają przekształcenie, które trzeba uwzględnić przed interpretacją wartości jako HU. Jeśli 0 + intercept daje wynik bliski wartości odniesienia dla powietrza, jest to sygnał wiarygodności kodowania: przewiduje wynik dla zapisanego zera, ale nie dowodzi, że zapisane zero jest zaobserwowaną próbką powietrza, ani nie waliduje minimum obrazu. Atrybuty przeskalowania CT definiuje moduł DICOM CT Image.

Pozostałe pola przygotowują kontrole przestrzenne i rekonstrukcyjne. PixelSpacing, ImagePositionPatient i ImageOrientationPatient opisują położenie przekroju oraz jego osie w płaszczyźnie; SliceThickness oznacza nominalną grubość przekroju, natomiast SpacingBetweenSlices, jeśli występuje, opisuje odległość między środkami. ConvolutionKernel pomaga rozpoznać kontekst rekonstrukcji. Pola te należy interpretować zgodnie ze specyfikacją właściwą dla danego obiektu; brak pola nie jest semantycznym zerem. Odpowiednie atrybuty przestrzenne definiuje moduł DICOM Image Plane. Role UID źródłowej Series i obiektu źródłowego rozwija podrozdział o identyfikatorach.

Krok 2 studium przypadku: zdekoduj zapisane piksele

Wersjonowany przykład pydicom w materiale towarzyszącym do 3D Slicer dekoduje zapisane próbki za pomocą pixel_array i stosuje liniowe przeskalowanie lub Modality LUT danego obiektu przy użyciu oficjalnej operacji apply_rescale. Manuskrypt zachowuje stabilne znaczenie tej operacji, natomiast dokładny przykład API pozostaje datowany wersją pydicom 3.0.2.

Jeśli obecne jest powietrze poza ciałem, sprawdź reprezentatywny obszar lub rozkład wartości i porównaj go z wartością odniesienia dla powietrza bliską −1000 HU, uwzględniając padding, artefakty i zakodowane przekształcenie. Znany obszar wody można porównać z wartością odniesienia 0 HU. Nie traktuj globalnego minimum jako wymaganego pomiaru powietrza i nie wnioskuj z wiarygodnego zakresu intensywności, że kompletny kontrakt obiektu jest prawidłowy. Wyjaśnienie wartości zapisanej pokazuje, dlaczego błędne przekształcenie może mimo to dać wiarygodnie wyglądającą tablicę.

Ta kontrola nadaje konkretną postać rozróżnieniu między kontraktem a danymi właściwymi: tablica zawiera zakodowaną intensywność, a znaczenie fizyczne zależy od RescaleSlope i RescaleIntercept. Wynik dotyczy wyłącznie warstwy intensywności. Nie mówi jeszcze nic o tym, czy obiekt należy do zamierzonej Series, czy ma właściwą kolejność przestrzenną ani czy jest klinicznie wymienny z inną rekonstrukcją.

Krok 3 studium przypadku: porównaj sąsiednie położenia

Po ustaleniu skali intensywności sprawdź dwa sąsiednie przekroje z tej samej Series. Chodzi o zobaczenie, które metadane przekształcają odrębne obiekty w kandydujący stos. Dla spójnie zorientowanych, równoległych przekrojów oblicz wektor normalny przekroju jako iloczyn wektorowy cosinusów kierunkowych wiersza i kolumny, zgodnie z rozwinięciem w rozdziale o geometrii, a następnie sprawdź, czy wartości ImagePositionPatient różnią się wyłącznie wzdłuż tego wektora. Przesunięcia w płaszczyźnie lub różnice orientacji są sygnałami do zbadania: zwaliduj zamierzoną reprezentację, zamiast na ich podstawie uznawać, że nie można utworzyć użytecznego wolumenu.

Porównaj również ImageOrientationPatient i PixelSpacing między tymi dwoma przekrojami. Od regularnej Series oczekuje się zachowania odpowiedniej geometrii w płaszczyźnie, dlatego różnica jest powodem do zbadania, a nie do cichego połączenia tablic. Na koniec zmierz wzdłuż wektora normalnego odległość między środkami położeń przekrojów i porównaj ją z SpacingBetweenSlices, jeśli ten atrybut występuje. Interpretuj SliceThickness jako nominalną grubość, a nie drugą nazwę zmierzonego odstępu między środkami. To ważna zmiana perspektywy: odstęp mierzy się z geometrii, a następnie porównuje z metadanymi, zamiast ufać mu tylko dlatego, że istnieje tag. Jest to zalążek podrozdziału o porządkowaniu przekrojów w rozdziale o geometrii.

Krok 4 studium przypadku: użyj przeglądarki jako uzupełniającego źródła informacji

Ostatnim czytelnikiem jest przeglądarka. Wczytaj zamierzoną publiczną Series do przeglądarki takiej jak 3D Slicer i porównaj wyświetlany obraz z interpretacją metadanych. Sprawdź wyświetlane odstępy i początek, przejrzyj wyświetlane metadane DICOM oraz zastosuj odpowiednie ustawienie wyświetlania okna płucnego. Oficjalna dokumentacja DICOM w Slicerze i dokumentacja Volumes opisują zależny od wersji interfejs i zachowanie wyświetlania; te szczegóły należą do materiału towarzyszącego, a nie do ponadczasowego przypadku.

Przeglądarka jest uzupełniającym źródłem informacji, a nie wyrocznią. Jeśli Slicer i odczyt pydicom są niezgodne, nie ufaj bezkrytycznie żadnemu z nich. Znajdź tag lub etap przetwarzania odpowiedzialny za różnicę; niezgodność jest tropem diagnostycznym, a nie powodem, by wybrać obraz wyglądający bardziej przekonująco. Materiał towarzyszący dla programu 3D Slicer przedstawia wizualną stronę zweryfikowanego materiału przypadku Witowskiego i jego niewielkiej procedury RIDER, nie czyniąc z ogólnego samouczka ani lokalnej ścieżki projektu części tego przypadku.

Krok 5 studium przypadku: przenieś pytanie o geometrię do rozdziału 4

Przypadek kończy się przeniesieniem pięciu reprezentatywnych pól do przyjętego materiału rozdziału 4 o geometrii, segmentacji i zmianie próbkowania, a nie potraktowaniem ich jako ostatecznego werdyktu: ImagePositionPatient, ImageOrientationPatient, PixelSpacing, SliceThickness i FrameOfReferenceUID. Razem nazywają ważne informacje przestrzenne, które trzeba sprawdzić, zanim tę Series będzie można uznać za bezpieczny, regularny wolumen 3D, ale lista nie jest wyczerpująca. Znaczenie mają również wymiary, spójność między instancjami, unikalne położenia, zmierzony odstęp między środkami i właściwa relacja przestrzenna; szczegółowe decyzje dotyczące konstruowania i zmiany próbkowania pozostają poza tym przypadkiem.

Użyteczny odruch jest już wyraźny: odczytaj kontrakt, a dopiero potem zaufaj pikselom. RescaleSlope/Intercept, PixelRepresentation, UID i tagi geometrii poprzedzają każdą operację na tablicy. Przeliczenie na HU oraz reprezentatywne kontrole powietrza lub wody mogą ujawnić błędną skalę, ale wiarygodny zakres intensywności nie jest kompletną walidacją. Zmierzona kolejność i odstępy wynikają z położeń sąsiednich przekrojów wzdłuż wektora normalnego; nazwy plików i InstanceNumber są tylko pomocniczymi diagnostycznymi kontrolami spójności, nigdy zamiennikami geometrii. pydicom i Slicer są dwoma czytnikami tego samego kontraktu; gdy ich wyniki się różnią, należy szukać różniącego się tagu lub etapu przetwarzania.

Zwartą tabelę tagów, materiały o VR i składni transferowej, listę klas SOP oraz pełny katalog trybów awarii zawiera materiał referencyjny o CT i DICOM. Kontrole kontraktu w tym przypadku pozostawiają celowo otwarte pytanie: w jaki sposób te atrybuty przestrzenne ustanawiają geometrię w przestrzeni pacjenta i kiedy maska lub wolumen wymagają zmiany próbkowania? Jest to temat rozdziału 4 — geometria fizyczna, segmentacja i zmiana próbkowania.