Hi all, 

the proposed changes look fine to me. Daniel, if you do not have any specific 
doubts, I would say: Lets incorporate them. 

Regards,
Klaus

-----Ursprüngliche Nachricht-----
Von: Samuel Silva [mailto:[email protected]] 
Gesendet: Dienstag, 31. März 2009 14:23
An: Maleike Daniel
Cc: Fritzsche Klaus; Christoph Bergmeir
Betreff: Re: [mitk-users] 4D data loading from file sequence

Hello!

So here goes a description of what I wanted to do and how I accomplished it.

- I have a sequence of 2D DICOM CT images which contain 12 volumes taken 
along the time.
- The sequence I am currently using, pre-processed using MeVisLab at 
some point, allows the distinction of  the volume an image belongs to by 
looking into tag 0021,1110
- As a first approach I used the "OpenSequence" code from MainApp in my 
applicaton but, eventhough all the sequence was opened, all volumes 
appeared together, i.e., no proper separation was being done
- I then add a restriction using the tag mentioned above but the volumes 
were not being separated
- I checked into MITK and ITK code and realized that when SetDirectory 
was called in mitkDataTreeNodeFactory it computed the unique ID for each 
file on the spot using some default tags and eventualy some user defined 
restrictions *BUT*...
- The problem is that user restrictions are only add (in 
mithDataTreeNodeFactory) to the  generator after SetDirectory is called 
and thus are not used to compute the UIDs. I checked this by running it 
step-by-step.
- I then moved the SetDirectory to after setting the restrictions and 
can confirm that now, when SetDirectory is invoqued, it properly uses 
the restriction I added, properly building the UIDs.
- This now allows for proper sorting and separation of my files into 
volumes and I can successfully read and separate all 12 volumes, which 
was what I aimed for.

Concluding, by doing this change to the mitkDataTreeNodeFactory (and 
adding the restriction I needed) I successfully dealt with my data using 
the remaining MainApp code.

//===========================================================
// An excerpt of the fileOpenSequence code, taken from MainApp
// The only relevant change is the AddRestriction line
(...)
        factory->SetFileName(fileName.toAscii());
        factory->SetImageSerie(false);
        if (start != stop)
        {
          factory->SetImageSerie(true);
          factory->SetFilePattern( pattern );
          factory->SetFilePrefix( prefix );
          factory->SetUseSeriesDetails(true);
          factory->AddSeriesRestriction("0021|1110");
        }
        QApplication::setOverrideCursor( QCursor(Qt::WaitCursor) );

        factory->Update();
        factory->SetImageSerie(false);
        fileOpenGetFactoryOutput(*factory.GetPointer());
        firstFileOpen = false;
(...)
//========================================================

//========================================================
// Relevant part of ReadFileSeriesTypeDCM where I performed the code change

void mitk::DataTreeNodeFactory::ReadFileSeriesTypeDCM()
{
  std::cout << "loading image series with prefix " << m_FilePrefix << " 
and pattern " << m_FilePattern << " as DICOM..." << std::endl;

  typedef itk::Image<short, 3> ImageType;
  typedef itk::ImageSeriesReader< ImageType > ReaderType;
  typedef std::vector<std::string> StringContainer;
  typedef itk::GDCMImageIO IOType;
  typedef itk::GDCMSeriesFileNames NameGeneratorType;

  std::string dir = this->GetDirectory();
  std::cout << "dir: " << dir << std::endl;

  IOType::Pointer dicomIO = IOType::New();

  // Get the DICOM filenames from the directory
  NameGeneratorType::Pointer nameGenerator = NameGeneratorType::New();

 //// nameGenerator->SetDirectory( dir.c_str() ); // ---> line commented

  // add more criteria to distinguish between different series
  nameGenerator->SetUseSeriesDetails( m_UseSeriesDetails );


  // add series restrictions
  std::vector<std::string>::const_iterator it;
  for(it=m_SeriesRestrictions.begin(); it!=m_SeriesRestrictions.end(); it++)
  {
    nameGenerator->AddSeriesRestriction( *it );
  }

  nameGenerator->SetDirectory( dir.c_str() ); //---> line added
(...)
//========================================================


I hope this helps you understand the situation. Please feel free to 
enquire on further aspects you find relevant. By looking into the 
results I obtained and by what I could check by running the relevant 
code step-by-step this seems a good solution.

Best regards,
Sam

Daniel Maleike wrote:
> On Tue, 2009-03-31 at 12:41 +0100, Samuel Silva wrote:
>   
>> Hi again!
>>
>> I changed the SetDirectory to before the SetRestrictions and after the 
>> SetUseSeriesDetails and it did not work, i.e., volumes were not separated.
>>
>> I went a bit into the code (ITK included) and it still seems logic to me 
>> the suggestion I gave. And it works perfectly.
>>
>> As far as I could tell (by going into the ITK code) the information 
>> which is wiped out when SetDirectory is called is any which is related 
>> to previous file sets and their unique IDs. So, it steel seems to me 
>> that SetRestrictions must be before the SetDirectory. This way, when 
>> CreateUniqueSeriesIdentifiers is called, in gdcmseriehelper.cxx, my 
>> restrictions are used to build the unique ID.  This is the only way I 
>> see which allows using my restrictions when building each files UID 
>> (which happens when SetDirectory is called).
>>
>> Can you point me to the ITK manual page (or other document) where you 
>> read the information you provided?
>>     
>
> Hi,
>
> I got the information from 
>
> http://www.itk.org/Doxygen/html/classitk_1_1GDCMSeriesFileNames.html
>
> (in "Detailed Description").
>
> I'm not an expert in how DICOM images are read, so it could easily be
> that your change is fine. I'll forward your mail to the person who
> worked on these lines of code (Klaus Fritzsche), he'll be back next week
> to give his comments.
>
> Still, could you describe what happens and what you expect? I still
> havn't fully understood that.
>
> Regards
> Daniel
>
>
>   


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users

Reply via email to