[Insight-users] Fwd: Help on DICOM image reading bug
Mathieu Malaterre
mathieu.malaterre at kitware.com
Wed Sep 6 17:57:29 EDT 2006
Sam,
Could you please post directly to the ITK mailing list instead of
personal email. Otherwise your question does not get archived.
Anyway here is what I tried:
./bin/DicomImageReadWrite Slice_38.dcm out.dcm foo.vtk bla.vtk
If you then open out.dcm you'll see that the DICOM header was corrected
and Bits Allocated is now 16bits as it should be. Your image contains a
very bizarre scalar range. That's why you need to be very careful with
your choice of window/level. For instance if you open the rewritten file
with VolView, you'll see an histogram of the image on the left panel.
This is trivial to adjust the Window/Level from this interface to
quickly look at this image.
HTH
Mathieu
Xuejun wrote:
> Hi, Mathieu;
>
>
>
> I tried it but unfortunately the problem is still there.
>
>
>
> After updating the source files in the directories of
> /Insight/Utilities/gdcm/src and /Insight/code/IO through CVS, I updated
> accordingly these two libraries.
>
>
>
> Actually when first testing the modified version, something was wrong
> with the file itkgdcamImageIO.cxx, the same as indicated the first time
> I found, unrecognized type “14U”. I had to modify this file again and
> regenerated itkIO library. After rebuilding the project, the display
> result is the same, the upper part of the DICOM image is lost.
>
>
>
> Did you test it the revised one on the DICOM image I sent to you? If the
> display is normal with you, would you please tell me how to fix this
> problem?
>
>
>
> I have to speed up the project and fix this initial problem as quickly
> as possible. Your kind help is greatly appreciated.
>
>
>
> Best regards,
>
> Sam
>
>
>
>
>
>
>
> -----Original Message-----
> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> Sent: Tuesday, September 05, 2006 6:09 PM
> To: Xuejun
> Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
>
>
>
> Yes this was fixed in ITK CVS. I would recommend updating ITK and trying
>
> it out. It will be available in ITK 3.0
>
>
>
> Mathieu
>
>
>
> Xuejun wrote:
>
>> Hi, Mathieu;
>
>>
>
>> Would you please let me know if the bug was resolved or not and how to use
>
>> the file?
>
>>
>
>> Regards,
>
>> Sam
>
>>
>
>>
>
>> -----Original Message-----
>
>> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>
>> Sent: Thursday, August 31, 2006 1:21 PM
>
>> To: Xuejun
>
>> Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
>
>>
>
>> Oh I remember now. I did an early patch and attached it to the bug
>
>> tracker, but it is incorrect. I need to revise it. Give me until tomorrow.
>
>>
>
>> Mathieu
>
>>
>
>> Xuejun wrote:
>
>> > http://public.kitware.com/Bug/bug.php?op=show&bugid=3668
>
>> >
>
>> >
>
>> > -----Original Message-----
>
>> > From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>
>> > Sent: Wednesday, August 30, 2006 5:23 PM
>
>> > To: Xuejun
>
>> > Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
>
>> >
>
>> > Sam,
>
>> >
>
>> > if each pixel is indeed 2 bytes (==16bits), why does the
> header says
>
>> >
>
>> > 14bits for the Bits Allocated instead of directly 16bits ? I have been
>
>> > working on DICOM file for a long time, and I am convinced this is a bug
>
>> > in the library you are using. Before applying the patch (yes it's
>
>> > ready), I need to refer to the correct manufactor of the DICOM lib.
>
>> >
>
>> > For instance, the DICOM library is referring to the 'Signed Short
>
>> > Lossless Bug' from DicomObject:
>
>> >
>
>> > http://www.medicalconnections.co.uk/html/lossless_bug.html
>
>> >
>
>> > Why so, because we are patching the DICOM library to handle
> illegal
>
>> > DICOM file. Therefore we might not be able to handle other illegal DICOM
>
>> > file from different constructors that suffer from similar problems.
>
>> > Example maybe next time we found 14bits, it actually means 12 instead of
>
>> > 16 bits for you.
>
>> >
>
>> > Thanks for your time
>
>> > Mathieu
>
>> >
>
>> > Xuejun wrote:
>
>> >> I will contact with them regarding this issue, but I am not sure what
>
>> >> they will do.
>
>> >>
>
>> >>
>
>> >>
>
>> >> Actually for about one year I have been working on this kind of DICOM
>
>> >> image with our C++ code (not on ITK) on SUN workstations under Solaris
>
>> >> operating system. It works well in reading the image although the DICOM
>
>> >> image saved with the code cannot be recognized by IDL, while DICOMWorks
>
>> >> can. I encountered this DICOM reading problem through ITK on PC windows.
>
>> >>
>
>> >>
>
>> >>
>
>> >> I am not familiar with the specifications of DICOM. Based on my
>
>> >> observations, I think it should be the second one of your hypotheses,
>
>> >> because I checked the number of pixels is 2139111, with each pixel
>
>> >> taking 2 byte (unsigned short). Then the total number is 4278222, the
>
>> >> same as you found.
>
>> >>
>
>> >>
>
>> >>
>
>> >> I very appreciate you to resolve this as quickly as possible.
>
>> >>
>
>> >>
>
>> >>
>
>> >>
>
>> >>
>
>> >> Thanks
>
>> >>
>
>> >> Sam
>
>> >>
>
>> >>
>
>> >>
>
>> >> -----Original Message-----
>
>> >> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>
>> >> Sent: Tuesday, August 29, 2006 3:23 PM
>
>> >> To: Xuejun
>
>> >> Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
>
>> >>
>
>> >>
>
>> >>
>
>> >> Hi Sam,
>
>> >>
>
>> >>
>
>> >>
>
>> >> If you are in touch with those guys, could you please
>
>> >> forward them this:
>
>> >>
>
>> >> * DICOM spec is at: http://medical.nema.org
>
>> >>
>
>> >> * PixelData Length for this image is incorrect:
>
>> >>
>
>> >>
>
>> >>
>
>> >> Two hypothesis:
>
>> >>
>
>> >> 1. You use the pack bits approach in which case the PixelData length
>
>> > should:
>
>> >>
>
>> >>
>
>> >> Rows*Colums*(BitsAllocated/8)
>
>> >>
>
>> >>
>
>> >>
>
>> >> In your case:
>
>> >>
>
>> >>
>
>> >>
>
>> >> 1833*1167*(14/8) = 3743444.25 (need to round to next byte)
>
>> >>
>
>> >> whereas your image is: 4278222
>
>> >>
>
>> >>
>
>> >>
>
>> >> 2. Your image is indeed encoded on 16bits (no pack bits mechanism), then
>
>> >>
>
>> >> BitsAllocated is incorrectly set to 14, and should be set to 16.
>
>> >>
>
>> >>
>
>> >>
>
>> >>
>
>> >>
>
>> >> Mathieu
>
>> >>
>
>> >> Ps: feel free to CC me in the discussion.
>
>> >>
>
>> >>
>
>> >>
>
>> >> Xuejun wrote:
>
>> >>
>
>> >>> This DICOM comes from a new type of medical imaging system. So you
>
>> > please
>
>> >>> keep it as confidential.
>
>> >>> Thanks
>
>> >>> Sam
>
>> >>> -----Original Message-----
>
>> >>> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>
>> >>> Sent: Tuesday, August 29, 2006 1:46 PM
>
>> >>> To: Xuejun
>
>> >>> Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
>
>> >>> You are a very lucky person :) I tried with:
>
>> >>> - TomoVision: crash
>
>> >>> - dcmtk: incorrect result
>
>> >>> - eFilm: does not open file
>
>> >>> - osiris: does not recognize the file
>
>> >>> - tviewer: incorrect result
>
>> >>> Can you please tell me where this image is coming from ?
>
>> >>> Thank you
>
>> >>> Mathieu
>
>> >>> Xuejun wrote:
>
>> >>>> That is the software we are using to display the DICOM image. In
>
>> >> addition,
>
>> >>
>
>> >>>> IDL6.0 also works well to display such DICOM image.
>
>> >>>> Thanks
>
>> >>>> Sam
>
>> >>>> -----Original Message-----
>
>> >>>> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
>
>> >>>> Sent: Tuesday, August 29, 2006 1:01 PM
>
>> >>>> To: Xuejun
>
>> >>>> Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
>
>> >>>> Xuejun wrote:
>
>> >>>>> Hi, Mathieu;
>
>> >>>>> First of all, I very appreciate your efforts to resolve this reading
>
>> >> bug.
>
>> >>
>
>> >>>>> Because this DICOM image can be displayed normally using some
>
>> >> software, I
>
>> >>
>
>> >>>> am
>
>> >>>>> confused by the "illegal DICOM file".
>
>> >>>> I would be interested in those 'some software', I believe only
>
>> >>>> DicomWorks can read this image. Can you name a few other ?
>
>> >>>> Thanks
>
>> >>>> Mathieu
>
>> >
>
>>
>
>>
>
More information about the Insight-users
mailing list