[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: koffice/libs/flake
From:       Jan Hambrecht <jaham () gmx ! net>
Date:       2009-11-19 10:15:30
Message-ID: 4B051AC2.5040001 () gmx ! net
[Download RAW message or body]

Ariya Hidayat wrote:
>> I had again a look at the code and the part that Thomas thinks is expensive
>> was already used in the old code for big images. The difference is that it is
>> now also used for small images where this should not be a problem. Also it is
>> better memory wise to have no duplicate images. Therefore a small overhead
>> when the image is create can be excepted in my opinion.
> 
> I do not fully understand the said problem and the proposed solution,
> but may I give a suggestion anyway?
> 
> Instead of taking the cryptographic hash of the whole image (converted
> to PNG), how about having a complementary "quick hash" version as
> well? This hash value is calculated from e.g. N first RGBA (int32)
> values of the image data, whereas N is a small number, e.g. 32 or 64.
> If the quick hashes are different, then we can be sure that the images
> are not the same at all, and this is only at the small cost of the
> performance (speed). If the quick hashes are the same, more checks
> need to be done and this is the case (hopefully rare) where we will be
> "hit".
> 
> Of course, to avoid the (hopefully still rare) case where two images
> are different yet the first few pixels are the same (e.g. a logo with
> a large transparent border area) and thus yields the quick hash miss,
> you can vary "N first RGBA values" to .e.g "N first prime-number
> indexed RGBA values", i.e. calculated from the 2nd, 3th, 5th, 7th
> pixels, and so on.
> 
> My apology if this idea is completely non-sense.
> 
> 
> Regards,
> 
> 

I think we want to avoid false positive at all times for this, so we do 
not accidentaly "merge" slightly different images.
I am not sure why the image is saved to a byte array just to calculate 
the hash, as the QCryptographicHash also has a method QCryptographicHash 
addData ( const char * data, int length ). So we would be able to 
directly work on the image data to calculate the hash. Or is there 
anything i missed?

Ciao Jan

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]