[Insight-users] Rewriting Dicom header entries

Mathieu Malaterre mathieu.malaterre at gmail.com
Thu Oct 18 03:57:08 EDT 2007 

Hi Angela,

  You are correct whenever a bytes array is found in a DICOM tag, GDCM
will preserve it as is. It consider that the user knows what it is
doing, and is needed for some special cases.
  In your case however since you have control over your input, you could either:

1. Get the MetaData dictionary of your input DICOM (from the Reader)
and remove the 0008,0008 entry.

2. Simply disconnect the writer from the input reader so that you
could 'pretend' you are creating a DICOM file ex-nihilo. Which AFAIK
is indeed what you are doing. In which case you could control
*exactly* what to add in the header and what not.

  See ImageReadDicomSeriesWrite or the ItkSfotwareGuide#DICOM section

HTH
-Mathieu

On 10/17/07, Angela Wang <Angela.Y.Wang at hsc.utah.edu> wrote:
> Hello again,
>
> On closer inspection, using a hex editor, it looks like the trailing null
> (0x00) is not replaced with white space (0x20) by GCDM.
>
> For example tag 0008,0008 has the following hex output:
>
> (0008,0008)   CS      16       DERIVED/
> 08 00 08 00   43 53   10 00    44 45 52 49 56 45 44 5C
>
>
> PRIMARY
> 50 52 49 4D 41 52 59 00
>
> New entries come out alright if I pad to an even length. However, if it is
> an odd length 00 is added.
>
> Angela
>
> On 10/17/07 7:34 AM, "Jean-Pierre Roux" <jpr at creatis.insa-lyon.fr> wrote:
>
> > Angela Wang wrote:
> >> Here is a sample of the dicom images. The original dicom file is
> >> Medcon_Data.dcm.  Then I used ITK to change the headers for OLD.dcm and
> >> NEW.dcm.  All odd number of characters should have been padded to an even
> >> number with blanks.
> >>
> >> I am told that the ones with null termination in the OLD.dcm file are:
> >> (0008,0008) - image type
> >> (0010,0040) - patient's sex
> >> (0020,0020) - patient orientation
> >>
> > OK.
> > XMedCon padds *all* the odd length strings with Zero.
> >
> >> I believe/hope that the null character terminations are fixed in the NEW.dcm
> >> version.
> > They are.
> > GDCM (therefore, ITK)  replaces trailing zero in strings by a white space.
> >> Except that (0008, 0008) entry is not changed.
> > (0008, 0008) is forced to "DERIVED\PRIMARY", except if user says he
> > didn't modify the pixels of the original image.
> > Use gdcm::FileHelper::SetContentType(gdcm::UNMODIFIED_PIXELS_IMAGE)
> >
> > Current CVS version of GDCM forces the value *only* when it contains
> > "ORIGINAL"
> > Maybe in next ITK release ...
> >
> >> I don't know how to
> >> distinguish a "blank" from a "null character".
> >>
> > You can see that using your favorite hexadecimal editor
> > White Space = 0x20
> > Binary Zero = 0x00
> >
> > Jean-Pierre Roux
> >
> >> Thanks again,
> >> Angela
> >>
> >>
> >>
> >>
> >> On 10/16/07 10:46 AM, "Jean-Pierre Roux" <jpr at creatis.insa-lyon.fr> wrote:
> >>
> >>
> >>> Angela Wang wrote:
> >>>
> >>>> Hi Mathieu,
> >>>>
> >>>>
> >>>> On 10/16/07 2:05 AM, "Mathieu Malaterre" <mathieu.malaterre at gmail.com>
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>>   Correct me if I am wrong, but doesn't DICOM actually clearly specify
> >>>>> that for a derived image (*), you have to set Image Type (0008,0008)
> >>>>> to DERIVED\PRIMARY.
> >>>>>
> >>>>>
> >>>> That is good to know.
> >>>>
> >>>>
> >>>>
> >>>>>   The process is fairly simple, if you derive an image (ie. read a
> >>>>> DICOM) and then writes it, ITK-gdcm will actually do the correct job
> >>>>> of marking it derived and setting up the Reference SOP Instance UID
> >>>>> for you. Otherwise you need to create an image from scratch, or
> >>>>> somehow disconnect from the source. But I'd be interested what is your
> >>>>> test case.
> >>>>>
> >>>>>
> >>>> I am using a processing program that converts images from DICOM to ECAT 6.
> >>>> Then I convert the processed images from ECAT 6 back into DICOM, using
> >>>> XMedcon. During that process, all of the original header entries are pretty
> >>>> much lost, so I am using ITK to rewrite information back into the DICOM
> >>>> header entries. The (0008,0008) is filled in by one of those programs and
> >>>> has a null character termination,
> >>>>
> >>> Dicom norm says that a field cannot have an odd length (even length is
> >>> mandatory)
> >>> The fields have to be padded either with blank space or with binary zero.
> >>>
> >>> We thought that GDCM (used by ITK) makes the right padding (dicom3tools
> >>> doesn't disagree with our padding)
> >>> Could you send one of your generated images,so we can check if anything
> >>> looks wrong.
> >>> (maybe XMedcon produces images that are not 100% kosher ?)
> >>> Jean-Pierre Roux
> >>> gdcm team
> >>>
> >>>>  which is not acceptable to the upload
> >>>> site. That is the long story why I am trying to re-write that particular
> >>>> entry.
> >>>>
> >>>> Thanks for your help and comments!
> >>>> Angela
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 10/15/07, Angela Wang <Angela.Y.Wang at hsc.utah.edu> wrote:
> >>>>>
> >>>>>
> >>>>>> I am trying to write two values into a DICOM header entry for my
> >>>>>> processed
> >>>>>> image file.  This one tag does not write my values. I am able, however,
> >>>>>> to
> >>>>>> change other DICOM header entries.  The tag is (0008,0008) for Image Iype
> >>>>>> and takes type CS = code string.
> >>>>>> The code looks like:
> >>>>>>
> >>>>>>       ReaderType::DictionaryArrayRawPointer dictPointer =
> >>>>>>                      reader -> GetMetaDataDictionaryArray();
> >>>>>>       ReaderType::DictionaryRawPointer dict = (*dictPointer)[i];
> >>>>>>       itk::MetaDataDictionary & dictionary= *dict;
> >>>>>>       std::string tagkey, value;
> >>>>>>       tagkey = "0008|0008";         // Image Type  vr = CS
> >>>>>>       value = "ORIGINAL\\SECONDARY";
> >>>>>>       itk::EncapsulateMetaData<std::string>(dictionary, tagkey, value);
> >>>>>>
> >>>>>> Does anyone know how to make this work?
> >>>>>> Thanks.
> >>>>>> Angela
> >>>>>> _______________________________________________
> >>>>>> Insight-users mailing list
> >>>>>> Insight-users at itk.org
> >>>>>> http://www.itk.org/mailman/listinfo/insight-users
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> _______________________________________________
> >>>> Insight-users mailing list
> >>>> Insight-users at itk.org
> >>>> http://www.itk.org/mailman/listinfo/insight-users
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
>
> --
> Angela Wang
> Research Analyst
> University of Utah
> Center for Alzheimer's Care
> Imaging and Research
> 650 Komas Dr. Suite 106A
> Salt Lake City, UT 84108-1225
> (801)587-3694
> angela.y.wang at hsc.utah.edu
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>


-- 
Mathieu

More information about the Insight-users mailing list