Update: I've enhanced your gist with our use of QFile: https://gist.github.com/amyspark/deb7fee06ff5144028865269c8fb9967
So the issue boiled down to LibTiff requiring read+write (and not just write) access to the file. The documentation says it but sort of eliptically: > TIFFFdOpen is like TIFFOpen except that it opens a TIFF file given an open > file descriptor fd. The file's name and mode must reflect that of the open > descriptor. The object associated with the file descriptor must support > random access. We thought that was just random seeking + writing, but the directory link actually reads back the partially written TIFF when creating subsequent IFDs. Thanks again for your help! amyspark On 10/12/2022 17:12, L. E. Segovia wrote: > Thanks so much! The only difference between yours and my code is that, > we're using TIFFFdOpen instead of TIFFOpen, since we rely on Qt's QFile > to resolve content URLs on Android. > > When using TIFFOpen, the multi-page files are generated properly, so > would this be an issue with LibTiff when using descriptor-backed files > directly? > > (Do notice this was tested on Windows, but I think it may affect Linux > too, since that's the OS the bug report comes from.) > > amyspark > > On 10/12/2022 09:44, [email protected] wrote: >> It should work. I made you a tiny demo prog: >> >> https://gist.github.com/jcupitt/912b0da1c95b615152fa0fbd6e4cc821 >> >> It builds and runs without error, and the result loads into gimp as a >> 10 page document (or 10 layer image). >> >> >> >> On Sat, 10 Dec 2022 at 12:16, L. E. Segovia <[email protected]> wrote: >>> >>> Um, this is the gist of my initial post. Using TIFFWriteDirectory >>> sequentially just does not work, so I'm left with no way to create >>> multipage TIFFs: >>> >>>> creation fails with these lines logged: >>>> >>>>> krita.file: "TIFFLinkDirectory: Error fetching directory count" >>>>> krita.file: "TIFFRewriteDirectory: Error fetching directory count" >>>> >>>> A breakpoint on the TIFF error writing routine shows that both are >>>> issued the moment I call TIFFWriteDirectory for the second and further >>>> layers. TIFFCreateDirectory, which I saw suggested in tif_overview.c, >>>> does not have an effect here. >>> >>> I'm not sure if the documentation is mistaken or I'm doing something >>> wrong, as most examples out there use SubIFD (and even those are few and >>> far between). >>> >>> amyspark >>> >>> On 10/12/2022 08:29, [email protected] wrote: >>>> Yes, TIFF files have two page dimensions. >>>> >>>> You can put directories one after the other with TIFFWriteDirectory() >>>> and you'll get a simple multipage document, conceptually like a PDF. >>>> This is the dimension you'll find most widely supported in things like >>>> GIMP. >>>> >>>> Hanging off each top level "page" you can also have subifds. You need >>>> extra API to read these and they are not so widely used. The biggest >>>> application I've found is in OME-TIFF which stores each channel (so >>>> RGB plus various fluorescence and confocal layers) as a separate >>>> top-level mono image, then uses subifds to hold pyramid levels. >>>> >>>> Unless you really need subifds, I'd stick to just using >>>> TIFFWriteDirectory(). Just call it at the end of each page, no need >>>> for TIFFCreateDirectory(). >>>> >>>> On Sat, 10 Dec 2022 at 02:17, L. E. Segovia via Tiff >>>> <[email protected]> wrote: >>>>> >>>>> Yes, I did this, but not even GIMP recognises such multi-page files. >>>>> >>>>> On a related matter, judging from >>>>> https://linux.die.net/man/3/tiffsetdirectory, there should be a way to >>>>> not need to tamper with TIFFTAG_SUBIFD, i.e. using TIFFReadDirectory >>>>> sequentially. In fact, it was the approach we were using up to now. >>>>> >>>>> That brings me a few questions to mind: >>>>> >>>>> - Does anyone know if that's the intended use of TIFFReadDirectory? If >>>>> so, wasn't the function intended to seek into the next directory on its >>>>> own? >>>>> - Alternatively, are we supposed to use TIFFSetSubdirectory before each >>>>> TIFFReadDirectory? (getting the offsets with TIFFGetField) >>>>> >>>>> Best, >>>>> >>>>> amyspark >>>>> >>>>> On 09/12/2022 10:52, [email protected] wrote: >>>>>> Hello amyspark, >>>>>> >>>>>> My understanding is that you set the magic TIFFTAG_SUBIFD tag on a >>>>>> directory with an $n element array of offsets, all initialized to 0, >>>>>> and then the next $n TIFF directories you write will appear as >>>>>> subdirectories of this directory, with the offsets filled in for you. >>>>>> >>>>>> Or that's what I did here and it seems to work for me: >>>>>> >>>>>> https://github.com/libvips/libvips/blob/master/libvips/foreign/vips2tiff.c#L2127-L2141 >>>>>> >>>>>> John >>>>>> >>>>>> On Fri, 9 Dec 2022 at 12:26, <[email protected]> wrote: >>>>>>> >>>>>>> The page I followed when implementing TIFF subframe writing is: >>>>>>> >>>>>>> https://stackoverflow.com/questions/11959617/in-a-tiff-create-a-sub-ifd-with-thumbnail-libtiff >>>>>>> >>>>>>> HTH >>>>>>> Paavo >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tiff <[email protected]> On Behalf Of L. E. Segovia >>>>>>> via Tiff >>>>>>> Sent: reede, 9. detsember 2022 03:29 >>>>>>> To: [email protected] >>>>>>> Subject: [Tiff] How to write multi-file TIFFs >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'm writing to ask about how to create a TIFF with multiple sub-images. >>>>>>> Our writing code at Krita is unable to create this kind of files, >>>>>>> creation fails with these lines logged: >>>>>>> >>>>>>>> krita.file: "TIFFLinkDirectory: Error fetching directory count" >>>>>>>> krita.file: "TIFFRewriteDirectory: Error fetching directory count" >>>>>>> >>>>>>> A breakpoint on the TIFF error writing routine shows that both are >>>>>>> issued the moment I call TIFFWriteDirectory for the second and further >>>>>>> layers. TIFFCreateDirectory, which I saw suggested in tif_overview.c, >>>>>>> does not have an effect here. >>>>>>> >>>>>>> Does anyone know the correct incantations to create this kind of files? >>>>>>> I'm running LibTiff 4.4.0 at present. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> amyspark >>>>>>> >>>>>>> -- >>>>>>> amyspark 🌸 https://www.amyspark.me >>>>>>> _______________________________________________ >>>>>>> Tiff mailing list >>>>>>> [email protected] >>>>>>> https://lists.osgeo.org/mailman/listinfo/tiff >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Tiff mailing list >>>>>>> [email protected] >>>>>>> https://lists.osgeo.org/mailman/listinfo/tiff >>>>>> _______________________________________________ >>>>>> Tiff mailing list >>>>>> [email protected] >>>>>> https://lists.osgeo.org/mailman/listinfo/tiff >>>>> >>>>> -- >>>>> amyspark 🌸 https://www.amyspark.me >>>>> _______________________________________________ >>>>> Tiff mailing list >>>>> [email protected] >>>>> https://lists.osgeo.org/mailman/listinfo/tiff >>> >>> -- >>> amyspark 🌸 https://www.amyspark.me > -- amyspark 🌸 https://www.amyspark.me _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
