After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599075 - Issue on DICOM files
Issue on DICOM files
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Plugins
2.8.4
Other All
: Low minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-10-20 16:58 UTC by Orazio Gambino
Modified: 2018-05-24 12:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Comparison of opening DICOM image opned in "DICOM viewer software" and in "GIMP" (86.34 KB, image/jpeg)
2010-04-15 06:05 UTC, Kashif
Details
DICOM Image files (Please unzip) (241.94 KB, application/x-compressed-tar)
2010-04-15 10:26 UTC, Kashif
Details
DICOM image displayed wrongly with histogram in GIMP 2.6.7 (Windows/XP build) (244.58 KB, image/jpeg)
2010-05-28 08:44 UTC, Ulrich.Windl
Details
DICOM image displayed correctly in GIMP 2.2.10 (Linux/SLED 10 SP2, Novell build) (930.35 KB, image/jpeg)
2010-05-28 08:45 UTC, Ulrich.Windl
Details
DICOM image displayed correctly in ImageMagick 6.2.5 (Linux/SLED 10 SP2, Novell build) (165.86 KB, image/jpeg)
2010-05-28 08:47 UTC, Ulrich.Windl
Details
Screen shot (834.45 KB, image/png)
2010-06-27 18:22 UTC, Jim Conyngham
Details
DICOM and PNG Image (2.84 MB, application/zip)
2016-02-20 13:47 UTC, Stefan Huschenbeck
Details

Description Orazio Gambino 2009-10-20 16:58:58 UTC
GIMP loads a DICOM file, but the image doesn't appear in the right way. Probably there is a problem on little/big endian decoding. Indeed, a figure is visualized, but the gray levels are wrong. The foreground is noisy while the background is dark. I suggest an option on the Open wizard to set the little/big endian decoding when the Dicom file type is selected.

Thank you.
Comment 1 Sven Neumann 2009-10-20 20:44:19 UTC
There is noone maintaining the DICOM plug-in. So if there's a problem with it that you'd like to see fixed, then please attach a patch to this bug-report.
Comment 2 Kashif 2010-04-15 06:05:54 UTC
Created attachment 158780 [details]
Comparison of opening DICOM image opned in "DICOM viewer software" and in "GIMP"
Comment 3 Kashif 2010-04-15 06:12:02 UTC
I have tried installing GIMP on windows XP SP2 and windows 7. Both shows the same error as mentioned by Orazio Gambino earlier in this thread. Please find the image already posted before this comment.
Comment 4 Nils Philippsen 2010-04-15 08:42:54 UTC
Somebody should probably attach an actual DICOM file which shows this problem to this bug report. Without something to reproduce the issue, there's no way anybody could sensibly work on this, even if they wanted to.
Comment 5 Kashif 2010-04-15 10:26:56 UTC
Created attachment 158803 [details]
DICOM Image files (Please unzip)

Here are the DICOM Files attached. Please unzip to find 4 DICOM Files.
Comment 6 Ulrich.Windl 2010-05-28 08:41:35 UTC
I also noticed this problem, and to my surprise, an older version of GIMP (2.2.10) and ImageMagick (6.2.5) can read the image without problem. GIMP 2.6.7 is no longer able to do so. Inspecting the histogram I found that the bad image only has four colours, while the original is a 16 bit grayscale image (with a wide range of gray levels). I cannot attach the original DICOM image for privacy reasons (a tool to overwrite any personal, equipment and institution data would be helpful here), but I can attach screenshots for old GIMP, current GIMP and ImageMagick. I feel the problem can be fixed.
Comment 7 Ulrich.Windl 2010-05-28 08:44:03 UTC
Created attachment 162178 [details]
DICOM image displayed wrongly with histogram in GIMP 2.6.7 (Windows/XP build)
Comment 8 Ulrich.Windl 2010-05-28 08:45:32 UTC
Created attachment 162179 [details]
DICOM image displayed correctly in GIMP 2.2.10 (Linux/SLED 10 SP2, Novell build)
Comment 9 Ulrich.Windl 2010-05-28 08:47:11 UTC
Created attachment 162180 [details]
DICOM image displayed correctly in ImageMagick 6.2.5 (Linux/SLED 10 SP2, Novell build)
Comment 10 Jim Conyngham 2010-06-27 18:22:03 UTC
Created attachment 164764 [details]
Screen shot

I've just run into the same bug.

The image data in the file is 12-bit grey scale, with each pixel stored in two bytes (16 bits) in little-endian format.  I.e.,
bits/pixel = 16
bits stored = 12
high bit = 11
not signed.

The image loaded into GIMP is has clearly been byte-swapped.   Most of the image is noise, and both the histogram tool and the color-cube tool show that the loaded image has only 16 values, all of which are multiples of 16.   

Looking at the code for file-dicom.c, it's not obvious exactly where the error is, but logically should be in the part where it decides whether the image is little-endian or big endian.

I'm unable to attach the image because it's too large.
I'm attaching a screen shot.
Comment 11 Jim Conyngham 2010-06-27 18:59:35 UTC
(In reply to comment #10)
> I've just run into the same bug.

P.S.  Forgot to add that I'm using the latest GIMP 2.6.9, on Windows XP.
Comment 12 Michael Schumacher 2013-06-03 20:00:42 UTC
This still happens in 2.8.4
Comment 13 Stefan Huschenbeck 2016-02-20 13:47:03 UTC
Created attachment 321725 [details]
DICOM and PNG Image

As the problem persits in 2.8.16 I'd like to contribute some files.
IM000001.dcm is a DICOM-Image
IM000001.jpg is how it is displayed in GIMP
Note that the annotations added to the picture are displayed correctly.
IM000001.png is how the file is displayed be irfanview 4.41 with DICOM Plug-in.
Comment 14 Stefan Huschenbeck 2016-02-20 13:47:45 UTC
Comment on attachment 321725 [details]
DICOM and PNG Image

As the problem persits in 2.8.16 I'd like to contribute some files.
IM000001.dcm is a DICOM-Image
IM000001.jpg is how it is displayed in GIMP
Note that the annotations added to the picture are displayed correctly.
IM000001.png is how the file is displayed be irfanview 4.41 with DICOM Plug-in.
Comment 15 Michael Natterer 2016-02-21 12:24:36 UTC
Are you familiar with the file format and can try to fix this, preferably
on git master? None of us knows anything about dicom afaik.
Comment 16 Stefan Huschenbeck 2016-02-21 17:33:50 UTC
No sorry. I'm not even familiar with git. Reading the older comments I thought part of the problem is that there is no suitable file. 
I forgot to mention that my GIMP is running on Win7 64-bit.
Comment 17 Jonathan Tait 2016-02-21 21:07:29 UTC
We appear to have lost an endian-swap, way back in GIMP-2.5.0, specifically in Muks' patches in bug 524017.

Up to GIMP-2.4.7, procedure dicom_loader() contained this code:

  guint pix_gl = g_ntohs (GUINT16_SWAP_LE_BE (buf16[pix_idx]));
   :
  buf16[pix_idx] = pix_gl;

	
In GIMP-2.5.0 onwards:

  buf16[pix_idx] = g_htons (buf16[pix_idx]) >> shift;

In other words, the GUINT16_SWAP_LE_BE() has been lost and the g_ntohs() replaced by g_htons() ..which is NOT the same thing at all.

-----------------------------
To put this into context:

- DICOM files store image data in little-endian format by default, but may also use big-endian, in which case appropriate tags should be included; however, the original author (Dov Grobgeld) found that that (apparently) did not work reliably because there were many rogue files which did not include recognisable tags, so he implemented an alogithm to *guess* the endianness of image data based on the premise that the least-significant bytes of all the image data will generally have a higher *maximum* value than all the most-significant bytes. ref: https://git.gnome.org/browse/gimp/tree/plug-ins/common/file-dicom.c#n764

- after the guessing algorithm is executed, the in-buffer image data *should* be in little-endian format, regardless of the format in the DICOM file and regardless of the endianness of the host CPU;

- in procedure dicom_loader(), the GUINT16_SWAP_LE_BE() would then convert the data to big-endian (aka. "network" format in glib parlance) regardless of CPU, and the g_ntohs() would then convert that result (if necessary) to suit the host CPU, ready for normalization/scaling and storage in the GIMP image buffer.

--------------------------------
Re-instating the original swap (but retaining Muks' other modifications), I find that the plugin will then load Stefan Huschenbeck's IM000001.dcm (which contains 10-bit image data) correctly (although I notice that the IM000001.png created by irfanview appears to be inverted!).

However, the plugin still does not load Kashif's images correctly, nor some of the images provided in other bug reports. Kashif's images appear to contain 10-bit data, but the tags say it is full 16-bit (so the image appears very dark when loaded in GIMP). The original plug-in used auto-normalization of image data, but again that was removed in Muks' patches.

I will investigate further when I have the time.
Comment 18 Ulrich.Windl 2016-02-22 07:44:08 UTC
(In reply to Michael Natterer from comment #15)
> (...) None of us knows anything about dicom afaik.

I found this as a starting point: http://dicom.nema.org/standard.html
Comment 19 Michael Natterer 2016-02-22 11:32:56 UTC
Yeah, what I meant is not that none of us is able to dig into it and fix it :)
Rather, why not ask the reporter if they can upload a patch...

Seems Jonathan is on the right track.
Comment 20 Stefan Huschenbeck 2016-02-23 12:03:41 UTC
(In reply to Jonathan Tait from comment #17)

...
> contains 10-bit image data) correctly (although I notice that the
> IM000001.png created by irfanview appears to be inverted!).
...

Hi Jonathan. Analogue film material that was exposed to x-rays appears black after develop process. Screen areas covered by material absorbing x-rays remain white.
This simple effect is used with dental x-ray films where there is little space. To lower x-ray dose (and to protect the patient's tissue) the film is placed in a cassette where it is covered by a screen. This screen is emitting visible light when hit by x-rays.
Visible light "blackens" the film much stronger than pure x-rays.
So "historically seen" irfanview displays the correct image.
The DICOM-viewer enclosed to the CD where the image is from shows it in the same way. 
- If this bug isn't fixed, it hopefully at least will improve readers dental care and less brains will be exposed to x-rays ;-)
Comment 21 Jonathan Tait 2016-02-23 14:08:48 UTC
> - If this bug isn't fixed, it hopefully at least will improve readers dental
> care and less brains will be exposed to x-rays ;-)

Haha.
Yes it is a bug in the GIMP plugin - the image uses DICOM PhotometricInterpretation "MONOCHROME1" which is indeed inverted. The GIMP plugin was simply ignoring that tag completely.

I have solved that problem (by detecting the tag and inverting the pixel data when the image is loaded) but am still struggling with Kashif's image and various others which use signed pixel data.
Comment 22 Ulrich.Windl 2016-08-04 07:58:29 UTC
In GIMP 2.8.18 (Windows) I'm still having problem with a recent DICOM series: It seems as if the order of grayscale bits is wrong when interpreting, or the number of bits used is incorrect. Fortunately exiftool knows about DICOM, and here are some data it decoded (hopefully this will give a hint what might be wrong):
Start Of Item                   : 
Samples Per Pixel               : 1
Photometric Interpretation      : MONOCHROME2
Planar Configuration            : 0
Rows                            : 128
Columns                         : 128
Bits Allocated                  : 16
Bits Stored                     : 12
High Bit                        : 11
Pixel Representation            : Unsigned
End Of Items                    : 
End Of Sequence                 :
Comment 23 Michael Schumacher 2016-08-04 08:08:16 UTC
It isn't surprising that nothing has changed:

The last change to actual DICOM-code in the plug-in was in 2013:
https://git.gnome.org/browse/gimp/log/plug-ins/common/file-dicom.c
Comment 24 GNOME Infrastructure Team 2018-05-24 12:42:05 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/313.