Details:
.webp Compression: Drawing, V8 Save quality 93 (100=high)
_lossless.webp Compression Lossless V8L Compression 9 (0=none)
.png Compression 9 (0=none) [lossless]
The program used is mtPaint, but mtPaint uses the system's ability for file formats, so the actual routine handling webp is not coded into mtPaint but part of my Porteus 5.0 [core modules updated] XFCE 4.16:
Code: Select all
guest@rava:~$ cat /etc/porteus/*
001-core.xzm:20221211
002-xorg.xzm:20221211
002-xtra.xzm:20221211
003-xfce.xzm:20220925
initrd.xz:20220928
Now I use for screenshots that show window contents the Compression: Drawing since most objects are similar to simple drawings.
Most of the time _lossless.webp is the smallest file size, then .png and .webp the largest.
As described above, _lossless.webp and .png both are lossless while .webp is not.
But there was one strange exception. It was a screenshot of the thunars "Configure Columns in the Detailed List View" settings window - a smaller and more simple screenshot than most.
Here the file sizes:
Code: Select all
49528 thunar-4.16.10-config-columns.webp
143922 thunar-4.16.10-config-columns_lossless.webp
188348 thunar-4.16.10-config-columns.png
It is for now the only time the _lossless.webp is much bigger than the .webp .
Usually file sizes are like so - _lossless.webp smallest, .png middle, .webp largest:
Code: Select all
46670 thunar-4.16.10-sorting-bug_lossless.webp
213680 thunar-4.16.10-sorting-bug.png
220934 thunar-4.16.10-sorting-bug.webp
Code: Select all
34610 thunar-4.16.10-sorting-bug2_lossless.webp
208494 thunar-4.16.10-sorting-bug2.png
218884 thunar-4.16.10-sorting-bug2.webp
Any tips why that is? Why is _lossless.webp usually compressed the best even when its lossless, but fails doing so for a relative simple and small screenshot?