[Insight-developers] [slicer-devel] bug in vtkITKArchetypeImageSeriesReader and possible improvement in slicer and ITK

Matt McCormick matt.mccormick at kitware.com
Fri Sep 13 16:57:25 EDT 2013


Hi Kevin,

Yes, that sounds like a good plan.

Thanks,
Matt

On Fri, Sep 13, 2013 at 7:53 PM, Wang, Kevin <kevin.wang at rmp.uhn.on.ca> wrote:
> Hi Matt,
>
> Thanks for your comments on this.
>
> I agree that there should be no changes to itk::ImageSeriesReader. I am too used to VTK thinking.
>
> Your proposal to check the componentType using imageIO for each 2D dicom slice should be working. Here is what I think, instead of store all the componentType in a vector variable SliceNativeScalarTypes, use min and max to track the intensity range, then after go through all the slices, use the min and max to determine the suitable OutputScalarType for the volume. Pseudocode:
>
> for( const_iterator fileNamesIt = this->FileNames.begin; fileNamesIt !=
> this->FileNames.end(); ++fileNamesIt)
>   {
>   imageIO->SetFileName( *fileNamesIt );
>   imageIO->ReadImageInformation();
>   if (imageIO->GetComponentType() == itk::ImageIOBase::UCHAR)
>     {
>     min = std::numeric_limits<uint8_t>::min() < min ? std::numeric_limits<uint8_t>::min() : min;
>     max = std::numeric_limits<uint8_t>::min() > max ? std::numeric_limits<uint8_t>::max() : max;
>     }
>   if (imageIO->GetComponentType() == itk::ImageIOBase:: CHAR) // check all other types
>     {
>     min = ...
>     max = ...
>     }
>         ...
>   }
>
> if (this->UserNativeScalarType)
>   {
>   if( max <= std::numeric_limits<int8_t>::max() && min >= std::numeric_limits<int8_t>::min() )
>     {
>     this->SetOutputScalarType(VTK_CHAR)
>     }
>   if ()  // ... do the check for all other types
>     {
>     this->SetOutputScalarType(VTK_UNSIGNED_CHAR)
>         }
>         ...
>   }
>
> Thanks,
>
> Kevin
>
>
> -----Original Message-----
> From: Matt McCormick [mailto:matt.mccormick at kitware.com]
> Sent: Friday, September 13, 2013 2:34 PM
> To: Wang, Kevin
> Cc: Slicer devel (slicer-devel at bwh.harvard.edu); insight-developers at itk.org
> Subject: Re: [slicer-devel] bug in vtkITKArchetypeImageSeriesReader and possible improvement in slicer and ITK
>
> Hi Kevin,
>
> Thanks for proposing your patch and mentioning it on the list.  Your patches are always welcome.  Instructions for submitting a patch can be found here:
>
>   http://insightsoftwareconsortium.github.io/ITKBarCamp-doc/CommunitySoftwareProcess/SubmitAPatchToGerrit/index.html
>
> As I understand the problem, (which may be incorrect), a change should not be necessary on itk::ImageSeriesReader.  itk::ImageFileReader and itk::ImageSeriesReader are template based, and the output pixel type is determined by the pixel type of the output image template parameter, so an OutputImagePixelScalarType does not apply to itk::ImageSeriesReader.
>
> In vtkITKArchetypeImageSeriesReader.cxx, after determining the correct imageIO in ::ExecuteInformation(), around line 720, would gathering an array of NativeScalarTypes to expose to the user of vtkITKArchetypeImageSeriesReader generate the functionality that is desired?  Pseudocode:
>
>   this->SliceNativeScalarTypes.resize( this->FileNames.size() );
>   for( const_iterator fileNamesIt = this->FileNames.begin(), iterator scalarTypesIt = this->SliceNativeScalarTypes.begin(); fileNamesIt !=
> this->FileNames.end(); ++fileNamesIt, ++scalarTypesIt )
>   {
>   imageIO->SetFileName( *fileNamesIt );
>   imageIO->ReadImageInformation();
>   *scalarTypesIt = imageIO->GetComponentType();
>   }
>
> Thanks,
> Matt
>
> On Fri, Sep 13, 2013 at 3:11 PM, Wang, Kevin <kevin.wang at rmp.uhn.on.ca> wrote:
>> Hi slicer,
>>
>>
>>
>> I am developing a module in Slicer and I found a bug in
>> vtkITKArchetypeImageSeriesReader class. Here is the issue.
>>
>>
>>
>> Since dicom utilizes the concept of slope and intercept, the scalar
>> range for each 2D slice can be much different. However, in Slicer, the
>> scalar type is determined by checking the ComponentType returned by
>> GDCMImageIO which only tells the last slice ComponentType in
>> vtkITKArchetypeImageSeriesReader.cxx.
>>
>> I propose to change vtkITKArchetypeImageSeriesReader.cxx as well as
>> the itkImageSeriesReader class in ITK. The idea is that the scalar
>> range will be checked for each 2D slice in itkImageSeriesReader and
>> then a new variable OutputImagePixelScalarType will be set
>> accordingly, then in vtkITKArchetypeImageSeriesReader.cxx it will
>> check the OutputImagePixelScalarType from the itkImageSeriesReader to
>> correctly determine the scalar type.
>>
>>
>>
>> If you think this makes sense, I will create an ITK ticket and submit
>> a patch to ITK. The slicer patch has to wait until slicer start to use
>> the newly patched ITK. I have created a ticket for tracking this:
>> http://na-mic.org/Mantis/view.php?id=3386
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kevin
>>
>>
>> This e-mail may contain confidential and/or privileged information for
>> the sole use of the intended recipient.
>> Any review or distribution by anyone other than the person for whom it
>> was originally intended is strictly prohibited.
>> If you have received this e-mail in error, please contact the sender
>> and delete all copies.
>> Opinions, conclusions or other information contained in this e-mail
>> may not be that of the organization.
>>
>> _______________________________________________
>> slicer-devel mailing list
>> slicer-devel at bwh.harvard.edu
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to
>> slicer-devel-request at massmail.spl.harvard.edu
>> with unsubscribe as the subject
>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel
>> opers/FAQ
>
> This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient.
> Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited.
> If you have received this e-mail in error, please contact the sender and delete all copies.
> Opinions, conclusions or other information contained in this e-mail may not be that of the organization.
>


More information about the Insight-developers mailing list