v0.51 crc32 checksum fail

[pim]

Hi.
When merging old picture collections I found two different pictures with same crc32 according to XnView:



Other crc32 tools show more believable values:

Code: Select all

[nabuko@nabuko cksum]$ cksum 183-8385_IMG.JPG 
323455275 433352 183-8385_IMG.JPG
[nabuko@nabuko cksum]$ cksum 184-8419_IMG.JPG 
315802252 743109 184-8419_IMG.JPG

Do you want to check original pictures?

[xnview]

yes please send me the pictures?

[pim]

Here it is:
183-8385_IMG.JPG
184-8419_IMG.JPG

[xnview]

ok, thanks. Strange i have not same crc32 on windows, and which settings do you have for a result with these 2 pictures?
There aren't similar...

[pim]

Lets compare if we have identical files also by another tool:

Code: Select all

[nabuko@nabuko XnMP]$ md5sum 183-8385_IMG.JPG 
169fb6fba4638aa10e05f78b0c5b4581  183-8385_IMG.JPG
[nabuko@nabuko XnMP]$ md5sum 184-8419_IMG.JPG 
58ec190b6fb4b241cfafdeafcdb0ce72  184-8419_IMG.JPG

I'm getting the same result with default settings:

Code: Select all

[nabuko@nabuko XnMP]$ mv ~/.xnviewmp/ ~/.xnviewmp_bck
[nabuko@nabuko XnMP]$ xnviewmp

I just checked "Same file data" in "Search similar files" dialog. Nothing else.

And here is extract from terminal output since comparison starts:

Code: Select all

...

### ThumbLoaderThread :: stop() ok
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
### MyBitmapView (35cf8a0) :: resizeEvent 244 64
### MyBitmapView (357da40) :: resizeEvent 244 64
LOAD BITMAP <//media/truecrypt1/PROGRAMY/Dropbox/Public/XnMP/184-8419_IMG.JPG>
GFF :: LoadThumbnail : 0 
LOAD BITMAP <//media/truecrypt1/PROGRAMY/Dropbox/Public/XnMP/183-8385_IMG.JPG>
GFF :: LoadThumbnail : 0 
=> 0 1 b4002e90 (0)
###### LOAD BITMAP </media/truecrypt1/PROGRAMY/Dropbox/Public/XnMP/184-8419_IMG.JPG>
### resetViewport (35cf8a0)  ==> 244 64  (85 64) 0 0
### resetViewport (35cf8a0)  ==> 244 64  (85 64) 0 0
###### LOAD BITMAP </media/truecrypt1/PROGRAMY/Dropbox/Public/XnMP/183-8385_IMG.JPG>
### resetViewport (357da40)  ==> 244 64  (48 64) 0 0
### resetViewport (357da40)  ==> 244 64  (48 64) 0 0
### MyBitmapView (357da40) :: resizeEvent 330 64
### resetViewport (357da40)  ==> 330 64  (48 64) 0 0
### MyBitmapView (35cf8a0) :: resizeEvent 330 64
### resetViewport (35cf8a0)  ==> 330 64  (85 64) 0 0
QSettings::endGroup: No matching beginGroup()
ThumbLoaderThread :: stop()
### ThumbLoaderThread :: stop() ok

...

[xnview]

Very strange, i've tested on windows and linux, and i don't have same crc with similar dialog

[pim]

It is...
Have you tried both 32 bit or 64 bit version?
What crc32 checksums are you getting?

Setup in english: Initial settings, select dir, open dialog and select Method. Nothing else.

[xnview]

Ok, with same file data, the crc is not computed!

[xnview]

Ok, i've tried with other tool, and the crc32 is the same for these 2 files

[pim]

Today I checked those files at different computer with different OS under different XnView version but with the same result: v0.53
CRC32 checksum tool integrated into TotalCommander gives also same values (while in hexa):

Code: Select all

; Generated by WIN-SFV32 v1.0
; (Compatible: Total Commander 8.01)
183-8385_IMG.JPG B700F1BB
184-8419_IMG.JPG B700F1BB

Seems like it's time for another checksum method:-)
But at least you know it's not bug in your implementation but rather design flaw in crc32.