https://bugs.kde.org/show_bug.cgi?id=466005
kde-bugtrack...@map-of-mind.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|8.0.0 |8.5.0
CC| |KDE-Bugtracking@map-of-mind
| |.net
--- Comment #9 from kde-bugtrack...@map-of-mind.net ---
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?
--
You are receiving this mail because:
You are watching all bug changes.
