[Dcmlib] Re: [Fwd: Re: Images Axial Acquisition order]

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

>> I think we initialy made a lot of stupid things, in vtkGdcmReader.
>> - BuildFileListFromPattern is probabely 100% unused, because almost 
>> no dicom file name in the world can be built from a pattern
>
>
> Yes and no. It's like saying why do we ever look at ImageNumber they 
> are hardly ever used... I have seen cases where the filename respect a 
> patern. Furthermore we can also resort the filename that respect the 
> pattern, the pattern never meant: "This is the order we will read the 
> files"...
> Anyway I agree this does not seem very usefull.
>
>> - AddFileName leads to an unusable unsorted set of files
>
>
> Ok I have 500 files. I know I am interested in 100 of them let say: 
> 150-250. How do I tell vtkGdcmReader I am only interested in those 
> (remember we still don't have selection by volume(*)).


==> If you use the new ability vtkGdcmReader:: SetCoherentFileList( 
std::vector<gdcm::File* > *cfl );
to pass one of the 'Coherent File List' produced by gdcm::SerieHelper, 
there is no problem to read only a SubSet of files (whole file, of 
course, but not all the files)

>
>> - When the files are read, vtkGdcmReaderforgets immediately they were 
>> Dicom files (whe delete gdcm::File)
>
>
> evil...


==> I suggest we keep *always* the gdcm::File (there're not so big ...)
So, Python users that select an image thru their GUI will be able to 
retrieve the Dicom informations from the gdcm::File
corresponding to the image.
(Marlene will not cry any longer ...)

>
>> - when the volume is read, it's too late to transform its planes.
>
>
> yes and no. ITK has a low level notion of orientation directly in the 
> itk::Image definition. It's just that VTK does not. BUT to display a 
> vtk::Image, we use Actor that have a notion of Orientation. So yes the 
> orientation is really application level, and gdcm shall never ever try 
> to reorganize pixel to apply a transformation ! This is not our goal, 
> this is not our main focus.
> So please no code to shuffle pixel around in gdcm.
>
>> I think we have to allow user (you) to pass vtkGdcmReader a function 
>> that describes the transformations he wants to apply on each image 
>> immediately after reading.
>
>
I just added

File::TypeOrientation( ) method
/**
* \brief  THERALYS' Algorithm to determine the most similar basic orientation
(Axial, Coronal, Sagital) of the image
* \note Should be run on the first gdcm::File of a 'coherent' Serie
* @return orientation code
*   #   0 :   Not Applicable (neither 0020,0037 Image Orientation Patient
*   #                         nor     0020,0032Image Position     found )
*   #   1 :   Axial
*   #  -1 :   Axial invert
*   #   2 :   Coronal
*   #  -2 :   Coronal invert
*   #   3 :   Sagital
*   #  -3 :   Sagital invert
*   #   4 :   Heart Axial
*   #  -4 :   Heart Axial invert
*   #   5 :   Heart Coronal
*   #  -5 :   Heart Coronal invert
*   #   6 :   Heart Sagital
*   #  -6 :   Heart Sagital invert
*/

to be used by whomsoever it may interest ;-)

The user may deduce for this information what kind of swap (if any) he wants to do, program it in a function of his own, and pass the function to vtkGdcmReader.

Therefore, gdcm has not to be aware of SetMode( gdcm::Dentist );
(How may kinds of medical doctors sahal we have to deal with?)

My last idea was :
-----------------------------------------------
I think we have to allow user (you) to pass vtkGdcmReader a function 
that describes the transformations he wants to apply on each image 
immediately after reading.

The code would look like :

dicom_reader = vtkGdcmReader::New();
dicom_reader->RemoveAllFileName();
dicom_reader->AllowLookupTableOff();
gdcm::SerieHelper *sh = new gdcm::SerieHelper();
sh->SetDirectory(dicom_folder, true);
gdcm::FileList *l = sh->GetFirstCoherentFileList();
sh->OrderFileList(l);
===> dicom_reader->SetTransformationFunction(yourFunction);
dicom_reader->SetCoherentFileList(l);

Inside 'yourFunction', the user would have acess to the gdcm:File, and 
to do exactly want he feels like (each user can choose the transformation he wants).
-----------------------------------------------

 

>
> More than a transformation I would rather see a 'Style'. As you 
> describe in a previous mail there is a more Dentist one, a more 
> conventional for XYZ...
> So I would rather see the transformation being as a subclass of 
> gdcm::Transformation. Something like:
>
> gdcm::Transformation t;
> t->SetModeToDentist();
> or
> t->SetMode( gdcm::Dentist );
>
> vtkGdcmReader->SetTransformation( t->GetOutput() )


When the whole volume is created, is it still time to perform swapping?
Did you see Luca's volume right<-->left ?
Can he transform it 'out of gdcm?

JP

>
> Mathieu
> (*) In VTK to read 100 slices from a serie we would do:
>
> reader =  bla
> reader->SetFilePattern()
> reader->SetExtent(0,511, 0, 511, 100, 250);
>                                  ^^^^^^^^
> And then the reader understand the user is only interested in a 
> subvolume of the serie and therefore will only read the necessarie 
> files. It's just a matter of notation (plus we don't have implemented 
> the Extent notion).
>