.webp file size anomaly

[Rava]

The endings of the file names determine what compression I use or if none.

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

unless I am silly here and mistaken and it is part of an updated mtpaint. Then my bad and all that jazz.


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

Image dimension: 531x561 8-bit/color RGB


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

Image dimension: 919 x 937, 8-bit/color RGB

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

Image dimension: 913 x 1025, 8-bit/color RGB


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?