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.


Attachment: signature.asc
Description: This is a digitally signed message part.

Gimp-developer mailing list

Reply via email to