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
Here’s how they are displayed in Slicer…
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]
For reference (i left the option to enable/disable that patch)
With patch
Without patch
Thanks @issakomi,
Thanks.
Your data will display fine because the patch is removed.
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.
No, we can not turn it dynamically on/off in GDCM. S. DCMTK’s dcmdjpeg 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.
Was this a very recent gdcm fix removal?
Do Slicer fixes make it into SlicerQREADS builds?
Thanks.
The change was merged into ITK master 10 months ago. Somewhere above is a link to GDCM’s initial commit (Sourceforge).
Checked recent stable 4.11 release, there is the bug. Preview 4.13 is fine.
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. This inefficient variant of JPEG is unique to medical imaging and is defined in itu-t81. 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. 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).
Thanks @issakomi and @Chris_Rorden. I verified that Slicer 4.13 displays the images correctly. The timing on 4.13 availability perfect! 
I don’t have sample data set which works with the patch and doesn’t work without.
Here is such file, from GDCM collection.
E.g. to test dcmdjpeg +w6.
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.
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.
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?
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
Oh ok. Thanks so much JC 