All .png KDE wallpapers are way too big in size and hence slow to load. We can improve loading (login screen, lock screen, desktop wallpapere) by properly optimizing all PNG wallpapers. Since kimageformat supports modern compression methods, I read all the documentations, man pages and conducted close to 1000 tests using various methods and advanced options for modern photo/picture/raw data compression. In order to decrease the size of enormous PNGs of KDE wallpapers, I compressed all png wallpapers using all adanced options possible to achieve maximum quality while compressing these pictures. Please conduct blind tests for two versions (see attatchments) and decide which one would you like to include as default KDE wallpapers in the next version of KDE. See how slow all pngs are to browse with Gwenview (put all PNGs in one folder) and how fast are the compressed photos are to browse. BTW you will not see any quality loss doing blind test. 1. Problem: 13Megabytes for a wallpaper/lock/login screen/sddm is way too big. 2. Solution: Very high quality modern compression methods already in attatchments 3. Please update links in the appropriate folders (/usr/share/wallpapers/) to the new compressed ones insead of the big PNGs All Platforms, All Kernels, All OSes All Kernels
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.