Working Around Bugs in Third Party Libraries
This is another story of continuous improvement, this time in mahotas' little brother imread.
Last week, Volker Hilsenstein here at EMBL had a few problems with imread on Windows. This is one of those very hard issues: how to help someone on a different platform, especially one which you know nothing about?
In the end, the problem was not Windows per se, but an old version of libtiff. In that version, there is a logic error (literally, there is a condition which is miswritten and always false) and the code will attempt to read a TIFF header from a file even when writing. Mahotas-imread was not ready for this.
Many (especially in the research open-source world, unfortunately) would just say: well, I won't support broken versions of libtiff: if your code does not adhere to the spec, I am just going to not work for you, if you don't do exactly what you should, then I won't work either. See this excellent old essay by Joel Spolsky on this sort of thing.
In my case, I prefer to work around the bug and when libtiff tries to read in write mode, return no data; which it correctly handles. I wrote the following data reading function to pass to libtiff:
tsize_t tiff_no_read(thandle_t, void*, tsize_t) { return 0; }
The purpose of this code is simply to make imread work even on a broken, 5 year old version of a third party library.
§
In the meanwhile, we also fixed compilation in Cygwin as well as a code path which led to a hard crash.
Especially the possibility of a hard crash made me decide that this was important enough to merit a new release.
Related articles
imread 0.3.0 (pypi.python.org)
Using imread to save disk space (metarabbit.wordpress.com)