Suggestion to make the result of image comparison more reliable

[Werve]

I am doing a folder comparison with the option for image comparison enabled. (Latest Winmerge stable version)
I noticed that sometimes the reported result of comparing some images indicates different images but if I compare the same files as binary instead they are the same. So I suggest doing a binary comparison first and in case it is really different do a pseudo-visual comparison with the images option.

Also I noticed that sometimes comparing folders with many files and image comparison option enabled, the program crashes (it is not slow, even leaving it open 10+ hours does not increase progress) and having to close it by killing the process.
On the other hand, if you do the partial comparison of each sub-folder (present of the previous folder, the comparison of which crashes) you are able to terminate it correctly.
Is this a RAM memory management problem?

[sdottaka]

It may be similar to the problem of #1176.

Could you tell me if you can get a stable result when the number of comparison threads is 1 as follows?
Also, please let me know if there is any condition that is easy to reproduce.

[Werve]

Ok, I managed to reproduce it again and seems it works with thread = 1 (of course lot slower)

Before:

After:

Maybe is because there is some problem with thread that cant compare the files corrupted (see impossible result in the images)
Also i noticed that there are no similar human comparison algorithm to compare audio files (it use binary compare), maybe should be useful an audio fingerprint comparison? (to have an option similar to visually comparison of images) https://acoustid.org/ merged with information with duration and bitrate to avoid considering compressed and original audio identical (best quality) or write in such cases as a result of comparison "similar files, best quality left/right"

[sdottaka]

Thank you for trying that.

I am unable to reproduce this issue at the moment, so if you could tell me how to easily reproduce it, that would be great!

[Werve]

Happened often with folders having 20000+ files, image comparison enabled and also added pdf extension. (attached the settings file)
With some folders containing corrupted images (resulting in impossible comparison).
I don't think there is anything else in common.

Sorry, if I currently had more time I would prepare a sample folder I had the problem with.

settings.zip

[Werve]

Just a quick update: not always thread =1 fix the problem so now I'm thinking that maybe is related to some antivirus protections.
Or maybe is related to my change of experimental diff engine in Winmerge (Compare - General).
I set it on "minimal" now, I'll update this comment if this fixed it.

[Werve]

I tried on a different PC installing winmerge and with the default settings.
I noticed that the block occurs only after adding the pdf extension in the settings for comparison as an image and enabling the comparison for folders as well and set automatic unpacking on to make that works.
Actually it only works on the x64 version. In the 32-bit version the comparison as images still ignore the pdf type.

[sdottaka]

Thank you for the info.
The 32-bit version of WinMerge does not support image comparison of pdf files due to limitations to support WinXP.

[sdottaka]

I was not able to reproduce the problem of that comparison being blocked, but I was able to reproduce the problem of the same content being determined to be different, even though they are identical.

WinMerge uses a Windows feature (Windows.Data.Pdf) to image PDF files. When PDF files are converted to images using this function, a slight color difference sometimes appears as shown in the attached image.

I do not know why this happens.
As a workaround, select a value such as 16 in the Image → Ignore Color Difference (Color Distance Threshold) menu to ignore slight color differences.

[Werve]

Thanks for the suggestion, I will use that option from now on.

I was able to replicate the block with a random set of created files.
I uploaded the two folders used for comparison and the settings if needed to replicate.
https://gofile.io/d/ky0WVw

[sdottaka]

Thank you for uploading the file.
I'll try it later.

[sdottaka]

There was a memory leak when comparing PDFs, so version 2.16.24 fixes this problem.
I think this fix makes the comparison stuck issue a little better. (It seems that it is not perfect because it has hung once yet)