[ITK] Tests with multi-file input data (Bruker2DSEQ)
Wood, Tobias
tobias.wood at kcl.ac.uk
Wed Jun 14 10:06:40 EDT 2017
Thanks again Brad.
I have one more question that I apologise in advance for asking, because it is probably in a help guide somewhere but I can’t find it - What is the minimum set of commands required to rebuild and rerun a single test after I make changes?
I’m trying to avoid doing a ‘make all’ or ‘make test’ so I don’t have to wait for all >2000 tests to compile and run. I have been trying:
make ITKIOBruker2DSEQTestDriver -j 4
ctest -R -V itkBruker2DSEQ
However, this does not seem to trigger the transfer of the test files into the ExternalData/Modules/IO directory, and the test fails. I’m clearly missing something obvious...
Toby
On 14/06/2017, 14:30, "Lowekamp, Bradley (NIH/NLM/LHC) [C]" <blowekamp at mail.nih.gov> wrote:
That is a little complicated of a directory structure.
I would separate the arguments to run the test and defining the data dependency. First `ExternalData_Expand_Arguments` is called with the path to “acquisition” in the source directory, which contains the MD5. Something like:
ExternalData_Expand_Arguments(ITKData
ExpandedData # ignores output variable
DATA{Input/acquisition/,RECURSE:,REGEX:.*}
)
Then add the test :
itk_add_test( NAME itkBurkerTest1 COMMAND ITKBurkerTestDirver DATA{Input/acquisition/1/2dseq}"
You can find an example of this here:
https://github.com/InsightSoftwareConsortium/ITK/blob/c5c879ad54778ce3b514fd35c197ed4340ccd976/Modules/Filtering/FFT/test/CMakeLists.txt#L138-L150
Please note I have not tried those lines, but I expect them to be close to the proper things to do.
Brad
On Jun 14, 2017, at 9:13 AM, Wood, Tobias <tobias.wood at kcl.ac.uk> wrote:
Thanks very much Brad. Individual responses below.
If you need an entire folder, you can create it here. I am not sure what problem you encountered with this layout.
To be honest, I didn’t try it. I assumed it would cause problems. I will try it.
There are quite a number of options for referencing files series, file pair, and associated directories. I would expect this to meet you needs.
Again thanks - I had completely missed this documentation.
It’s not clear to me what files are needed when reading, if you need recommendation on using `DATA{}` please be specific with the files needed by the IO, and their locations.
The bare minimum required to read the image are the ‘2dseq’ and ‘visu_pars’ file. I have kept the convention of the old Bruker reader which is to specify the ‘2dseq’ file as the input, and then to work out the paths to ‘visu_pars’ and the other headers.
The Bruker format is a bit complex. The issue is that each acquisition can be reconstructed multiple times. The directory structure goes something like this:
acquistion/
method
<- An important header file
acqp
<- Another important header
fid
<- Raw data
***bunch of other stuff***
pdata/
1/
2dseq
<- Reconstructed data
visu_pars
<- Most important header
reco
<- Less important header, mostly duplicated in visu_pars
procs
<- Unimportant header
id
<- Unimportant header
2/
2dseq
visu_pars
reco
procs
id
...
I hope the indentation survives transmission. Here, 1 and 2 are different reconstructed images, for instance magnitude and phase, or for diffusion it might be raw images and a multi-volume file containing FA, MD etc. as calculated by ParaVision.
From Paravision 6 onwards, the bare minimum to read an image seems to be 2dseq + visu_pars. However, some important meta-data like diffusion b-values and b-vectors is only present in the method header. Hence I’m not entirely sure what should be considered a valid “image” by ITK - just 2dseq + visu_pars, or the entire data structure?
For my uses, I think the best approach would be to consider 2dseq + visu_pars the minimum, but if the other headers are present read them in to get the meta-data. Is that acceptable?
Best wishes,
Toby
More information about the Community
mailing list