Enhanced CT Image Storage object rendering does not take into account Modality LUT encoded in PixelValueTransformationSequence

[PalminX]

When rendering an Enhanced CT Image Storage object with PixelIntercept and PixelSlope encoded in a PixelValueTransformationSequence within a SharedFunctionalGroupsSequence, the Modality LUT is not applied correctly.

Steps to reproduce the behavior

• Download sample Multiframe CT images from ftp://medical.nema.org/medical/dicom/Multiframe/CT/

• From the example images, use CT0070 and render it like this:

  ImageManager.SetImplementation(WinFormsImageManager.Instance);
  var img = new DicomImage("CT0070");
  img.WindowCenter = 40;
  img.WindowWidth = 400;
  img.RenderImage().As<Bitmap>().Save("output.png");

Expected behavior

The rendered PNG image looks like this:

Actual behavior

The rendered PNG image looks like this:

Additional Information

The actual encoding of the RescaleIntercept/RescaleSlope in this multiframe instance looks like this:

    (5200,9229) SQ (Sequence with undefined length #=1)     # u/l, 1 SharedFunctionalGroupsSequence
      (fffe,e000) na (Item with undefined length #=6)         # u/l, 1 Item
    […]
        (0028,9145) SQ (Sequence with undefined length #=1)     # u/l, 1 PixelValueTransformationSequence
          (fffe,e000) na (Item with undefined length #=3)         # u/l, 1 Item
            (0028,1052) DS [-1024.00]                               #   8, 1 RescaleIntercept
            (0028,1053) DS [1.00000]                                #   8, 1 RescaleSlope
            (0028,1054) LO [HU]                                     #   2, 1 RescaleType
          (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
        (fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
      (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
    (fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem

Regular (single-frame) CT instances render correctly when RescaleIntercept and RescaleSlope are defined on the top level

    (0028,1052) DS [-1024.00]                               #   8, 1 RescaleIntercept
    (0028,1053) DS [1.00000]                                #   8, 1 RescaleSlope

fo-dicom version and OS/platform

fo-dicom 4.0.2, Windows 10 64 Bit, .NET Core

[PalminX]

Attaching the example instance from ftp://medical.nema.org/medical/dicom/Multiframe/CT/

CT0070.zip

[gofal]

Isn't the initial windowing (level, width) also stored in perframe functional sequence? This then should also be applied. Important enhancement for EnhancedCT, EnhancedMR and BreastTomosynthesisObjects.

[PalminX]

That's true... In my example, I set the WindowCenter/WindowWidth explicitely, but of course any LUT stored a PerFrameFunctionalGroupsSequence should be used if applicable

[gofal]

@mrbean-bremen @amoerie I've got a question about github. This branch is about to be ready and it required some rebuild within DicomImage. To avoid regression, I have built some RenderingTest on my machine. There is a directory containing a dicomfile and a Bitmap with both the same filename. The bitmaps are rendered image taken from other applications or from sample websites. The rendertest just takes all pair of files, renders and does a pixel-per-pixel comparison.

I'd like to add this test to github, but there Gigabyte of data. Do you know of any solution, to upload static data to github, so that a test running github action could consume those? Of course this would not be part of the unittest, but a manually to trigger test.

[amoerie]

There's actually GitHub LFS but I'm not sure what this costs... Will get back to you.

[mrbean-bremen]

Do you know of any solution, to upload static data to github

Not really. What was done in pydicom for large test data was creating a separate repository with the data that is downloaded into a cache on demand, but that uses no special GitHub functionality.

[gofal]

no, the single files itself are only some megabytes. but the files all sum up to gigabytes.

[gofal]

of course i can continue running the tests locally on my machine, but I would love the idea, that the various files to be tested can grow by the community.

[mrbean-bremen]

A relatively simple solution could be to add a separate data repository, download it once in the CI tests to some cache directory and cache it using for example the latest commit ID of the test data repo for the current branch. Then it has to be downloaded again only if new data has been committed. The tests then have to be pointed to that test data path for getting the data. The logic that checks if the test data is current could also be used for local tests, though that might be a bit more tricky, as we cannot use the GitHub Action functionality. The downside is that we would always have to download all the test data, but on the other hand if we would need them anyway if we want to run the tests. We could add some option to skip tests that use this data, or more sophisticated options, but for a first working version this is probably not needed.

[amoerie]

no, the single files itself are only some megabytes. but the files all sum up to gigabytes.

Are they encoded with JPEG 2000? That typically makes a big difference vs Little Endian Explicit.

[amoerie]

Do you know of any solution, to upload static data to github

Not really. What was done in pydicom for large test data was creating a separate repository with the data that is downloaded into a cache on demand, but that uses no special GitHub functionality.

This isn't such a crazy idea!