Hello everybody,

I am currently updating an older plugin (one that is not in the distribution nor in the registry anymore) in order to bring it back to life (and, well, maybe learn something about Gimp programming as well).

The plugin although it worked quite well, seemed never to have been finished.

Now, there is a random function in this plugin, which according to documentation, would require a random number seed that is unique for every image that is going to be processed, i.e. the result of the random function should be identical for any identical image. This, however, has not been implemented as such in the old files.

Now my idea was to use some sort or CRC on the drawable to get a seed for the random number generator, that would match these requirements.

Since I haven't been able to find a function within the libraries that I could use as a starting point (and of course I do not want to re-invent the wheel), my question is, if there is such a function that would provide an identical value for any identical image - or would I have to write a kind of pre-filter in order to generate that value ?

Thank you very much for listening,

Torsten

Hi David,

Since I haven't been able to find a function within the libraries that I could use as a starting point (and of course I do not want to re-invent the wheel), my question is, if there is such a function that would provide an identical value for any identical image - or would I have to write a kind of pre-filter in order to generate that value ?

What you are talking about is a hash function. There is a string hasher in GLib that should do what you want.

Quite so, yes - thank you, I'll try that out.

However, be aware,
the criteria 'a random number seed that is unique for every image that is going to be processed,' cannot be fulfilled in an absolute way. With a hash value of 32bits, that's > 4 billion possible hashes. Practically speaking, you are likely to encounter a hash collision* unless the amount of images in the set you're processing gets very large, you should be aware that it is always possible though.

I am aware of that. The point is, that the function is a random but - according to it's documentation should behave identically for identical images. The idea behind this is, that you should be able to recreate the same effect on the same image - even if there is such a thing called random.

The cheapest possible solution to that would be to use a constant as the random number seed. This, however, would make the random function very predictable, which I feel is horribly wrong - so I'd rather go with a hash which may collide from time to time, yet still will be a good enough seed.

Torsten

Hi Sven,

On Wed, 2008-04-09 at 09:27 +0930, David Gowers wrote:

What you are talking about is a hash function. There is a string hasher in GLib that should do what you want.

The string hash function in GLib is not suitable for this job. Torsten doesn't want to hash a string, he is asking for a checksum over image data.

Yes, I discovered that myself, since the string hasher would have difficulties with handling the binary data of the drawable passed on to the plugin.

You can use GChecksum which was added recently to GLib or you can use the MD5 implementation in libgimpmath.

This sounds nice, but I think it'll also needs something more since the whole image needs to be checksummed. As I see it, I'll probably have to do a checksum on every tile of the drawable and then sum them up again, right ?

Torsten

Am Mittwoch, 9. April 2008 22:05:37 schrieb Sven Neumann:

Hi,

On Wed, 2008-04-09 at 09:27 +0930, David Gowers wrote:

What you are talking about is a hash function. There is a string hasher in GLib that should do what you want.

The string hash function in GLib is not suitable for this job. Torsten doesn't want to hash a string, he is asking for a checksum over image data.

You can use GChecksum which was added recently to GLib or you can use the MD5 implementation in libgimpmath.

Unfortunately, I'm stuck with GLib 2.14 at the moment and the GChecksum is available from 2.16 on only.

Regarding the MD5 implementation in limbgimpmath, it would have been nice if I could use it, but I cannot as I have to produce an MD5 on the whole drawable, which means that I whould have to run gimp_md5_update() on every tile. Yet, gimp_md5_init(), gimp_md5_update(), and gimp_md5_final() are declared as static (why ?), so I will have to use something else.

For now, I will therefore use the OpenSSL implementation of MD5 (also, why isn't limbgimpmath reusing the OpenSSL code for that purpose ? Just a curious question...).

Torsten

Hi Sven,

On Thu, 2008-04-10 at 18:04 +0200, Torsten Neuer wrote:

Regarding the MD5 implementation in limbgimpmath, it would have been nice if I could use it, but I cannot as I have to produce an MD5 on the whole drawable, which means that I whould have to run gimp_md5_update() on every tile.

Not on every tile. You would use gimp_pixel_rgn_register() and gimp_pixel_rgn_process() to iterate over the whole drawable and feed all pixels through the checksum engine.

Hmm... this is what I currently use:

typedef union DIGEST_BUFFER { unsigned char md[EVP_MAX_MD_SIZE]; guint32 val;
} DigestBuffer;

guint32 compute_drawable_checksum( GimpDrawable *drawable ) {
DigestBuffer result;
EVP_MD_CTX checksum;
GimpTile *t;
guint l, r, c;

EVP_DigestInit( &checksum, EVP_md5() );

for( r=drawable->ntile_rows; r--; ) {
for( c=drawable->ntile_cols; c--; ) {
t = gimp_drawable_get_tile(drawable,FALSE,r, c); gimp_tile_ref( t );
EVP_DigestUpdate( &checksum, t->data, t->ewidth * t->eheight * t->bpp ); gimp_tile_unref( t, FALSE );
}
}
EVP_DigestFinal( &checksum, result.md, &l );

return result.val; } /* compute drawable_checksum() */

It seems pretty fast and also seems to work (at least I get the same value for the identical images and different values for different images).

I thought that it was low-level enough not to use pixel_rgn related functions - or am I getting something completely wrong here ?

And yes, I know that I', using only a quarter of the computed MD5 for identifying the drawable, but srandom() can only take so much.

Yet, gimp_md5_init(), gimp_md5_update(), and gimp_md5_final() are declared as static (why ?), so I will have to use something else.

The GIMP MD5 implementation was added specifically for the purpose of implementing the thumbnail spec. We didn't add an all-purpose API simply because there was no need for it.

It would be nice to have these three function to be made public though, since they could really be useful also in other ways, too (digitally fingerprinting images comes to mind).

For now, I will therefore use the OpenSSL implementation of MD5 (also, why isn't limbgimpmath reusing the OpenSSL code for that purpose ? Just a curious question...).

Because that would add a dependency on openssl. In such a case it is a lot simpler to just duplicate the code.

Understandable from that point of view. And given it is only a very small piece of code, the time and effort of making it a configurable item won't justify adding the dependency.

Torsten