[Insight-users] Dicom read-write

Mathieu Malaterre mathieu.malaterre at gmail.com
Mon Jun 4 11:18:30 EDT 2007


Rashindra,

  This lead me to my next question: why use ITK ?
  GDCM, the DICOM library underneath ITK comes with a small app (See
Examples/ directory): a DICOM Anonymizer.

 http://cvs.creatis.insa-lyon.fr/viewcvs/viewcvs.cgi/gdcm/Example/Anonymize.cxx?view=markup

Feel free to send questions to dcmlib:

 http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

> I think that explicitly changing the value of
> an entry should not affect the values of other entries as a side effect.

This seems like a perfectly valid argument. Unfortunately in your
case, here is the sequence of actions that are happening:

1. Your incoming DICOM file is stored in 12bits
2. ITK does not support 12bits data
3. Thus GDCM pass the Pixel Data buffer to ITK as a 16bits (valid!)
4. Ok... now the Pixel Data is expressed as 16 bits
5. When saving the Pixel Data, GDCM is given a 16 bits buffer by ITK
6. Obviously GDCM will declare the Pixel Data as 16 bits (no way to
know if the PixelData was rescaled or not (*))

as for the Group Length 0002,0000. I'd suggest you read the DICOM Part
10 (file format description). You'll see that DICOM v3 specify that
Meta Group (0002) needs a group length...

  I would need a cristal ball to figure out why Media Storage SOP
Instance UID was changed. This one should actually be the same as SOP
Instance UID (0008,0018), so I don't see why it would change...


HTH
-Mathieu
(*) Technically you could edit (hexedit) your DICOM file to change the
value from 16 to 12 if you are sure your scalar range did not change
(still 12 bits Pixel Data).

On 6/4/07, Rashindra Manniesing <r.manniesing at erasmusmc.nl> wrote:
>
> HI Mathieu,
>
> Thank you for your response.
>
> Actually I wanted to write a simple (2D) dicom anonymizer, leaving all
> non-private tags intact.  I think that explicitly changing the value of
> an entry should not affect the values of other entries as a side effect.
>
> Rashindra.
>
>
>
>
> Mathieu Malaterre wrote:
> > Rashindra,
> >
> > Thanks for describing your issue in details. Unfortunately you are
> > not telling us why you are trying so hard to keep the DICOM meta data
> > intact.
> >  itk::GDCMImageIO will write a valid DICOM file, from your
> > itk::Image. I have been adding some functionalities to create somewhat
> > invalid DICOM file (when using KeepOriginalUIDOn). Those functions
> > should only be used if you really know what you are doing.
> >
> >  We could help you, if you would tell us what you were trying to do.
> >
> > Thanks,
> > -Mathieu
> >
> > On 6/2/07, Rashindra Manniesing <r.manniesing at erasmusmc.nl> wrote:
> >>
> >> HI,
> >>
> >>
> >> I have a question concerning  'DicomImageReadChangeHeadeWrite.cxx' (ITK
> >> 3.2, Example/IO directory).
> >>
> >> The program reads a dicom slice, change header information and writes a
> >> dicom slice. I have commented out the code responsible for changing
> >> header information, thus the header in/out should be exactly the same
> >> (should it?). This is not the case.
> >>
> >> Is that a bug or feature? And how to resolve this? Using the member
> >> function KeepOriginalUIDOn() of GDCMImageIO preserves some of the header
> >> information, but still other entries are changed, including eg
> >>
> >> (0002|0000) Group Length
> >> (0002|0003) Media Storage SOP Instance UID
> >> (0028|0101) Bits Stored = 12
> >>
> >> and many others. How to prevent this from happening?
> >>
> >> Rashindra Manniesing
> >>
> >>
> >>
> >> _______________________________________________
> >> Insight-users mailing list
> >> Insight-users at itk.org
> >> http://www.itk.org/mailman/listinfo/insight-users
> >>
> >
> >
>
> --
>   Rashindra Manniesing, PhD
>   Biomedical Imaging Group Rotterdam (BIGR)
>   Erasmus MC - University Medical Center Rotterdam
>   Departments of Medical Informatics and Radiology
>
>   phone  +31 10 40 88001
>   fax    +31 10 40 87050
>   email  r.manniesing at erasmusmc.nl
>
>   room   Ee2342
>   postal P.O. Box 1738, 3000 DR Rotterdam
>   visit  Dr. Molewaterplein 40/50, 3015 GE Rotterdam
>


-- 
Mathieu


More information about the Insight-users mailing list