> On 11 Dec 2022, at 19:58, Sulau <[email protected]> wrote: > > Hi, > > I had a quick look at it. > > Within libitff, the number of directories / directory number is stored in an > uint16_t and the number 65535 was treated as a magic number for a > "non-existing directory"! Thus, libtiff can only handle 65534 directories. > > However, many libtiff functions do not depend on the directory number. > Therefore, it is in principle possible to handle TIFF files with more than > 65535 IFDs if none of these functions that use the directory number are used. > Like the test file gray.movie.u2.tif containing 65567 pages. > > Before version 4.5.0, the existing IFD loop check was ineffective. Therefore, > no warnings occur for test files with more than 65534 directories. > > Since the directory number is contained as a uint16_t in public libtiff > interfaces, I see no quick solution at the moment other than to disable the > IFD loop check again. >
Note that 4.5.0 will change SONAME so it's an opportunity to change that if you want. > I will setup a gitlab issue. > > Su >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
