Update libtiff v4.4.0

[blowekamp]

The third-party libtiff is rather old and out dated.

[blowekamp]

@dzenanz The current ITK/Modules/ThirdParty/TIFF does not have a sub-tree. How does one initialize using sub-trees and the UpdateFromUpstream infrastructure?

[dzenanz]

For vanilla initializing subtrees: add a remote of the library you want to add (libtiff), fetch, then merge with main repository.

For starting a new subtree using UpdateFromUpstream infrastructure: I don't know, I have never done that. I have only made changes to existing third-party libaries and their update scripts.

@bradking should be able to advise, or maybe even get it started for us?

[blowekamp]

For reference this was the last update to the library:
54c790a

There are a lot of upstream changes, and not many local changes. So starting with a fresh upstream is reasonable IMHO.

[bradking]

I'll take a look at importing a new tiff.

[dzenanz]

Linking some related and possibly related issues:
#4777
#2959
#4102

[bradking]

As a first step, #4957 rebuilds the existing tiff 4.0.3 import with our modern history structure. That will make the update to a newer tiff version much easier.

[hjmjohnson]

FYI: Initial 10-minute attempt to update to v4.7.0. I don't have time to continue working on this at the moment.

Some file names have changed, so we need to update the updater script.

0001-ENH-Update-to-latest-v4.7.0-libtiff-codebase.patch

[blowekamp]

FYI: Initial 10-minute attempt to update to v4.7.0. I don't have time to continue working on this at the moment.

Some file names have changed, so we need to update the updater script.

0001-ENH-Update-to-latest-v4.7.0-libtiff-codebase.patch

Yes, lots of changes have happened in the last 10 year. They also add CMake instrastructure. I had not had the change to determine if it was usable or not yet.

[bradking]

For reference, VTK has imported tiff 4.6.0 and uses the upstream's CMake code with some patches.

[blowekamp]

These look like the changes VTK made:
https://gitlab.kitware.com/third-party/tiff/-/compare/v4.6.0...for%2Fvtk-20231025-4.6.0?page=2&straight=true

It appears VTK make their third party changes in a separate repository, then form the sub-tree via a script which is then merged into the main-line of the VTK repo.

[bradking]

Yes, VTK's approach has the advantage that the changes from upstream are recorded independently from VTK. It has the disadvantage that an extra repository is needed with VTK-specific tags.

With the tiff 4.0.3 re-import done, I'll move on to an actual update in ITK.

[blowekamp]

Yes, VTK's approach has the advantage that the changes from upstream are recorded independently from VTK. It has the disadvantage that an extra repository is needed with VTK-specific tags.

With the tiff 4.0.3 re-import done, I'll move on to an actual update in ITK.

Awesome, I just started to make changes in to libtiff library to get it to configure, but I'll leave it to you!

[bradking]

@blowekamp I don't know how soon I'll be able to get to it, so if you've made progress, go ahead and continue. I can help structure the history once you have something working.

[blowekamp]

After merge of #4961, there are some build issues when DCMTK in enabled that I am investigating.

[blowekamp]

@bradking It looks like there are some library properties that are not being forwarded to the DCMTK External project:
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/TIFF/src/itktiff/libtiff/CMakeLists.txt#L125

Should these target properties be replaced in ITK's 3P module CMake code, or the DCMTK configuration be updated to extract these target properties and forward to DCMTK configuration.

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/DCMTK/CMakeLists.txt#L218

[bradking]

Modules/ThirdParty/TIFF/CMakeLists.txt's setting of ITKTIFF_INCLUDE_DIRS may need to be updated.