WebP Compression Error in XnView MP

[abobong]

Required Tools:
The latest version of xnviewmp

xnviewmp 1.5.5 (the xnviewmp.exe file from version 1.5.5 is required)

cwebp.exe (libwebp 1.4.0)

Setup:
Rename xnviewmp.exe from version 1.5.5 to 1.5.5.exe and drop it into the folder of the latest xnviewmp installation.

Configure the batch conversion settings to aim for lossless compression and maximum compression efficiency.

The latest version is here.

Capu001.png (5.95 KiB) Viewed 239 times

Version 1.5.5 is here.
Not retaining metadata will likely lead to more accurate results.

setting.png (6.61 KiB) Viewed 358 times

Place cwebp.exe directly in the root of the C: drive.

Test 1: Comparing File Sizes
Create sample WebP files using both the latest xnviewmp.exe and 1.5.5.exe. Compare the file sizes.

------------------------------original.jpg---buddicat.jpg---(byte)
--------original----------|----29,581----|-------179,093
xnviewmp1.8.6(webp)|-----3,338-----|----1,035,359
xnviewmp1.5.5(webp)|-----3,338-----|----1,033,952



Test 2: Using cwebp.exe

Recreate the conditions using cwebp.exe with the following encoding options:

-lossless -q 100 -m 6 -f 0 -sharpness 0

Note: -o must be manually specified for successful encoding.

------------------------------original.jpg---buddicat.jpg---(byte)
cwebp.exe(webp)-----|--------168----|----1,033,952


Analysis:

Despite using the same settings, cwebp.exe and xnviewmp produce slightly different file sizes:

The file size for original.jpg created by cwebp.exe is significantly smaller (168 bytes). This can be attributed to cwebp.exe discarding EXIF metadata.

For buddicat.jpg, both tools generate files of identical size because no metadata was present in the original image.

Suspicious Compression in xnviewmp 1.8.6:

Compression in xnviewmp 1.8.6 appears abnormally fast and less efficient compared to xnviewmp 1.5.5.

This suggests that the compression ratio may have been improperly lowered in the newer version.

Request for Resolution:
The results strongly indicate that xnviewmp’s WebP compression has become less effective in recent versions (after 1.5.5).

Please investigate and address why the latest xnviewmp versions fail to produce properly compressed WebP files.

Attached to this report are:

The generated WebP files for review.

The tools used (cwebp.exe and xnviewmp executables).

A batch script for reproducing the issue (just drag and drop images into the script).

This problem remained unresolved for several years. I hope this report provides enough evidence for an investigation. If additional information is required, please let me know.

[xnview]

is it possible to send the buddicat.jpg too?

[abobong]

Sorry about that. Resending it now.

[xnview]

XnView use 75 (default) as quality when you use lossless

[abobong]

Thank you for the information. I understand that a default quality of 75 is used during lossless compression.

Additional Test

----------------------------- buddicat.jpg---(byte)
-----------original-------|------179,093
xnviewmp1.8.6(webp)|----1,035,359
cwebp.exe(-q 75)------|----1,035,360

Could this default quality setting be one of the reasons for the issue?

I will continue to cooperate with the investigation.

abobong

[xnview]

no there is a little difference between cwebp and XnView (header size) but i don't understand why. I use same options. I need more investigation

[abobong]

Correction in Measurements and Observations: Upon re-measuring, the file size for xnviewmp1.8.6(webp) should be 1,035,360 instead of 1,035,359. This confirms that xnviewmp1.8.6's lossless setting is fixed at -q 75.

To investigate further, I ran cwebp.exe with the parameters -lossless -m 6 -f 0 -sharpness 0, without specifying -q. Interestingly, the resulting file size matched xnviewmp1.8.6's lossless setting (-q 75). This suggests a potential shift in the lossless configuration:

・For versions up to xnviewmp1.5.5, the lossless setting may have been consistently [-lossless -q 100].

・In xnviewmp1.8.6, the parameter appears to rely only on [-lossless].


Comparison Results for buddicat.jpg and cat2.jpg:

----------------------------- buddicat.jpg---(byte)
-----------original-------|------179,093
xnviewmp1.8.6(webp)|----1,035,360
cwebp.exe(no -q)-----|----1,035,360
cwebp.exe(-q 75)-----|----1,035,360
cwebp.exe(-q 0)------|----1,039,742

----------------------------- cat2.jpg---(byte)
-----------original-------|------255,806
xnviewmp1.8.6(webp)|----1,231,168
cwebp.exe(no -q)------|----1,231,168
cwebp.exe(-q 75)-----|----1,231,168
cwebp.exe(-q 0)------|----1,238,836(*-q 0 was added for verification purposes).

Excerpt of the description for -q float

-q float
Specify the compression factor for RGB channels between 0 and 100. The default is 75.

In case of lossy compression (default), a small factor produces a smaller file with lower quality. Best quality is achieved by using a value of 100.

In case of lossless compression (specified by the -lossless option), a small factor enables faster compression speed, but produces a larger file. Maximum compression is achieved by using a value of 100.

It states here that it can be used for both lossy and lossless compression, and if aiming for maximum compression, you should use -q 100.

Key Points
・If the hypothesis is correct, in version 1.8.6, the lossless parameter might be limited to [-lossless] only.
・To restore the previous setting, it might be necessary to revert to [-lossless -q 100]

All the files for verification are identical.
https://drive.google.com/drive/folders/ ... ZIfkUk9PVA


Through exhaustive file checks I conducted previously, I have identified xnviewmp.exe as the specific file causing this issue. Updating the encoder will not resolve this problem, and this current verification method is designed to demonstrate that.
viewtopic.php?p=197781#p197781