Does dcmj2pnm transform for CT modality?

[nikkoara]

I need a bit of clarification on the modality transformation, as performed by dcmj2pnm. My understanding was that the modality transformation, be it linear or LUT-driven, happens by default during the extraction of the image with dcmj2pnm (unlike VOI transformations). This made me expect that the resulting image file will contain HU values, offset by 32768. In other words, HU values in the image, say, in the range of [-10,1000] will be offset to [32758,33768].

I am trying to reconcile the above with my findings (and the miriad of partial and/or vague explanations found in the wild).

E.g., the image:

Code: Select all

$ dcmj2pnm -v -im -o downloads/CT-MONO2-16-ankle
I: reading DICOM file: downloads/CT-MONO2-16-ankle
I: preparing pixel data
I: dumping image parameters
I:   filename            : downloads/CT-MONO2-16-ankle
I:   transfer syntax     : Little Endian Implicit
I:   SOP class           : SecondaryCaptureImageStorage
I:   SOP instance UID    : 1.2.840.113619.2.1.2411.1031152382.365.1.736169244
I:   columns x rows      : 512 x 512
I:   bits per sample     : 17
I:   color model         : MONOCHROME2
I:   pixel aspect ratio  : 1.00
I:   number of frames    : 1 (1 processed)
I:   VOI LUT function    : <default>
I:   VOI windows in file : 1
I:   - <no explanation>
I:   VOI LUTs in file    : 0
I:   presentation shape  : <default>
I:   overlays in file    : 0
I:   maximum pixel value : 3056
I:   minimum pixel value : -992
I: cleaning up memory
$

Please note the min and max values, they are the actual HU values, computed by f(x)=mx+b, with slope m=1 and intercept b=-1024. The stored pixel values in the DICOM file range between 32 and 4080, though.

After extracting the PNG:

Code: Select all

$ dcmj2pnm downloads/CT-MONO2-16-ankle t.png

I end up with an image file, t.png:

Code: Select all

$ identify -verbose t.png
  Image: t.png
  ...
  Colorspace: Gray
  Depth: 16-bit
  Channel depth:
    gray: 16-bit
  Channel statistics:
    Pixels: 262144
    Gray:
      min: 32800 (0.500496)
      max: 36848 (0.562264)
  ...

It seems to me that it wasn't the HU values of each pixel but the stored DICOM values for the pixels that have been offset by 32768. Indeed, the minimum PNG pixel value is 32800=32768+32, where 32 was the minimum DICOM stored pixel value.

So, is the encoding of pixel values in monochrome 16-bit PNGs a mere offset of the stored values for each pixel in the original DICOM file? Again, my understading was that a modality transformation will always take place upon extraction, and for CT that means transforming to HU values before adding the offset.

Thanks!

[J. Riesmeier]

Unless the modality transform is disabled (using option -M or --no-modality), the Modality LUT Transformation is applied to the stored pixels according to the DICOM Grayscale Transformation Pipeline. Because the tool dcmjpnm (and the underlying DicomImage class) is meant for getting a rendered version of an image, the PNG file in your example does not contain HU values but the rendered output (based on these HU values). Even if you don't specify a VOI Transformation (like window center and width) explicitly, the output is mapped linearly to an unsigned value range.

The output of signed pixel values (e.g. in PNG format) is not supported by this tool, if this was the question.

[nikkoara]

Thanks for the reply! I was not concerned with PNG signed pixel values.

Follow-up question: if the resulting PNG file contains rendered output based on the HU values (which are in the range [-992,3056] for this exam) shouldn't the PNG pixel values be in the range [32768-992, 32768+3056], i.e., [31776,35824], instead of the range [32800,36848]? The latter is a simple offset by 32768 of the original DICOM stored values which themselves are in the range [32,4080].

Unless the modality transform is disabled (using option -M or --no-modality), the Modality LUT Transformation is applied to the stored pixels according to the DICOM Grayscale Transformation Pipeline. Because the tool dcmjpnm (and the underlying DicomImage class) is meant for getting a rendered version of an image, the PNG file in your example does not contain HU values but the rendered output (based on these HU values). Even if you don't specify a VOI Transformation (like window center and width) explicitly, the output is mapped linearly to an unsigned value range.

The output of signed pixel values (e.g. in PNG format) is not supported by this tool, if this was the question.

[J. Riesmeier]

The answer to your question it not that easy, but easier to understand if you enable the trace log output and render the output image:

Code: Select all

T: Input length: 524288 bytes, Pixel count: 262144 (262144), In: 16 bits, Out: 16 bits (signed)
[...]
T: intermediate pixel data - absmin: -33792, absmax: 31743

So, the input data (stored pixel data) is 16 bit signed in the range of -32768 to 32767. After applying the Modality LUT transformation, the possible value range is -33792 to 31742 (see above). For the output image, this value range is linearly mapped to the range of 0 to 65535 (16 bit unsigned), i.e. -992 becomes 32800 and 3056 becomes 36848.