Seeking advice on Segmented Color Palettes in Presentation States

[David Clunie]

Hi folks

Because most people find the text describing Segmented Color Palettes:
  https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.9.2.html

initially introduced by the Ultrasound folks in Supplement 5:

  https://www.dclunie.com/dicom-status/status.html#Supplement5

relatively incomprehensible, as well as rarely (if ever) utilized, we have become somewhat prejudiced against it, and when we remember to do so, we have excluded it from use in certain more recent IODs:

  https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.9.html

Specifically, we say:

"Required if segmented data is used in an Image IOD or Color Palette IOD; shall not be present in a Presentation State IOD or Segmentation IOD"

However, it transpires that the degenerate form of a Segmented Color Palette is actually pretty useful and compact for communicating a simple single linear ramp, e.g., from [0,255] can be encoded as:

  0x0000,0x0001,0x0000,0x0001,0x00ff,0x00ff

i.e., 12 bytes per 8-bit input and output channel rather than 256.

This tempts some creative people to use it.

So, my questions for you are:

1. Should we consider relaxing the prohibition on using Segmented Color Palettes in Presentation State or Segmentation IODs (which would be a potentially breaking change for viewers that don't support it, though they may not support it for images anyway)?

2. If so, should we constrain it to allowing only a simple form (single linear ramp) or leave it so that recipients may encounter something (much) more complex?

3. If so, should we narrow the list of specific IODs (e.g., which Presentation State IOD, such as Advanced Blending) we should relax this prohibition for, and leave others to retain the prohibition (e.g., perhaps Pseudo-Color Softcopy Presentation State), depending on our estimate of the size if the installed base affected?

4. Or, at the other extreme, should we expunge this monstrosity from the standard entirely by retiring it, or even more aggressively, prohibiting it even for images?

5. To be even more provocative, does such a parametrized form of a linear ramp or a more complex equation have value for grayscale LUTs as well? Or RWVMs? I.e., should we design a new and better form for certain use cases? E.g., we could represent gamma changes to a true color image in a parameterized form rather than quantized in a LUT (independent of the ICC profile tone curve or matrix transforms). See also:

  https://onlinelibrary.wiley.com/doi/abs/10.1002/9780470688106.ch28

Before I submit any CPs on this, I was wondering what other people thought.

David

PS. Last time someone asked to support allowing Segmented Color LUT was for the (standalone) Color Palette IOD; see

  https://www.dclunie.com/dicom-status/status.html#CP1687

PPS. I am hard pressed to find a DICOM Conformance Statement that describes any product actually using the Segmented Color Palette mechanism, but I did find this Fuji/Hitachi/Aloka F37 statement that mentions it as possibly present:

  https://asset.fujifilm.com/master/global/files/2022-05/50a57de7fbb92f925b960f64b00c0c08/f37_ver4_0_11-dcs.pdf

PPPS. There is at least one example of an Ultrasound image that contains a Segmented Color Palette kicking around on the Internet from Mathieu's test collection, "gdcm-US-ALOKA-16.dcm", but it does not use a compact form such as I described:

  https://github.com/malaterre/gdcmdata/blob/master/gdcm-US-ALOKA-16.dcm

but see also:

  https://groups.google.com/g/comp.protocols.dicom/c/ImJqq8SsQwY

[Mathieu Malaterre]

Hi David,

We have received very few of those in the past. One of the latest is (circa 2021):

(0008,0070) LO [Hitachi Aloka Medical,Ltd.]             #  26, 1 Manufacturer
(0008,1090) LO [SSD-ALPHA7]                             #  10, 1 ManufacturerModelName
(0018,1020) LO [01-6.2.0\Prism.L_DICOMLib Ver08.00.00[20110420]] #  48, 2 SoftwareVersions

Someone from Hitachi / Fujifilm should be able to confirm whether this code path is still in use today.

Your question seems mostly opinion-based, so you have my vote. It makes sense to compress the LUT(s) in those special cases.

However, here is how I read your original post:

[...]
DICOM only allows _native_ PALETTE COLOR. DICOM will not allow you to include _encapsulated_ PALETTE COLOR because of various legacy reasons (JP2 with PCLR & CMAP, or SPIFF with JPEG-LS / Mapping Tables). A Part 18 implementation must take special care to handle those LUTs so that a client can retrieve LUT data as Bulkdata instead of it being stored as binary64 directly in the JSON metadata, saving network bandwidth.
[...]

Here is a quick experiment from my Debian stable system using the ALOKA file you referenced: gdcm-US-ALOKA-16.dcm

```bash

% du -sb gdcm-US-ALOKA-16.dcm          
873140 gdcm-US-ALOKA-16.dcm

$ gdcmconv --apply-lut gdcm-US-ALOKA-16.dcm rgb16.dcm
$ gdcmimg rgb16.dcm rgb16.ppm
$ cjxl -d 0 --modular_palette_colors=128 rgb16.ppm rgb16.jxl

$ du -sb rgb16.jxl
56804 rgb16.jxl

```

I have not done my homework, so I cannot tell why lossless compression is so impressive on that image, but the conclusion is: yes, there are ways to be creative with LUT compression.

Cheers,

[Jörg Riesmeier]

Hi David,

Personally, I would declare the entire concept of segmented palettes as “retired” (if it were up to me). Very few companies seem to have implemented it. The benefit of saving a few bytes per image does not, in my view, justify the increased effort required for implementation [*]. If the one or two ultrasound companies insist on it, segmented palettes should be limited to ultrasound images. I have also seen segmented palettes used for WSI objects (see the discussion on the WG-26 mailing list), which, in my view, makes absolutely no sense when you consider how huge WSI objects are and how little you actually save.

[*] That is also why I never implemented it for the DCMTK image rendering pipeline (see modules dcmimgle/dcmimage).

My experience with the DICOM standard is this: features that are easy to implement get implemented. Complicated features or alternative approaches are often not implemented at all, or only by a very small number of vendors/developers.

Regards,

Jörg