ITK 4 support for stand alone build#26
Conversation
2c286b9 to
dedfcfe
Compare
|
rebased patch set on current head of master |
dedfcfe to
cac9884
Compare
|
rebased patch set on current head of master |
|
Hi @pyushkevich Thank you for all the work you do on this great project, your work is very much appreciated :) If possible I would like to upstream changes to make Convert3D build against older versions of ITK. As I currently need to build against ITK version 4.7.2. I have tried (the best way I could think of) to make a patch set that keeps the current code paths intact and simultaneously includes ifdef's were older code snippets are needed. If you have the time, could you take a look at the patch set in this PR and advice me on what you think would be the best from here. What do you think of such a change? Is it a good/bad idea to include support for building against "ancient" versions of ITK? Would it be better to approach this in another way? |
…std::isfinite as these std functions work for both itk4 and itk5
…nst ITK newer than version 4.13
…c versions, e.g. 4.8.4 which is the default version on ubuntu 14.04
…inite with std::isfinite as these std functions work for both itk4 and itk5' patching additional changes made in master since 20240312
… additional changes made in master since 20240312
…ertException if compiled with ITK version less than 5, this is needed or the following compiler error is generated: could not convert 'ImageConverter<TPixel, VDim>::PopImage()' from 'ImageConverter<double, 4u>::ImagePointer' to 'ConvertAPI<double, 4u>::ImagePointer'
cac9884 to
e1c0ca9
Compare
|
rebased patch set on current head of master, fixed merge conflicts, and added additional patches needed to enable compiling against ITK 4.7.2 using gcc 4.8.4 on ubuntu 14.04 |
made it possible to build against itk versions going back to itk 4.7.0.
the suggested changes are based on the previous changes made during the itk 5.0 upgrade in d781da4 and 5842523
the main idea is to have two code paths guarded by a preprocessor directive that chooses the correct path for the correct itk version, this way both the previous implementation and the new itk 5 implementation can coexist in the same code base.