Bug: "Keep original file when encoded result is larger" may delete your images permanently

[Litr]

Windows 10 x64
Tested on both XnConvert 1.99 x64 and XnViewMP 1.6.3 x64
I post it here, as i use standalone XnConvert way more than similar embedded feature in XnViewMP.

1) My results with "Keep original file when encoded result is larger" are pretty underwhelming... if not say more!

• (XXX to JPEG format conversion) JPG file was converted with a LARGER size (original file should be preserved, as it was smaller)

• (XXX to JPEG format conversion) PNG file was deleted permanently , not even placed in the recycle bin (original file should be preserved, as it was smaller)

• (XXX to JPEG format conversion) AVIF file was deleted permanently , not even placed in the recycle bin (original file should be preserved, as it was smaller)

2) Also i found one tiny flaw in the preset system - if "Keep original file when encoded result is larger" option state (ON or OFF) is not saved in the Preset file (checkFilesize="false" or checkFilesize="true") then it will be used from INI file. So you need to update all your presets if you want to use that option in some, but not all of them.

So in the end, i am glad that i have decided to test it before ughm... actually using and saving some space on my images. It is not like i don't have backups but i may not even notice that something went wrong before i refreshed these backups with these vanished files...

[xnview]

Please post a screenshot of 'Output' tab? Do you have actions? and files to reproduce?

[Litr]

Please post a screenshot of 'Output' tab? Do you have actions? and files to reproduce?

Yes i have actions but they are inactive (0/11 selected) when i test "Keep original file when encoded result is larger".
You can see files in the attachments (both of them) but it is 100% repeatable on my PC, so like any file but a JPG as i described in the first post...

Also, Happy New Year!

[Litr]

Please post a screenshot of 'Output' tab? Do you have actions? and files to reproduce?

Eh, i juts realized that i forgot to post my output tab.

[xnview]

please disable 'preserve extension'?

[snowfl]

please disable 'preserve extension'?

I am also getting this bug, original file size is 745 KB and new one is 2.37 MB and original file is getting deleted.

[xnview]

Thanks to your detailed description I can reproduce the problem.

[xnview]

This problem is supposed to be fixed in XnView MP 1.6.4. Please check and confirm the bug fix here.

[snowfl]

Still not working, i also removed the xnview config ini to make sure nothing carried over from old version.

[xnview]

Still not working, i also removed the xnview config ini to make sure nothing carried over from old version.

The source is always removed?

[snowfl]

Still not working, i also removed the xnview config ini to make sure nothing carried over from old version.

The source is always removed?

Yap it was removed. I downloaded xnview few days ago to reduce the resolution (1920px) of older files, good thing i tested this before using it on the actual files.

Some of these files was downsized to 1920px long time ago so i don't want these files to be modified/deleted but xnview increases its file size and deletes the original.

[xnview]

which action do you have? source file?

[snowfl]

Previous test file is private file so i used another file.


Total input file size: 173.42 KiB
Total output file size: 524.97 KiB
File size ratio: 202%

[Litr]

This problem is supposed to be fixed in XnView MP 1.6.4. Please check and confirm the bug fix here.

Hmm, i tested it again in 1.6.4 and it seems to work fine? I am still a bit scared to use this new function, so i will do more testing later.

I also noticed that processing log will only list correct values if the size goes DOWN (gets smaller), if it goes UP (gets bigger) then you can see only 0% in the log, for example:

556.50 KiB -> 556.50 KiB (0%) bigger file not saved
775.02 KiB -> 726.21 KiB (-6%) smaller file was saved
3.02 MiB -> 1.68 MiB (-44%) smaller file was saved
15.80 MiB -> 6.06 MiB (-61%) smaller file was saved
10.13 KiB -> 10.13 KiB (0%) bigger file not saved

I think we can see only a negative % and 0% because the comparison was done not between the new_temporary_file_that_was_wiped_because_it_was_too_big/original but between original/original twice, as it was preserved and not deleted - so we can only see 0% difference, as in the end these two identical files were compared... It is not critical by any means, just FYI.

Also please update XnConvert if this bug was really smashed!

[Litr]

So i tested it a bit more and it looks like the new feature SOMETIMES does not work if the extension is the same?
i.e. If i have JPGs then it will preserve new bigger files in one case... and wipe them out in other cases.

And for these weird files processing log can actually show positive %
185.99 KiB -> 233.96 KiB (25%) bigger file was saved

I think it has to do something if there is an image with attached color profile and "preserve color profile" feature is ENABLED. So maybe the "Keep original file when encoded result is larger" just does not work if "preserve color profile" in ENABLED?...

Also if you have enabled another small feature "If an output file already exist = Rename" and also have the file with identical name, but different extension before conversion AND IF SIZE GOES BIGGER after conversion, then it will make a copy of an old file (a copy of the different file with with identical name!) and then rename it... instead of wiping out new result file. I cannot explain it better, i am sorry, it is already a bit complicated for me.

TL;DR: Its like a layered pie now. But its tasty!