[Insight-users] Fwd: Help on DICOM image reading bug
Xuejun
sd2usa at gmail.com
Tue Sep 12 23:41:50 EDT 2006
Hi, Mathieu;
Since I don't hear from you after I posted the problem of DICOM reading
again, I am contacting with you regarding this problem and please let me
know if you have a double check.
Best regards,
Sam
-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
Sent: Wednesday, September 06, 2006 5:57 PM
To: Xuejun; insight insight
Subject: Re: [Insight-users] Fwd: Help on DICOM image reading bug
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
>
>> >
>
>>
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20060912/42763a32/attachment-0001.htm
More information about the Insight-users
mailing list