Legacy ImageMagick Discussions Archive

Long time user of ImageMagick, first time developing with MagickWand.

I'm getting the hashes of lots of images, but I'm having a problem with multipage images like GIF animations. I just thought that MagickGetImageSignature would compute the hash of all the images in the wand, but it only calculates the current image, which by default is the last frame of the animation. I somewhat fixed a problem with that (some animations have an empty frame at the end, giving out lots of false duplicates), moving the index/iterator to the first image in the wand before getting the hash.

I guess I'll have to resort to some custom processing to get a hash of all the images in the wand, but since I'm very new at using MagickWand, I'm first asking if there's a way to get the hash of all the images in the wand with a different usage of MagickGetImageSignature or a similar function.

If not, I guess I'll make some concoction with the hashes of each image.

Regards, JMM.

MagickGetImageSignature calls SignatureImage which calculates the signature of a single image. I don't think IM has a method for calculating the signature of a combination of images.

Two methods of combining multiple images seem obvious: you could append them, or you could average them.

Thanks for confirming. Although combining the images would be the "right" way to proceed, I didn't want to make any post-processing to the images to save time. Instead, I thought of combining the hashes of each image in some way. In case someone else has the same dilemma, here are my results.

After some research on the world of SHA, message digests, and combining hashes, concatenation is the most obvious and safe way. Safe as in, less amount of collisions, since we're using the hash as identification. When you want to keep the hash size and need to combine somehow, don't use XOR (although in this context it would be presumed to be safe).

There are several formulas for combinations, the one I've chosen due to proven robustness and simplicity is H = (H1*m) + H2 ; the topmost/leftmost bits must be discarded, and m must be prime. In the examples I've read a few people suggest large values, but in fact the most often used and recommended value is 3 for reasons beyond my basic cryptographic knowledge. Since we're using SHA-256, that's 32 bits, so H = (H1*3) + H2) keeping the rightmost, least significant 32 bits.

That seems plausible, though I know almost nothing about SHA etc. Larger values of m will lose more bits from H1. And if there are many images, so many iterations of H = (N[sub]n[/sub]*m)+H[sub]n-1[/sub]), hashes from more of the first few images will be discarded entirely.

I should retract, the formula I gave is good for two hashes, but not for large amounts. Probably by the reason you stated, the more hashes are combined this way, the less bits from the first hash are kept until they disappear. Different values of m depends on what are you doing with the resulting number, if keeping the lowest bits, then m must be low.

So in short, I ended having to concatenate the hashes of each image and then get the SHA-256 of that string. Due to the amazingly huge space of a 256 bit message digest, it'll be good enough.
(Incidentally, plugging in a hash library and getting the SHA is way easier than using a big number library.)

Thanks for your comments.