Bug 474862

Attatchment was too big (6.11MB). Its here:
https://www.sendspace.com/file/52ugb2

Created attachment 161863 [details]
both version

(In reply to John from comment #1)
> Attatchment was too big (6.11MB). Its here:
> https://www.sendspace.com/file/52ugb2

By mistake there was one big PNG inside that I missed to remove. Now the attatchment is below the limit. Added.

Comment on attachment 161863 [details]
both version

please do a blind test and then decide. Also browse big default PNGs (using arrows) with Gwenview and compare to the speed of browsing compressed wallpapers.

Since you've already done the work, would you care to submit a merge request with your changes so you can be properly credited for it? It would also be helpful if you described what you did so we can replicate this ourselves for future wallpapers. Thanks!

Few thoughts:

Ver1 has larger files than Ver2, I assume that Ver1 should be higher quality setting than Ver2.

However, for these type of artificial images, AVIF compression works very well. I have a subjective feeling that Ver2 looks slightly better than Ver1.

Performance on my computer is very good, size reduction is excellent.
for example 5120x2880-Altai.avif takes 28 ms to decode in Ver1 set and 26 ms in Ver2. Same picture in PNG format takes 106 ms to open.

AVIF compression used here is mathematically lossy, it would be good to keep original PNGs somewhere too, so that the small AVIF files could be regenerated in the future using future encoders.

One thing to consider is that AVIF support is optional in kimageformats so it may happen that it is not available everywhere. Many distros have the support enabled today but there could be some exceptions.

Side note:
GNOME team wanted to use for wallpapers another new-good image format JPEG XL (JXL) but they reverted the decision because of the few minor issues related to libjxl repo, and probably will try again after new libjxl release.

Not really. I did it on purpose not to reaveal anything for blind test. One is (among other parameters) "max/slowest" (see "s" parameter) and the other is one step above the default (after me checking gain vs speed curve chart in documentation). Both are different implementations.

One implementation when it comes to "tiles" (my experiments), might behave better than the other (it sees "the tiles" which I created in gimp manipulating a photo. It doesnt change within the tile, but "from title to tile" <--- larger identical surface). The other is also very good with newer versions, but "max" ("s") is slow as hell. Some gain would be there in size, but the trade-off vs speed is huge. You have to have NASA supercomputer speed (curve goes up a lot).

Another optimisations are advanced quantitisations mode turn off (if it works, not applicable for loosless, loseless is not great here, besides if you zoom those pngs to pixels there's like zero difference, so q-100 makes no sense). In other places some color profile is broken non-standard, some color profiles are very bad to compress, always full range search, 444 colors, instead of 422, enabled chroma in delta planes, and in one version its tuned not with psnr, but with better ssim, sharp color transitions and bias towards sharpness. In other I let great internals to work.

P.S. cjxl for photos with jpg is by default loseless, (revereable). There were a few .jpgs in the wallpaper folder.

I meant: 'advanced quantitisations mode turn ON"

*** Bug 484317 has been marked as a duplicate of this bug. ***

Doing this is probably a good idea, but I think someone who really cares about it and has relevant expertise would have to spearhead the project.