[ITK] Tests with multi-file input data (Bruker2DSEQ)

[Matt McCormick]

Hi Toby,

Thank you for moving the Bruker support forward!


Regarding regeneration of the testing data, re-run the CMake configuration:

   cd ITK-build
   cmake .

Then run the ExternalData target

   make ITKData

To make CMake configuration faster, turn ITK_BUILD_DEFAULT_MODULES OFF and
set Module_ITKIOBruker2DSEQ ON.


In terms of uploading the data, there is another option we are trying out
that uses Girder and SHA512 -- feel free to try these instructions:

  https://itk.org/ITKExamples/Documentation/Contribute/UploadBinaryData.html


> ctest -R -V itkBruker2DSEQ

This works. Another option to be aware of is:

  ctest -L ITKIOBruker2DSEQ

which will run all the tests from the ITKIOBruker2DSEQ module.


Thanks,
Matt

On Wed, Jun 14, 2017 at 10:06 AM, Wood, Tobias <tobias.wood at kcl.ac.uk>
wrote:

> 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
>
>
>
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170614/7f6debeb/attachment-0001.html>