# Slicer Issues with Displaying Certain DICOM Images

**URL:** <https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262>\
**Category:** Development\
**Tags:** dicom\
**Created:** [April 23, 2021, 12:27am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262 "2021-04-23T00:27:30Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![spycolyf](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@spycolyf](https://discourse.slicer.org/u/spycolyf)\
**Post date:** [April 23, 2021, 12:27am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/1 "2021-04-23T00:27:31Z")

</div>

@pieper @jcfr

Hello Slicer team, I’m wondering why Slicer has a problem displaying these images while other viewers display them correctly. Here are the images in my DropBox. They are test images, no worries…: [Dropbox - TestImageVolume - Simplify your life](https://www.dropbox.com/sh/hopthrktsxk096b/AACMArdeMeFo5aXxxfMkLN4Wa?dl=0)

Here’s how they are displayed in Slicer…  
 ![SlicerBadDisplay](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/5/a/5a8398bdf9c2315fb79eac5b00d83232de1847ba.png)

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 23, 2021, 2:07am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/2 "2021-04-23T02:07:35Z")

</div>

This is related to _predictor6_ bug in JPEG. In GDCM was a patch to workaround it, it is actually removed (some data set may work better without it, some with, AFAIK), so there is no problem with your data set in current Slicer version (tested with nightly).  
S. [Grassroots DICOM / Gdcm / Commit [371402]](https://sourceforge.net/p/gdcm/gdcm/ci/37140257a286f109270bc415e207fc16d6d428c3/)

 ![Screenshot at 2021-04-23 04-07-03](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/2/5/256d84d3e5596160c2deee13629f408df2a90554.jpeg)

For reference (i left the option to enable/disable that patch)  
With patch  
 ![20210423-041133](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/a/6/a66615ee72b2fcd8f421b5b8ffd668c0063e88a4.png)

Without patch  
 ![20210423-041127](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/2/a/2abc30d0d44ddb3ff34302e119f6586c41992bed.png)

---

<div class="post-metadata">

**Author:** ![spycolyf](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@spycolyf](https://discourse.slicer.org/u/spycolyf)\
**Post date:** [April 23, 2021, 3:30pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/3 "2021-04-23T15:30:55Z")

</div>

Thanks @issakomi,

1. Are you saying that in the most recent version of Slicer, my data will display fine because the patch is applied?
2. You stated “(some data set may work better without it, some with, AFAIK).” What is AFAIK and what types of images have it?
3. Can we dynamically turn the patch on or off? Perhaps we should add a button to our user interface to turn it on or off.

Thanks.

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 23, 2021, 4:14pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/4 "2021-04-23T16:14:20Z")

</div>

> [@spycolyf](#):
>
> Are you saying that in the most recent version of Slicer, my data will display fine because the patch is applied?

Your data will display fine because the patch is removed.

> [@spycolyf](#):
>
> You stated “(some data set may work better without it, some with, AFAIK).” What is AFAIK and what types of images have it?

I don’t have sample data set which works with the patch and doesn’t work without. The patch was ~10 years in GDCM, probably such data set exists.

> [@spycolyf](#):
>
> Can we dynamically turn the patch on or off? Perhaps we should add a button to our user interface to turn it on or off.

No, we can not turn it dynamically on/off in GDCM. S. DCMTK’s [dcmdjpeg](https://support.dcmtk.org/docs/dcmdjpeg.html) and option `+w6`

```
  +w6 --workaround-pred6
          enable workaround for JPEG lossless images
          with overflow in predictor 6

  # DICOM images with 16 bits/pixel have been observed "in the wild"
  # that are compressed with lossless JPEG and need special handling
  # because the encoder produced an 16-bit integer overflow in predictor
  # 6, which needs to be compensated (reproduced) during decompression.
  # This flag enables a correct decompression of such faulty images, but
  # at the same time will cause an incorrect decompression of correctly
  # compressed images. Use with care.

```

---

<div class="post-metadata">

**Author:** ![spycolyf](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@spycolyf](https://discourse.slicer.org/u/spycolyf)\
**Post date:** [April 24, 2021, 12:01am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/5 "2021-04-24T00:01:43Z")

</div>

@issakomi @jcfr

Was this a very recent gdcm fix removal?

Do Slicer fixes make it into SlicerQREADS builds?

Thanks.

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 24, 2021, 12:35am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/6 "2021-04-24T00:35:15Z")

</div>

The change was [merged](https://github.com/InsightSoftwareConsortium/ITK/commit/f2955fabd0a1e8b91f9d49f8c99be9b978dd4028) into ITK _master_ 10 months ago. Somewhere above is a link to GDCM’s initial commit (Sourceforge).

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 24, 2021, 12:44am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/7 "2021-04-24T00:44:30Z")

</div>

Checked recent stable 4.11 release, there is the bug. Preview 4.13 is fine.

---

<div class="post-metadata">

**Author:** ![Chris\_Rorden](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chris_rorden/32/4073_2.png) [@Chris\_Rorden](https://discourse.slicer.org/u/Chris_Rorden)\
**Post date:** [April 24, 2021, 11:55am UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/8 "2021-04-24T11:55:33Z")

</div>

As a historical note, once upon a time there was a popular DICOM tool named `Osiris` (I believe the modern `OsiriX` is an homage to this tool) that would save DICOM images using the compressed lossless JPEG transfer syntax [1.2. 840.10008.1.2.4.70](https://www.dicomlibrary.com/dicom/transfer-syntax/). This inefficient variant of JPEG is unique to medical imaging and is defined in [itu-t81](https://www.w3.org/Graphics/JPEG/itu-t81.pdf). Unfortunately, Osiris did not implement the format correctly, specifically Codec H.1.2.2: `No extra bits are appended after SSSS = 16 is encoded.` However, Osiris’ implementation was internally consistent (it could read and write its own images) and overwhelmingly popular. Since the format was so rare outside of medical imaging, many tools adopted the Osiris interpretation of the standard. Unfortunately, as far as I am aware there is no way to detect if this standard is implemented as described in the standard or as used by Osiris. For this reason, libraries must assume one method or another.

I would _strongly_ discourage any DICOM users from using transfer syntax [1.2. 840.10008.1.2.4.70](https://www.dicomlibrary.com/dicom/transfer-syntax/). Due to the Osiris bug, it is handled differently by different tools. It is also very inefficient, and one will typically get much better compression using conventional file based compression (e.g. zstd, zip, gz). Since DICOM only requires DICOM compatible tools to handled uncompressed data, using compressed transfer syntaxes can cause unintended consequences. If you must use a compressed transfer syntax I would suggest the more efficient, modern and consistently implemented 1.2.840.10008.1.2.4.80 (JPEG-LS) or 1.2.840.10008.1.2.4.90 (JPEG 2000 Image Compression, Lossless Only).

---

<div class="post-metadata">

**Author:** ![spycolyf](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@spycolyf](https://discourse.slicer.org/u/spycolyf)\
**Post date:** [April 24, 2021, 2:52pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/9 "2021-04-24T14:52:20Z")

</div>

Thanks @issakomi and @Chris_Rorden. I verified that Slicer 4.13 displays the images correctly. The timing on 4.13 availability perfect! 🙂

![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/3/c/3c36b99a922ee519d73af53f0c1ee8d06d95463f.png)

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 25, 2021, 5:00pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/10 "2021-04-25T17:00:05Z")

</div>

> I don’t have sample data set which works with the patch and doesn’t work without.

Here is such [file](https://drive.google.com/file/d/1QO646Zl4tKvMeaOy1EuTFsxiDHIurMhi/view?usp=sharing), from GDCM collection.

E.g. to test `dcmdjpeg +w6`.

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 25, 2021, 10:54pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/11 "2021-04-25T22:54:31Z")

</div>

> [@Chris\_Rorden](#):
>
> As a historical note, once upon a time there was

May be this [file](https://drive.google.com/file/d/1NUOlq7Ut57qiG8MTb3quXYlUajYnvGuj/view?usp=sharing) is an example of the bug you mentioned, `dcmdjpeg +wc` to fix.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [April 26, 2021, 3:15pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/12 "2021-04-26T15:15:13Z")

</div>

> [@issakomi](#):
>
> I don’t have sample data set which works with the patch and doesn’t work without.

I’m curious, shouldn’t this be a user option rather than a patch? Maybe it’s not a common enough problem any more to be worth working on.

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [April 26, 2021, 3:31pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/13 "2021-04-26T15:31:03Z")

</div>

In DCMTK _jpeg\_decompress\_struct_ is extended, there is

```
  /* Options that enable or disable various workarounds */
  unsigned int workaround_options;

```

and

```
/* constants for workaround_options in struct jpeg_decompress_struct */
#define WORKAROUND_PREDICTOR6OVERFLOW 1
#define WORKAROUND_BUGGY_CORNELL_16BIT_JPEG_ENCODER 2

```

In GDCM it is not available, predictor patch is simply removed.

I don’t think the issue appears often. For “Predictor” bug - both, working and not-working files are 16 bit lossless JPEG _signed short_, AFAIK. Probably not very important, i hope, not 100% sure. Can be fixed with `dcmdjpeg` is someone has many files, IMHO.

---

<div class="post-metadata">

**Author:** ![spycolyf](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@spycolyf](https://discourse.slicer.org/u/spycolyf)\
**Post date:** [April 27, 2021, 10:17pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/14 "2021-04-27T22:17:03Z")

</div>

Do you recommend that we use the latest nightly build (Slicer 4.13) if we have this problem? Or would issues with other image types occur?

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [April 27, 2021, 10:21pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/15 "2021-04-27T22:21:59Z")

</div>

For reference, this has been fixed integrating with the latest version of Slicer. See [BUG: Update Slicer to include fix related to GDCM predictor6 bug in JPEG by jcfr · Pull Request #93 · KitwareMedical/SlicerQReads · GitHub](https://github.com/KitwareMedical/SlicerQReads/pull/93)

---

<div class="post-metadata">

**Author:** ![spycolyf](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@spycolyf](https://discourse.slicer.org/u/spycolyf)\
**Post date:** [April 27, 2021, 10:24pm UTC](https://discourse.slicer.org/t/slicer-issues-with-displaying-certain-dicom-images/17262/16 "2021-04-27T22:24:34Z")

</div>

Oh ok. Thanks so much JC 🙂