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/Developers/FAQ _______________________________________________ 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
