[Insight-users] Rewriting Dicom header entries

Wed Oct 17 16:43:49 EDT 2007

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