Computer vision and similarity

SSCD, perceptual hashing and Hamming distance in practical image comparison

Different similarity methods answer different questions. A dependable system combines calibrated signals, versioned features and a review process for uncertain matches.

“Similar” needs a business definition

Two files can represent the same underlying image after resizing, recompression, colour adjustment, cropping, added text or a screenshot. Conversely, visually similar products or repeated layouts may look close while representing different content.

The intended action determines the useful definition. Duplicate storage cleanup, copyright review, catalogue deduplication and near-identical frame detection have different tolerance for false positives and false negatives.

A technical threshold is therefore not the starting point. The starting point is a labelled set of examples and the operational consequence of an incorrect match.

Cryptographic and perceptual hashes serve different purposes

A cryptographic hash changes when any byte changes. It is excellent for exact file identity and integrity, but two differently compressed copies of the same photograph will not match.

Perceptual hashes reduce an image to a compact representation of visual structure. The Hamming distance between two binary hashes counts differing bits. A small distance often indicates similar structure, but sensitivity depends on algorithm, preprocessing and image content.

Where perceptual hashes are useful

  • Fast candidate retrieval from a large collection
  • Detection of resized or mildly recompressed copies
  • A cheap first stage before a heavier model
  • Clustering repeated templates or near-identical frames

Where they can struggle

  • Large crops or changed composition
  • Text overlays and borders
  • Very uniform or repeated visual patterns
  • Semantically related but structurally different images

SSCD embeddings represent richer visual features

Self-Supervised Copy Detection produces an embedding vector rather than a short binary hash. Similarity is commonly measured with a vector metric such as cosine similarity after the expected normalisation. The representation can be more tolerant of transformations relevant to copy detection.

The stronger representation has operational cost. Model inference requires more compute, embeddings need storage and nearest-neighbour search requires an index or candidate strategy. Model and preprocessing versions must be recorded because feature vectors from different pipelines may not be comparable.

Use a staged comparison pipeline

A practical system can avoid comparing every image with every other image. Exact hashes remove identical files first. Metadata and perceptual hashes provide inexpensive candidate filtering. SSCD or another embedding model then ranks the reduced candidate set.

The final stage may use geometric verification, crop checks or human review depending on the consequence of a match. The stages should preserve their individual scores; reducing everything to one unexplained number makes later calibration and debugging difficult.

A staged image-comparison pipeline
Exact hashPerceptual candidatesSSCD similarityRule combinationReview or action

Each stage is versioned and retains the evidence used for the decision.

Calibrate thresholds on representative data

A threshold copied from a demonstration dataset may fail on the production collection. Logos, screenshots, product photos, illustrations and user-generated images have different similarity distributions.

Calibration uses labelled positive and negative pairs that include difficult cases. Precision and recall should be measured at the operating point, but aggregate metrics are not enough. False positives with high business cost deserve separate analysis.

Two thresholds can create a useful review band: scores above the higher threshold can be handled automatically where the risk permits, scores below the lower threshold can be rejected, and uncertain cases can be reviewed.

Data that improves calibration

  • Recompression and format changes
  • Common resize ratios
  • Crops and aspect-ratio changes
  • Text, watermark and border overlays
  • Visually repetitive but unrelated images
  • Known hard positives and hard negatives

Preserve preprocessing and model provenance

Orientation correction, colour conversion, resizing and crop policy affect the resulting hash or embedding. Those steps need a named processing version alongside the model and feature vector.

When a model changes, existing vectors should not silently be compared with new ones. A migration can reprocess the collection in batches while the system keeps both versions explicit. Search and decision records should state which version produced each score.

Design the review and correction loop

An operator reviewing a possible match needs the compared images, transformation context, individual scores, decision rule and relevant history. A bare “94% similar” label is insufficient evidence.

Confirmed and rejected pairs can improve later calibration, but only when labels retain their business context. A pair rejected for automatic enforcement may still be useful for discovery. Review outcomes should not be fed back as universal ground truth without qualification.

Monitor drift and operational quality

The input collection changes over time. A new image source, new watermark style or change in typical resolution can shift score distributions. Monitoring should include review volume, confirmation rate, score bands, processing failures and latency by model version.

Regular sampling of automated decisions helps detect drift before it becomes a large quality problem. The system should support reprocessing a bounded cohort rather than requiring a full collection rebuild for every experiment.

Need image comparison inside an operational system?

We can connect inference, feature storage, threshold logic, review state and scalable processing into a traceable application.

Discuss the technical architecture