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:[email protected]]
Sent: Friday, September 13, 2013 2:34 PM
To: Wang, Kevin
Cc: Slicer devel ([email protected]); [email protected]
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 <[email protected]> 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
> [email protected]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to
> [email protected]
> 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.
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php
Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ
Follow this link to subscribe/unsubscribe:
http://www.itk.org/mailman/listinfo/insight-developers
