JPEG XL: --brotli_effort Option

Ideas for improvements and requests for new features in XnView MP

Moderators: helmut, XnTriq, xnview

abobong
Posts: 49
Joined: Tue Mar 01, 2016 5:56 am

JPEG XL: --brotli_effort Option

Post by abobong »

JPEG XL needs [--brotli_effort=] setting to reach its full potential. With proper settings, it can outperform WebP in both compression ratio and speed.
Without it, even with -e 9 option (the current maximum setting), the compression ratio of monotonous images may fall below WebP.

Reference value: -q 100 -e 7 --brotli_effort=10 -j 0

Practical value range: 0-10. [--brotli_effort=]

"Comparison images: .zip attached."
You do not have the required permissions to view the files attached to this post.
Kadet
Posts: 203
Joined: Thu Oct 20, 2022 7:23 pm

Re: JPEG XL: --brotli_effort Option

Post by Kadet »

Adding progressive option will be nice too.
"Comparison images: .zip attached."
I don't understand. Is this a white card on the original?
In XNV, I can compress it in JXL to 145 bytes - with no meta data, because they occupy about 6 KB.
In your case, the different in jxl files are the meta data, not brotlii option.
abobong
Posts: 49
Joined: Tue Mar 01, 2016 5:56 am

Re: JPEG XL: --brotli_effort Option

Post by abobong »

"strip=exif,xmp,jumbf [strip=all], right. It's more effective to eliminate metadata than to compress the metadata box.

Progressive settings might be useful when aiming for JPEG's applications. I've been removing JPEG's progressive functionality, so I've only now realized its usefulness. The fact that there are people who say it's necessary and others who haven't found a need for it suggests it should probably be implemented.

I've recreated the tests due to initial flaws. After re-measurement, I found that JPEG XL's -e 6 had almost the same speed as WebP's maximum compression, so I re-measured the scores.

'maximum comp.webp' is WebP's maximum compression using libwebp.

'-e 9.jxl' is the maximum compression setting for XMP in XnView MP.

'-e 7.jxl' is an attempt to speed up by lowering the EFFORT value to 7.

sample-image cat-image
__________________________________________________________
original | 28.8kb[jpg] | 1.26mb[png] |
maximum comp.webp | 3.25kb | 958kb |
-e 9.jxl (XnView MP max) | 1.48kb | 917kb |
-e 7.jxl | 2.16kb | 927kb |
-e 6.jxl | 2.16kb | 940kb |
-e 9 strip=all.jxl | 1.47kb | 917kb |
-e 6 --brotli_effort=10.jxl | 2.14kb | 917kb |
-e 6 --b_e=10.strip=all.jxl* | 1.47kb | 917kb |
-e 7 --brotli_effort=10.jxl | 2.14kb | 927kb |
__________________________________________________________
* [strip=exif,xmp,jumbf] is represented as strip=all, b_e=10 means [--brotli_effort=10]
It seems that only the -e option directly affects the scores. [--brotli_effort=] and [strip=all] did not affect the actual measurements. The reason for the change in opinion is that I mistakenly used incorrect data as a reference. (It might be obvious if you think about it, but it's also true that you don't know until you try.)

It's worth noting that even when the lossless compression rate is reduced to -e 6, the scores are better than WebP's maximum compression rate. During re-measurement, I added -e 6 because it felt close to the speed of WebP's maximum compression.

There might be a certain number of people who want the ability to remove metadata. I'd also like someone to test Modular mode and VarDCT mode.

Resolved issue: [--brotli_effort=] does not significantly affect the compression rate, so it's not necessary now.

Issues:

Feasibility of the function to remove metadata
Discussion on whether progressive settings are necessary
In addition, enhancement of functions in anticipation of settings during non-compressible times
Re-measured samples are attached, though I don't think there's demand. Only the original 'cat' is attached because it's bulky."
You do not have the required permissions to view the files attached to this post.
simon
Posts: 89
Joined: Wed Aug 23, 2006 4:51 pm

Re: JPEG XL: --brotli_effort Option

Post by simon »

Sorry, I don't understand the point: the range of brotli_effort is 0 .. 11. When non specified, brotli_effort takes the default value 9, which is an already high value, so there is no so much room for better compression (at the price of a slower process)
abobong
Posts: 49
Joined: Tue Mar 01, 2016 5:56 am

Re: JPEG XL: --brotli_effort Option

Post by abobong »

The expectation was that combining a compression level of -e 6 or higher with the --brotli_effort= option would provide a balanced improvement in both compression speed and ratio. However, after re-measurement due to a discovered error, the improvement was only in the range of kilobytes.

Instead, we discovered a bug due to data inconsistencies.
viewtopic.php?t=48742

Issues:
I have never successfully processed anything with --brotli_effort=11.

Personal Opinions:
I also use -e 9.
In about 5 years, -e 10 may be able to be used.
At that time, I think it would be good to ask them to add -e 10 again.