[Insight-users] EncapsulateMetaData problem
Antoine Leimgruber
antoine.leimgruber at sokal.ch
Tue May 22 14:41:56 EDT 2007
Hi Luis
Let me first say that I totally agree with you on the fact that we have to complain with the modality manufacturer. Since it occurs in special experimental conditions, is a small error, and only the header is incorrect (no distorsion of image), it might very well be that it has never be noticed or simply left aside.
There are several reasons why we tried to edit the header. First, we cannot afford to repeat the experiments only for the sake of a header mistake, since we know the actual pixel size. Second, the process of convincing the manufacturer that something is wrong and have this bug corrected, as a patch or a new soft version is taking some time.
I did look in itk code and found the itkGDCMImageIO lines fixing the 0028|0030 that you tell me about. What was puzzling me is that 0018|1164 (ImagerSpacing) was also set when we did write dicom images *without manually editing the dicom tags* using the SetPixel method to make tests. By looking more closely, I see it set in gdcmFile.cxx. This is the answer about why I had to run twice the code to edit both tags. Sorry for not noticing before, I am unfortunatly not fluent in C++.
However, I am happy to leave the tags alone and to try to get things running with the ChangeInformationImageFilter that I was not aware of.
Thank you for your help
Regards
Antoine
----- Message d'origine -----
De: Luis Ibanez <luis.ibanez at kitware.com>
Date: Sat, 19 May 2007 17:41:36 -0400
Sujet: Re: [Insight-users] EncapsulateMetaData problem
À: Antoine Leimgruber <antoine.leimgruber at sokal.ch>
Cc: insight-users at itk.org
>
>Hi Antoine,
>
>If the information from the incoming DICOM image is incorrect,
>you should first complain with your image provider. Even if
>you are scanning animals, it is pretty sad that scanner vendors
>in the 21st century can't yet get right the pixel spacing of an
>image.
>
>
>If you are forced to fix the pixel spacing, you should do it by
>using the ChangeInformationImageFilter:
>
>http://www.itk.org/Insight/Doxygen/html/classitk_1_1ChangeInformationImageFilter.html
>
>Look at the methods
>
> SetOutputSpacing();
> ChangeSpacingOn();
>
>
>The example that shows how to change tags applies to the information
>that is not inherent to ITK images, such as:
>
> Number of pixels
> Pixel Spacing
> Origin
> Orientation (direction cosines)
>
>
>These four items of the output image DICOM tags are *NOT* taken
>from the MetaData dictionary. They are taken from the itk::Image
>itself.
>
>In other word, with ITK you can edit *SOME* of the DICOM tags,
>but not *ALL* of them. In practice, the ones that you can't
>edit with ITK is because you SHOULDN't have to edit them.
>
>
>
>
> ITK IS OPEN SOURCE:
> Please look at the code:
>
> You will see where we are settting the basic information
> into the DICOM tags:
>
>
> Line 920 : of itkGDCMImageIO.cxx pixel spacing
> Line 928 : of itkGDCMImageIO.cxx slice spacing
>
> Lines 948-954: same file : for Direction (orientation cosines).
>
>
>
>
>To summarize, leave the DICOM tags alone.
>
>What you should do is:
>
>
>
> 1) Complain about the inhabilithy of the image acquirers
> for getting right basic information about an image.
>
> ... If you can't trust the image spacing...
> what can you trust ?
>
>
> 2) In your code, just after reading the DEFECTIVE DICOM image,
> pass it through a ChangeInformationFilter and fix the spacing.
>
> Paradoxically enough, you are probably replacing the old values
> with new values that you obtained from the same people who
> provided you with a defective image in the first place.
>
> The image will then have the correct information, and you
> will not need to touch the DICOM tags. Just let ITK save this
> information into the DICOM header in a normal way.
>
>
> 3) Go and complain again, with your image provider.
>
> The bottom line is that:
>
> If they can't get right the simplest piece of information
> such as pixel spacing, then how can you trust that they
> are solving correctly the other really complicated aspect
> of an image.
>
>
> The fact that this is an animal experiment is not an
> excuse for accepting mediocrity in the image acquisition.
>
>
>
>
> Regards,
>
>
> Luis
>
>
>
>==========================
>Antoine Leimgruber wrote:
>> Hi Luis,
>>
>> Thank you for your answer !
>>
>> Unfortunately, I have to do it because the spacing tags coming out of
>> the imaging modality are incorrect. (Do not be concerned, though, we are
>> imaging animals and not patients).
>>
>> I am not quite sure to understand your statement that ITK will not let
>> me do it since I understood that the DicomReadChangeHeaderWrite.cxx
>> example demonstrates the manual edition of Dicom tags:
>>
>> //This example illustrates how to read a single DICOM slice and write
>> it back
>> //with some changed header information as another DICOM slice.
>>
>> It puzzles me because edition of tags (0018|1164) and (0028|0030)
>> works when I run the code a second time on the output image of the first
>> run.
>>
>> Do you mean that ITK cannot be used for editing Dicom Headers, or are
>> you answering the second part of my question about using ITK to erase
>> dicom tags ?
>>
>> Antoine
>>
>>
>> Le 19 mai 07 à 06:30, Luis Ibanez a écrit :
>>
>>>
>>> Hi Antoine,
>>>
>>> Are you trying to manually edit the DICOM tag
>>> describing the image spacing ?
>>>
>>> If so,
>>> ITK will not let you do that.
>>>
>>> ITK uses the actual image spacing of the image
>>> and writes it down in the DICOM tags.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Luis
>>>
>>>
>>>
>>> --------------------------
>>> Antoine Leimgruber wrote:
>>>
>>>> Dear all,
>>>> I am trying to edit 3 dicoms tags (see section of code at the end of
>>>> the message).
>>>> When I run the code once, the output dicom image has 2 of the 3 tags
>>>> edited. The tag 0028|0030 remains unchanged.
>>>> If I run the code again with the previous output image as input, then
>>>> the third tag of the new output is also edited.
>>>> What can I do to avoid running twice my code on each image ?
>>>> An alternative would be to remove the tag 0018|1164 from the header.
>>>> How can I do it ?
>>>> Thank you for your help
>>>> Antoine
>>>> [...]
>>>> InputImageType::Pointer inputImage = reader->GetOutput();
>>>> typedef itk::MetaDataDictionary DictionaryType;
>>>> DictionaryType & dictionary = inputImage->GetMetaDataDictionary();
>>>> itk::EncapsulateMetaData<std::string>(dictionary,"0018|1164",
>>>> std::string("0.164800\\0.312500"));
>>>> itk::EncapsulateMetaData<std::string>(dictionary,"0028|0030",
>>>> std::string("0.164800\\0.312500"));
>>>> itk::EncapsulateMetaData<std::string>(dictionary,"0010|0010",
>>>> std::string("y pixel size edited"));
>>>> typedef itk::ImageFileWriter< InputImageType > WriterType;
>>>> WriterType::Pointer writer = WriterType::New();
>>>> writer->SetInput( reader->GetOutput() );
>>>> writer->SetFileName( argv[2] );
>>>> writer->SetImageIO( gdcmImageIO );
>>>> try
>>>> {
>>>> writer->Update();
>>>> [...]
>>>> _______________________________________________
>>>> Insight-users mailing list
>>>> Insight-users at itk.org <mailto:Insight-users at itk.org>
>>>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>
More information about the Insight-users
mailing list