Przejdź do głównej zawartości

Dlaczego piksel CT nie jest automatycznie wartością HU

Rozdział 3 przedstawia DICOM jako kontrakt, dzięki któremu zapisane wartości uzyskują z metadanych znaczenie fizyczne, a obiekty obrazowe są identyfikowane i organizowane w badania, serie i instancje. Tożsamość obiektu pozostaje odrębna od tożsamości przestrzennej: ten rozdział opisuje kontrakt określający opakowanie danych i tożsamość, łączący omówienie modalności, sygnału i kontrastu w rozdziale 2 z przedstawieniem geometrii fizycznej w rozdziale 4. Rozdział kończy się odczytaniem jednej rzeczywistej akwizycji jako kompletnego kontraktu. Zaczyna się od najmniejszej postaci tego problemu: dlaczego zapisana wartość taka jak 37 nie jest automatycznie pomiarem CT.

Przekrój CT może zawierać zapisaną liczbę całkowitą 37. Jeśli kod potraktuje tę liczbę jako pomiar tkanki, może zgłosić +37 HU. W kodowaniu użytym w poniższym przykładzie ta sama zapisana wartość jest dekodowana jako −987 HU. Różnica nie jest szczegółem wyświetlania: tablica pikseli stanowi dane właściwe, natomiast metadane dostarczają kontrakt, który nadaje tym danym interpretację fizyczną.

Zakodowana wartość: 37 nie jest 37

Jednostki Hounsfielda tworzą zdefiniowaną skalę, ale obiekt DICOM nie musi zapisywać wartości tej skali bezpośrednio w każdym pikselu. W przypadku klasycznego CT Image Storage moduł CT Image określa BitsAllocated = 16, natomiast PixelRepresentation deklaruje, czy zapisane próbki są bez znaku, czy ze znakiem. Jeden z dopuszczalnych przykładów wykorzystuje próbki bez znaku z przesunięciem: zapisana wartość 0 może wtedy reprezentować wartość bliską −1000 HU bez potrzeby użycia bitu znaku. Odzyskanie wielkości CT wymaga zastosowania odwzorowania liniowego opisanego przez metadane danego obiektu:

HU = stored_pixel × RescaleSlope + RescaleIntercept

Dla zadeklarowanych ustawień przykładu RescaleSlope = 1 i RescaleIntercept = −1024:

stored pixel = 37
HU = 37 × 1 + (−1024) = −987

Liczba całkowita 37 nie oznacza zatem +37 HU; w tym odwzorowaniu odpowiada wartości zbliżonej do powietrza. Jeśli kod zastosuje próg zapisany w HU bezpośrednio do wartości zapisanej, granica przesunie się do innej wartości fizycznej, przez co woksele leżące w jej pobliżu mogą zostać przypisane do niewłaściwej klasy. To ograniczony błąd, który należy mieć na uwadze; jego zasięg zależy od progu, przekształcenia i obrazu.

Precyzyjnie o dwóch tagach

  • RescaleSlope (0028,1053) — czynnik multiplikatywny przeskalowania liniowego. Odczytuj go z każdego obiektu; nie zakładaj, że wynosi 1.
  • RescaleIntercept (0028,1052) — przesunięcie addytywne w tym przeskalowaniu. Odczytuj je z każdego obiektu zamiast zakładać konkretną wartość.

W rozpatrywanym tu liniowym przeskalowaniu CT atrybuty te opisują alternatywę przeskalowania liniowego w module Modality LUT; same nie są tablicą LUT. W rozszerzonym obiekcie wieloklatkowym równoważne przekształcenie może znajdować się w grupie funkcjonalnej Pixel Value Transformation jako część Enhanced CT Image IOD. Dla ograniczonego przykładu klasycznego CT, który nie jest obrazem lokalizacyjnym ani obrazem wieloenergetycznym, wynikiem tego przekształcenia są HU. Praktyczny wniosek brzmi: odwzorowanie należy do kontraktu DICOM przenoszonego obok bajtów obrazu; sama tablica nie mówi, jakiej skali liczbowej używa.

Dlaczego kontrakt ma znaczenie

Błąd jest niebezpieczny, ponieważ nie wywołuje podejrzanych objawów liczbowych. Tablica pozostaje prawidłową tablicą i może wyglądać całkowicie wiarygodnie, mimo że kod interpretuje jedną skalę jako inną. Gdy dalsza operacja oczekuje HU, ale otrzymuje wartości zapisane, błąd przenosi się do operacji, których progi lub statystyki zdefiniowano w tej skali fizycznej:

  • operacje okna/poziomu albo progowania używają innej skali liczbowej;
  • dyskretyzacja intensywności na potrzeby cech tekstury przypisuje do przedziałów niewłaściwe poziomy szarości;
  • ograniczenie HU, takie jak przykładowe [-1000, +400], wybiera niewłaściwe wartości zapisane;
  • w zadeklarowanym przypadku o nachyleniu 1 i wyrazie wolnym −1024 zgłoszone „średnie osłabienie promieniowania w guzie” różni się dokładnie o 1024 przed jakimkolwiek dalszym przetwarzaniem. To obliczenie nie uogólnia się na inne nachylenie ani inny wyraz wolny.

Błąd pozostaje niewidoczny, ponieważ tablica wygląda poprawnie: jest prawidłowym obrazem, tylko przesuniętym lub przeskalowanym. Przykład odnoszący się do konkretnego projektu znajduje się w mapie nauki TRACE-CT, gdzie load_ct_volume_explicit() stosuje volume[k] = pixel × slope + intercept podczas budowania wolumenu. Dalsze etapy otrzymują dzięki temu wolumen po dekodowaniu, a nie zapisane piksele. Implementacja jest przykładem egzekwowania kontraktu podczas wczytywania, nie zastępuje jednak odczytania kontraktu z każdego obiektu DICOM.

Kontrola dekodowania

Wersjonowany, wykonywalny przykład dla pydicom 3.0.2 znajduje się w materiale towarzyszącym do 3D Slicer, obok oficjalnego przewodnika pydicom po danych pikselowych i dokumentacji apply_rescale. Stabilna logika przykładu polega na użyciu zdekodowanej przez bibliotekę tablicy pixel_array, następnie zastosowaniu liniowego przeskalowania lub Modality LUT danego obiektu i sprawdzeniu otrzymanych wartości. Wynik stanowi kontrolę wiarygodności, a nie dowód poprawności kompletnego kontraktu obrazu.

Jeśli obecne jest powietrze poza ciałem, sprawdź reprezentatywny obszar lub rozkład wartości w tym miejscu i porównaj go z wartością odniesienia dla powietrza bliską −1000 HU, uwzględniając padding, artefakty oraz zakodowane przekształcenie. Obszar, o którym wiadomo, że zawiera wodę, można porównać z wartością odniesienia 0 HU. Żadna z tych kontroli nie czyni globalnego hu.min() wymaganym pomiarem powietrza. Obliczenie 0 + intercept jest przydatne wyłącznie jako kontrola wiarygodności kodowania: przewiduje, na co zostanie odwzorowane zapisane zero, ale nie dowodzi, że zapisane zero pobrano z powietrza, ani nie waliduje minimum obrazu.

W zadeklarowanym przykładzie o nachyleniu 1 i wyrazie wolnym −1024 zapisane zero zostaje arytmetycznie odwzorowane na −1024. Nie jest to uniwersalny przedział wartości dla powietrza ani reguła dotycząca skanerów lub rekonstrukcji, a globalne minimum bliskie zeru samo w sobie nie dowodzi pominięcia przeskalowania; o minimum mogą decydować padding, artefakty, anatomia lub obcięcie wartości.

Kontrola ujawnia zasadnicze rozróżnienie: tablica zawiera zakodowane wartości intensywności, natomiast interpretacja fizyczna znajduje się w metadanych. Odwzorowanie przez nachylenie i wyraz wolny jest pomostem między nimi. Ta sama idea kontraktu i danych właściwych powraca później w geometrii, gdzie metadane nadają tablicy położenie w przestrzeni pacjenta; ten podrozdział nie musi powtarzać tamtego wyprowadzenia przestrzennego. Wystarczy rozpoznać, że poprawne dekodowanie intensywności jest jednym z elementów większego kontraktu obrazu.

Wartości ze znakiem i bez znaku: druga część pułapki

RescaleIntercept spełnia swoje zadanie dopiero po zdekodowaniu wzorca bitowego piksela z użyciem właściwego typu danych. Tę interpretację opisują dwa kolejne tagi:

  • PixelRepresentation (0028,0103) — 0 = bez znaku, 1 = ze znakiem.
  • BitsAllocated (0028,0100) — 16 dla klasycznego CT Image Storage.

Pola te są tylko częścią kontraktu dekodowania danych surowych. Bezpośredni odczyt PixelData wymaga także uwzględnienia właściwej Transfer Syntax i kolejności bajtów oraz BitsAllocated, BitsStored, HighBit i PixelRepresentation. Warunkowy przykład z próbkami uint16 bez znaku i RescaleIntercept = −1024 zapisuje wartość zbliżoną do powietrza jako małą dodatnią liczbę całkowitą; inny warunkowy przykład z próbkami int16 ze znakiem i wyrazem wolnym 0 może już kodować wartości ujemne. Są to przykłady, a nie założenia dotyczące każdego obiektu. Preferowaną ścieżką jest zdekodowana przez pydicom tablica pixel_array, która respektuje zadeklarowaną reprezentację; jeśli tablica uint16 zostanie ponownie zinterpretowana jako int16, wartości poniżej 32768 pozostaną bez zmian, natomiast wartości z górnej połowy zakresu zawiną się o 65536, a nie przesuną się jednolicie. Odpowiednie pola pikseli obrazu definiują reguły kodowania pikseli DICOM.

Dekodowanie intensywności jest więc pierwszą kontrolą kontraktu, a nie całym procesem identyfikowania obrazu. Przed połączeniem przekrojów lub porównaniem obiektu pochodnego proces musi wiedzieć, który obiekt DICOM i która seria dostarczyły wartości oraz które instancje należą do siebie. Następny podrozdział przechodzi od liczbowych danych właściwych do tego kontekstu organizacyjnego: hierarchii Study, Series i Instance oraz identyfikatorów, które odróżniają pozornie podobne obiekty. Odrębny kontrakt przestrzenny, obejmujący tagi geometrii przypisujące tablicę do przestrzeni pacjenta, rozwija rozdział o geometrii.

© 2026 Adrian Tkacz · BioMedical-IT
Oryginalne teksty i ilustracje są udostępniane na licencji Creative Commons Uznanie autorstwa–Użycie niekomercyjne 4.0 Międzynarodowe (CC BY-NC 4.0), o ile nie zaznaczono inaczej. Przy ponownym wykorzystaniu proszę podać Adrian Tkacz / BioMedical-IT jako autora i zamieścić odnośnik do oryginalnego źródła. Materiały osób trzecich zachowują własne prawa i warunki licencyjne.