darktable can export to jxl. I think I did an analysis of different settings/efforts. The reduction in file size using a high effort are not worth the time it takes to encode. I think effort 3 was the ideal. Check GitHub issues for a the analysis.
2 Likes
I suspect your ImageMagick installation is old, before it could encode JXL. So IM ignored the unknown file extension, and encoded the output in the same format as the input. (I consider this bad behaviour by IM, and would prefer that it told me āCanāt encode JXL.ā)
This ā¦
convert -list format
ā¦ will tell you what formats can be read or written by your IM installation.
1 Like
One would use djxl for that purpose.
I hinted earlier, but choosing an image file format is not just about pixel values and compression. Metadata preservation across the ecosystem should be part of the process as well.
3 Likes
Well, for that part, as long as I have the raw and can use something like exiv2 / exiftool to dump stuff as text or whatever, it doesnāt worry me too much.
I keep all my final exports as PNG. Itās lossless compressed and well-supported by most software.
3 Likes
No need to apologise. The tangents from this thread are helpful and informative.
In my original post I was describing a workflow for panorama stitching. I wondered in the PNG file caused any loss. It appears not to. But then I started looking at my archival storage of edits. I like to keep the original RAW and in the same folder an 16 bit Tiff file of the edit in Adobe RGB. I also tend to put a white border and caption (watermark) on my images to describe the location of my travel pictures. So the actual edited image size if much larger than the captured image. This brings up an interesting issue with file size.
I did the following tests for the image saving with and without borders.
Tiff compressed 158 mb compared to uncompressed 372mb if there is no white border. But with border a massive 640mb file uncompressed compared to just 163mb compressed. I feel based on this I need to start using compression to save storage space if I have a white border. Even without a border there is significant space saving with compression.
I also looked at JXL lossless and it was 238mb with border and 233mb without border. Compressed tiff seems more efficient.
PNG was 159 with border at default compression of 5 and 320mb with no compression. The PNG without a white border was 155 at default compression of 5 and 186 with no compression. This suggests to me that PNG uncompressed may be a very suitable file format for my bordered images. Also PNG for both quality and file size seems suitable for my panorama stitching workflow.
Take home message for me is to start using compressed tiffs and uncompressed PNGs for my exports.
Criticism of my decision is welcome.
2 Likes
Is uncompressed PNG actually a thing? Iād expect that an image should have roughly the same size in any format without compression (basically number of pixels * bit depth + a bit of overhead and metadata).
If the uncompressed PNG is much smaller than the uncompressed TIFF, then there actually has to be some compression.
1 Like
You may read https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf if you are interested in the bit overhead and metadata.
Most file formats contain more than plain data. (Years ago, I opened MSOffice files with a text editorā¦the files contained the complete path to the executables, including user name; donāt know of it still so.)
I suspect thereās still basic stuff like āthis rectangular area is of an uniform colorā or whatever, which may not be counted as compression. This, or even the lowest setting indeed includes some sort of compression.
I donāt quite get why you would not always compress PNGs at least a little bit. To export faster?
Meanwhile, I had a little chat about bit depth and stuff with an LLM (Gemini), and the key takeaways for me (assuming it is not hallucinating but it cited a bunch of sources) were:
TIFF [ā¦] supports various color spaces, including CMYK , which is the standard for most commercial printing. PNG is primarily designed for web and digital screens and only supports the RGB color space. If your printing needs ever require a CMYK workflow, a 16-bit TIFF is the only viable option.
(Well, to be honest, color spaces are still something of a mystery to me.)
The difference in file size between a compressed 16-bit TIFF and a 16-bit PNG is often not significant enough to outweigh the other benefits of TIFF.
This matches my (rough) observations.
TIFF has a much broader and more established history in professional imaging, publishing, and archival industries. This ensures that a TIFF file created today will be easily opened and edited by the software of tomorrow.
[32-bit float] is useful for high-end HDR or scientific imaging, [but] completely unnecessary for archiving a standard photograph. It is the standard for professional visual effects [ā¦] where extreme precision and flexibility are required.
It kinda convinced me, even if I doubt that the āsoftware of tomorrowā will have any more trouble with PNGs than with TIFF, haha.
(It also told me that dynamic ranges were using a logarithmic scale and were therefore measured in decibels, which surprised me as I thought that this was specifically for sound. 
)
Edit: As for what RawTherapee uses internally during the edits, the home page of their website strongly hints at 32-bit floats.
1 Like
But this is compression. Even if it sounds simple, it still needs logic to actually detect those areas and some way to encode them.
Thatās the thing I read over and over again when I looked into the topic and is a point that I highly question. PNG is widely used and supported by more or less any application that deals with images. I donāt think that the risk of PNG not being readable anymore in the future is higher than for TIFF.
On the other hand, TIFF is basically just a container format that can contain different things. Just the fact that it supports different compression methods did already multiple times result in me not being able to use my own files in some circumstances (e.g. at some print shops). I never once had an issue with a PNG file.
So actually, I am more afraid of my TIFF files not being readable anymore in the future than my PNGs (that said, I donāt think this is something we actually need to worry about in practice).
This goes both ways - PNG for example has ambiguous support for color profiles so if youāre storing anything other than sRGB you might also run into problems w/ some apps/shops. Even worse w/ Exif metadata. Itās only w/ PNGv3 (June 2025!) that both things are in a better shape, but apps need time to catch up implementing this latest spec level.
In conclusion, both are āimperfectā, one just has to pick what works best for their specific needs.
4 Likes
RawTherapee only suggests the ādeflateā compression method (-tz instead of -t). It seems relatively standard. I wonder if you were using this or something more esoteric when you had issues with a shop. 
Speaking of āusing oneās own filesā: my file browser (Thunar) was unable to show thumbnails for float-colors files, and my image viewer could not open them either. 
If I have to rummage through old pics, I prefer them to be easily browsable 
(Also, I think the thumbnailer has a file-size limit and skips stuff that is too big, but thatās the first time I worry about this for anything else than a video. 
)
The two prevalent options for lossless TIFF compression are deflate (i.e. ZIP) and (older) LZW. (Side note: the article doesnāt cover this, but you always want to compress w/ horizontal predictor as well.) Not every app implements both, and not every app supports the predictor.
Support for float TIFFs is even more rare unfortunately.
Does RawTherapeeās default profile, RTv4_sRGB, count as an sRGB or is it something too elaborate for PNGs?
When I open those PNGs in GIMP, it asks me whether I want to keep the profile or convert it to GIMPās profile, but I honestly donāt see any difference in the result. 
(One of the 29572 mysteries about profiles for me.)
darktable has multiple options. I donāt remember which ones caused issues, I think the one with the best compression was unfortunately among them. Iām now typically exporting PNG for printing, so I donāt have to remember which TIFF settings are okay. But I only use sRGB for those, so I donāt have any experience with other colour profiles.
dt only uses deflate/ZIP for export (LZW is supported for import), the only options are w/ or w/o horizontal predictor (as mentioned one typically wants it for even smaller file size), and compression level (speed vs size trade-off).
P.S. RT seems to only do deflate w/ predictor if compression is enabled (and no control over compression level).
P.P.S. For the interested: the slightly smaller PNG size on average is due the fact that it can use several additional predictors (filters) that make the job for the compression algorithm (still the same deflate/ZIP) somewhat easier.
1 Like
For JPEG XL itās early days still, with lots of room for further encoding optimisations, whether itās for speed or size. This also means you should probably make sure to use the latest encoder version whenever possible.
2 Likes
Thanks. Indeed, I made a quick test now and PNG with level 0 results in roughly the same size as uncompressed TIFF or BMP for me. Now I wonder why @Terry got a significantly smaller file with PNG compared to TIFF (320 vs 640 MB). Maybe I misunderstood something in the comparison?
One is 8-bit and the other 16-bit?