I have a couple of commits, for which the code is more or less written, it is about bugfix in image io palette handling, and adding pallette write capabilities for tiff and png. The thing is I have no idea when I’ll be able to write the proper test so that it can be accepted as a pull request.
What should I do in this case ? I don’t like see these sitting on my computer…
One of my problems with testing is that if I enable the testing on everyday basis, it takes a very long time to recompile everything each time I modify something. Also I’m in a very time consuming project right now…
I made these corrections more than one year ago, so it is not so fresh in my head.
First I found some bug while testing how itk reads metadata on a bunch of tif files provided by libtiff.
when asked not to expand the palette, some tiff with 16 bits palette (not "directly’ supported by the reader) were detected and read as 8bit because the piece of code testing the palette type did not run.
There is a use of setExpandPalette instead of GetIsReadAsScalarPlusPalette.
Ideally, I think all the files provided by libtiff should be tested for correctness of metadata reading and also testing regressions. But I have no idea how this could be done…
I’ve also implemented writing image with palette for tiff and png image. By writing palette image, I mean writing a scalar image along with its colormap, not converting to rgb, like itk was doing before.
I try to apply the same logic as the read palette image:
boolean WritePalette macro in itkImageIOBase.h
add a set macro for the color palette in itkPNGImageIO.h and itkTIFFImageIO.h
in itkPNGImageIO.cpp and itkTIFFImageIO.cpp, the logic for allocating palette and setting it to the file
It is limited to one palette by tiff file for multipage tiff, but more because I have no clear idea on how to have a proper interface for this. It would be trivial to adapt tough.
A time-saving approach is to not build the entire toolkit and its tests during development. Instead only build the target module and its regression tests. The target name is <ITKModuleName>-all. For example
To only run the tests for a specific module, use the CTest label for that module, e.g.
ctest -L ITKIOTIFF
Make sure to rebase on master in case other improvements have been made to the toolkit.
Tests that examine reading and writing images with the desired characteristics should work well. ImageJ / Fiji has great tiff support, so the test files could be generated there, or there may be some example tests in their regression data.
Cool! Since this features is currently not supported by most of the other formats, it is best to add methods on itk::PNGImageIO and itk::TIFFImageIO with a consistent name. Then, we can evaluate whether it makes sense to expand support into itk::ImageIOBase and itk::ImageFileReader / itk::ImageFileWriter.
As an addition to what Matt said about building tests, and about enabling tests on everyday basis is this: if you have enough disk space, you could have two builds, one for “everyday” or development use with tests disabled, and another build with tests enabled used for this sort of questions.
If we test the libtiff images, plus some other I generated, lets say around 80 image, how would we do this ?
Some files are explicitly not supported in itk (like specific bit types), some give error but should be supported (the purpose of one incoming path) some gives warning that someone may want to correct (eg EXIFIFDOffset has unsupported data type (18) for meta-data dictionary), etc…
What I did a that time was to read all files, output
all meta as read by itk
and check by hand that these were correct…
It seems quite a bit of work to make this working, clear and flexible.