So there are two aspects to the embedding… 1 - What do you embed? are you just using the codec itself, or are you embedding the JXL code stream? For HEIC they agreed on the latter, since it means that it can be fed directly to a JXL implementation w/o any transcoding or modifications required. But it leads to 2…
2 - How do you deal with the features of TIFF that define key rendering/processing metadata (e.g., resolution, size, colorspace, etc.) vs. the same values in the JXL code stream? Leonard ________________________________ From: Even Rouault <[email protected]> Sent: Saturday, November 29, 2025 8:47:12 PM To: Leonard Rosenthol <[email protected]>; Bob Friesenhahn <[email protected]>; Romeyke, Andreas <[email protected]>; '[email protected]' <[email protected]> Subject: Re: [Tiff] Overview of supported/registered compression mode? Anybody working on FFV1 or QOI support? EXTERNAL: Use caution when clicking on links or opening attachments. Hi Leonard, I may have seen this. But how would that affect JXL-in-TIFF ? In HEIC, HEIC plays the same role as TIFF as a container, right? What kind of alignment are you thinking too exactly? The embedding of the JPEG XL codestream into each container is a container specific matter. In the instance of TIFF, there isn't even a new TIFF tag needed (just pseudo tags to configure the compressor) Even Le 29/11/2025 à 19:23, Leonard Rosenthol a écrit : Even - are you aware of the work at ISO/IEC (JTC 1/SC 1 & 2) to bring JPEG XL into HEIC files? It would be good to align those two efforts, since in both cases they are using JXL code streams within a larger container format. Leonard From: Tiff <[email protected]><mailto:[email protected]> on behalf of Even Rouault via Tiff <[email protected]><mailto:[email protected]> Date: Saturday, November 29, 2025 at 6:55 AM To: Bob Friesenhahn <[email protected]><mailto:[email protected]>, Romeyke, Andreas <[email protected]><mailto:[email protected]>, '[email protected]<mailto:[email protected]>' <[email protected]><mailto:[email protected]> Subject: Re: [Tiff] Overview of supported/registered compression mode? Anybody working on FFV1 or QOI support? EXTERNAL: Use caution when clicking on links or opening attachments. Hi, GDAL has a TIFF JPEG-XL codec at https://github.com/OSGeo/gdal/blob/master/frmts/gtiff/tif_jxl.c<https://github.com/OSGeo/gdal/blob/master/frmts/gtiff/tif_jxl.c> relying on libjxl. I'll likely submit it to libtiff upstream some day. I had been waiting for libjxl to go to the 1.0 milestone for that for now. Even Le 28/11/2025 à 15:32, Bob Friesenhahn via Tiff a écrit : > I have not heard of anyone working on QOI or FFV1 compression in > libtiff. If the work is performed suitably well (according to project > standards) and there is some assurance of continued support, the usage > license matches libtiff's license, and there is some assurance of > development support for some time after integration, the work is > likely to be integrated. > > The performance of compression in libtiff is rather dependent on > strip/tile sizes. Have you investigated modifying strip/tile sizes to > see if more can be gained from existing codecs? > > Have you tried WebP compression in libtiff? There is lossless WebP > support in libtiff! WebP compression should work rather well provided > that the image is a natural scene. WebP does not support large > images, but it should work well if a large image is diced up into tiles. > > Bob > > On 11/28/25 08:01, Romeyke, Andreas via Tiff wrote: >> >> Hi, >> >> For our long-term archive, we are considering switching from baseline >> TIFF 6.0 to a successor format that can efficiently compress images >> losslessly. To minimize conversion issues, one option would be to >> simply change the codec within TIFF. We've seen that "tiffcp" >> supports lzw, lzma, and zstd. >> >> Compared to the lossless encoding in Quite OK Image File Format >> (qoi), PNG, and especially compared to FFV1 or JPEG XL, the >> achievable compression rates are suboptimal[1]. >> >> Therefore, our question is: >> >> Is there an overview of which codecs libtiff currently supports? >> >> And is anyone already working on integrating qio or FFV1? >> >> If not, would such extensions have a chance of being incorporated >> into libtiff? >> >> With best regards >> >> Andreas >> >> [1] our testset (scans historic monographs) results in ff. lossless >> compression ratios: >> >> tiff/lzw – 94% >> >> tiff/zstd – 67% >> >> qoi – 50% >> >> png – 53% >> >> ffv1 – 36% >> >> jpeg-xl – 33% >> >> -- >> >> team member “long-term preservation“ >> >> Saxon State- and University Library Dresden (SLUB) >> >> Department 2 (IT), Division 2.3 (infrastructure and digital long-term >> preservation) >> >> Zellescher Weg 18 | 01069 Dresden >> >> phone: +49 351 4677 763 >> >> E-Mail: >> [email protected]<mailto:[email protected]> >> <mailto:[email protected]> >> >> http://www.slub-dresden.de/<http://www.slub-dresden.de/> >> <http://www.slub-dresden.de/<http://www.slub-dresden.de/>> | @slubdresden >> >> >> _______________________________________________ >> Tiff mailing list >> [email protected]<mailto:[email protected]> >> https://lists.osgeo.org/mailman/listinfo/tiff<https://lists.osgeo.org/mailman/listinfo/tiff> > _______________________________________________ > Tiff mailing list > [email protected]<mailto:[email protected]> > https://lists.osgeo.org/mailman/listinfo/tiff<https://lists.osgeo.org/mailman/listinfo/tiff> -- http://www.spatialys.com/<http://www.spatialys.com/> My software is free, but my time generally not. _______________________________________________ Tiff mailing list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff<https://lists.osgeo.org/mailman/listinfo/tiff> -- http://www.spatialys.com/<http://www.spatialys.com/> My software is free, but my time generally not.
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
