[Insight-users] Changes in gdcm::SeriesFileNames since ITKv4?

[jef vdmb]

Hi Yixun,
Thanks for your reply. This solved my issue.
Regards,Jef
Date: Tue, 17 Jul 2012 10:50:58 -0400
Subject: Re: [Insight-users] Changes in gdcm::SeriesFileNames since ITKv4?
From: yxliuwm at gmail.com
To: jvdmb at hotmail.com
CC: insight-users at itk.org

Hi,
There is a bug in gdcm::SerieHelper
 
Use m_UseSeriesDetails  not UseSeriesDetails

void SerieHelper::SetUseSeriesDetails( bool useSeriesDetails )
{
// Fixed
m_UseSeriesDetails = useSeriesDetails;
}
Yixun


On Tue, Jul 17, 2012 at 10:20 AM, jef vdmb <jvdmb at hotmail.com> wrote:




Hi, 


Ever since I passed to ITKv4 (4.1 and 4.2 give the same result), the behaviour of itk::GDCMSeriesFileNames seems to have changed.


I use the following standard code:



typedef itk::GDCMSeriesFileNames NamesGeneratorType;
NamesGeneratorType::Pointer namesGenerator = NamesGeneratorType::New();


// namesGenerator->SetLoadSequences(true);
// namesGenerator->SetLoadPrivateTags(true);
namesGenerator->SetUseSeriesDetails(true);
namesGenerator->AddSeriesRestriction("0008|0021");
namesGenerator->AddSeriesRestriction("0008|0032");
namesGenerator->SetDirectory(cla.input_arg);



When compiled against ITK 3.20, several DICOM series are detected. Using ITK 4.1 (and the same directory), only one series is  retained. Adding the (commented) options, does not change anything. 


My apologies if I missed the answer in this mailing list. I saw several entries reporting similar behavior, but did not come across an answer.


Regards,
Jef


_____________________________________
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://www.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-users



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20120717/eac37aed/attachment.htm>