The new JPEG-XL format (.jxl) supported by Digikam allow to "transcode" a file pic.jpg to pic.jxl file a way that you can restore pic.jpg from pic.jxl. To do that we need to "transcode" the jpeg file instead of to convert it. The related command line are : cjxl -d 0 pic.jpg pic.jxl /* the resulting file size is 20% smaller djxl pic.jxl pic2.jpg /* pic2.jpg is binary identical to pic.jpg (so there is retro-compatibility) The Batch Queue Manager allows to convert jpeg files to Jxl format but it converts, it don't transcode, so the resulting jxl files don't allow to eventually restore the jpeg as it was. This retro-compatibility is one of the capacities of the JPEG Consortium put forward to promote the format. The request is to add a transcode base tool into BQM using the commands above (or similar if others exist) : cjxl -d 0 for jxl -> jpg and djxl for jpg -> jxl.
Instead of a specific tool added in the list of tools, that could be a flag "transcode" within the convert function.
This is an ideal use case for the script function in the BQM, if you want it. Personally, I would never convert or transcode a JPG to anything else (even if the JPG can be recovered). As an example, I follow the bug reports for libheif, there are things like the colors are no longer identical, etc. "New" formats in particular are constantly being developed and changed. Maik
(In reply to Maik Qualmann from comment #2) > This is an ideal use case for the script function in the BQM, if you want it. It is a good suggestion, I will try, thanks !
Online doc to the BQM script plugin : https://docs.digikam.org/en/batch_queue/custom_script.html Gilles Caulier
(In reply to caulier.gilles from comment #4) > Online doc to the BQM script plugin : > > https://docs.digikam.org/en/batch_queue/custom_script.html > > Gilles Caulier Thank you, I just tried it. I had to choice png, tiff or jpeg. Of course, the output file is a jxl file but it has a wrong extension. It is not a real problem since I can do a batch rename it later.
(In reply to Maik Qualmann from comment #2) > Personally, I would never convert or transcode a JPG to anything else (even if the JPG can be recovered). I have a use case where 20% smaller could be useful. But anyway I did not planned to "transcode" my 70000 files right now. It was more a "study" to how do that eventually. On the other side, I began to export my raw files to jxl since it is 60% smaller (darktable can export jxl now).
*** Bug 481221 has been marked as a duplicate of this bug. ***
For those of us who do believe that JXL should replace JPG because of its amazing qualities, retaining the original quality in transcoding is important. Could you consider the inclusion of the mentioned transcoding library in Digikam? After all, it is a native feature of the JXL format, as is choosing the "effort" parameter in the encoding. The native TIFF format does not implement some of the encoding methods offered by Digikam and other image processing software. Moreover, there are so many non-native options that, as I'm sure you know, TIFF is also known as "Thousands of Incompatible File Formats". And yet, it seems that implementing all the native features of JXL is more problematic than implementing the non-native (non-standard) features for TIFF. That's my opinion, of course, but why hide from the user the native options of a format like JXL that has been developed in such a way that it covers all the weak points of the other image formats? Thank you
I was quite surprised when after testing with cjxl I tried to convert my jpg images using BQM and the resulting files were 2-3 times the original size. After this unexpected behaviour I found this ticked and would also like to support this feature request. Especially given jxl claims mathematically lossless compression (`cjxl --quality=100`/`cjxl --distance=0`) and in the case of jpg files specifically (default: --lossless_jpeg=1) the ability to reconstruct the original bit-for-bit. I have an archive of 2.8TB of jpg images. In my testing cjxl achieved compression of well over 10% that'd mean at least 280GB of space savings. (Being conservative, actual tests were around 18% which would be about 500GB) The current implementation of losslessly converting jpg to jxl has doubled and *trippled* the size of many set whereas the cjxl achieved a reduction of 19%. While disabling the lossless option and reducing the quality helped to reduce filesize it will definitely void the ability to reconstruct the original file. (In reply to Maik Qualmann from comment #2) > This is an ideal use case for the script function in the BQM, if you want it. > Personally, I would never convert or transcode a JPG to anything else (even > if the JPG can be recovered). > As an example, I follow the bug reports for libheif, there are things like > the colors are no longer identical, etc. The reason I shy away from the scripting function is for lack of certainty about the handling of metadata for newly generated image (embedded or XMP). An example would be welcome if someone has done this. :) I don't see the relevance of libheif given it's primarily for HEIF and AVIF formats?