Provide example files for CIFTI-1 and CIFTI-2
ghisvail opened this issue · comments
It would be nice to add a representative CIFTI file for each format so, the example can be run without fetching additional data. A proper testsuite would be even better, but solving this issue would give the packaging a mean of verifying whether the built binaries work.
We did prepare some example files for download from NITRC (http://www.nitrc.org/frs/?group_id=454), and the ones that are CIFTI files are only a few MB, I'll see about adding them. There is a volume file in that package, which is the largest of the files, at 25MB, not sure whether to include it (and the example gifti surface file, which this library can't read). With the example files, I could write some tests using the executables from the examples - 'rewrite' across all the mapping types should hit most of the read/write code for valid files, and 'xmlinfo' hits some of the API of each mapping type.
Good to know that such example files already exist. It would be worth adding some which can be processed by rewrite and xmlinfo so that a reasonable portion of the API is covered. It still does not replace a proper testsuite (any plans for adding one) but should be enough to set-up some initial CI testing together with the packaging.
I have added some example CIFTI-2 files, I'll start looking into some simple tests. A full testsuite is probably not worth the effort at this point.
I have added some example CIFTI-2 files.
Good. Thanks.
A full testsuite is probably not worth the effort at this point.
Your call.
I added some tests that cover reading/writing all mapping types for CIFTI-2, some of the getting API (get number of vertices, etc), and validates rewritten CIFTI-2 files via md5 sums (different between qt vs xml++, but same between qt4 and qt5, amazingly enough). The CIFTI-1 code is not covered (could add CIFTI-1 versions of each file, and make rewrite write with the same version as input), nor is manual use of the setting API (some of it is used in the reading functions).
Something I realized recently: due to using checksums as a validity check, the verification tests will fail on bigendian architectures - the file can be validly written as either endian (since it is nifti), and writing is currently done native endian for new files, with no way to override. The clean way to fix these tests is probably to add endian control to the API and the rewrite example, because I don't have a bigendian system to generate the correct md5s on.
I could instead loosen the validity check considerably by accepting anything that the xmlinfo example doesn't complain about, and simply trust that nothing was lost or added to the semantics of the file (seems unlikely).
The clean way to fix these tests is probably to add endian control to the API [...]
Agreed.
[...] and the rewrite example, because I don't have a bigendian system to generate the correct md5s on.
Indeed. This way you can generate hashes for all systems on your machine.
Endian control is now in the API, and the tests, see f45acd4.