The mechanism's safety implications are well understood by the authors as evidenced by issue tracker discussions.

The implementation calculates the blockhash over an image as advertised, and
passed a comparison test with the Python implementation at
https://github.com/commonsmachinery/blockhash-python.

The blockhash function itself is pretty basic; its website at
http://blockhash.io/ its goals compared to more complex alternatives like
pHash or imgSeek.

The implementation calculates the blockhash over an image as advertised, and
passed a comparison test with the Python implementation at
https://github.com/commonsmachinery/blockhash-python.

The blockhash function itself is pretty basic; its website at
http://blockhash.io/ its goals compared to more complex alternatives like
pHash or imgSeek.

There was little delta to the 1.3.2 version, but that was checked thoroughly.

Straightforward macro-only crate.

Own-crate review. Does what it says on the packaging, in regular use by other own crates.

Own-crate review. Does what it says on the packaging, in regular use by other own crates.

This crate is simple enough that I don't see how anything could go really
wrong here, and might easily be final with its 1.0.1 version unless new
features are added or the rules changed. No claims are made about the
conversion results being suitable for any application (eg. as identifiers).

Flexible implementation of perceptual hashes, with enough configurability to
try out their combinations.

Changes since 0.1.2 were largely cosmetic.

The crate is compact and straight-forward. It is refreshingly unopinionated
in that it leaves it up to the user to pick what to escape; consequently,
there was little to check against RFC3986 other than that the default
uppercasing rule is followed. A minor issue about unsafe code was found and
reported (https://github.com/servo/rust-url/pull/583), but it's more
theoretical then likely to cause practical trouble.

Own-crate review. Does what it says on the packaging. Not safe in a 'safe to
use' sense, but then again this is not to be expected from a -sys crate (all
functions are declared unsafe).

Own-crate review. Mixed quality; some older interfaces are built on a flawed
understanding of Pin and are not fully safe; these are being worked on.

Simple encapsulation of the unsafeness of setting a static variable only once and using that value as &'static from there on. Less automatic than lazy_static.

Simple encapsulation of the unsafeness of setting a static variable only once and using that value as &'static from there on. Less automatic than lazy_static. More focused on the no_std (and possibly atomic polyfilling) use case than once_cell, which otherwise provides a more comprehensive feature set.

The unsafes all look good and are not trivial to replace (tried the ASCII
string composition, but the compiler can't optimize away from_utf8's error
by seeing through into the possible random values.

Average understanding is medium, I don't know the APIs underlying the Windows
implementation.

Focus points of the review were the custom build script (which looks
perfectly reasonable), and the unsafe parts (which are to get instances of
the anyway-ZST types, and are in the process of being removed).

Own-crate review. Has been in "just works" mode for quite some time.