All 7 Algorithms — How Reference Search Works
Every algorithm processes your reference first, then scans each folder file and compares it against the reference. Matches appear live. The reference card is always protected at position 0.
Compares actual YUV colour values between your reference and each folder file. The image is divided into a 24×24 regional grid, and the average YUV (luminance + chrominance) value for each cell is computed. Two files match if their total colour distance across all 576 cells is below the threshold. This is the only algorithm that cares about colour — a bright-red reference will never match a bright-blue copy even if their brightness patterns are identical. Finds colour-similar copies even after re-compression or minor edits. Will not match colour-shifted versions of your reference.
Step 1
Process reference to 288×288 YUV gridReference hashed immediately on upload. 576 YUV cells computed.
Step 2
Process each folder file the same wayWeb Worker handles each file. Same 24×24 YUV grid computed per file.
Step 3
Compute total YUV distanceSum of colour differences across all 576 cells. Below threshold = match.
Step 4
Show match liveMatching cards rendered immediately. Reference always stays at position 0.
The fastest reverse image search. Your reference is hashed once (16×16 → grayscale → mean threshold → 256-bit hash). Then each folder file is hashed the same way and compared against the reference using Hamming distance. Because only one O(n) comparison is needed per file, this is significantly faster than the duplicate finder for large folders. Fast Mode reads JPEG EXIF thumbnails instead of full images — 5–10× faster with near-identical accuracy. The reference hash is computed immediately when you upload it, so there's no waiting before scanning begins.
Step 1
Hash reference at uploadReference processed to 256-bit aHash immediately. Preview shown.
Step 2
Hash each folder file16×16 canvas → grayscale → mean → 256-bit hash. Fast Mode uses EXIF thumb.
Step 3
Hamming distance vs referenceCount differing bits. ≤ threshold = match. Aspect-ratio pre-check applied.
Step 4
Live resultsEach match card rendered immediately as found. Reference pinned at position 0.
Divides a 64×64 canvas into 16 equal blocks and averages the brightness of each. Block averaging absorbs individual-pixel noise from JPEG compression, making BlockHash more tolerant of degraded copies than pixel-level methods. Your reference produces a 16-bit block hash; each folder file is hashed the same way and compared using Hamming distance. Excellent for finding heavily compressed or noisy versions of your reference that aHash or pHash might miss because the individual pixels differ too much from compression artifacts.
Step 1
Reference → 64×64 block hash16 blocks, each 16×16 pixels. Block brightness averaged, compared to median → 16-bit hash.
Step 2
Same for each folder fileCompression noise absorbed by block averaging — artifact-tolerant.
Step 3
16-bit Hamming distanceOnly 16 bits to compare — very fast even for huge folders.
Step 4
Live match cardsMatches appear as they're found. Reference always stays pinned first.
Instead of comparing absolute brightness, dHash encodes the direction of brightness change between adjacent pixels. Your reference is resized to 17×16 (one extra column), and 256 pixel pairs are compared left-to-right — each comparison becomes one bit. The key advantage: a copy of your reference that was edited with different brightness/exposure settings will still have the same gradient directions, so it matches even though the absolute pixel values are very different. Best for finding copies of your reference that were saved from different RAW development settings, HDR processing, or exposure correction.
Step 1
Reference → 17×16 gradient hash256 left-right pixel comparisons → 256-bit hash encoding brightness gradients.
Step 2
Same for each folder fileExposure/brightness differences don't change gradient direction — robust to edits.
Step 3
256-bit Hamming distanceCount differing bits. ≤ threshold = match. Aspect-ratio pre-check applied first.
Step 4
Live match cardsReference stays pinned. Matches render immediately as found.
Uses the Discrete Cosine Transform (the same math as JPEG compression) to extract the low-frequency "essence" of each image. Your reference is resized to 32×32, a separable 2D DCT is applied, and the top-left 8×8 block of low-frequency coefficients is thresholded against their mean to produce a 64-bit hash. These low-frequency components are extremely stable — JPEG re-compression, format conversion, mild sharpening, slight colour grading, and watermarking all change high-frequency detail while leaving the low-frequency structure intact. This makes pHash the best all-round choice for finding edited copies of a reference across different formats and export settings.
Step 1
Reference → 32×32 DCT hashSeparable 2D DCT → extract top-left 8×8 low-frequency coefficients → 64-bit hash.
Step 2
Same for each folder fileFormat conversions, mild edits, sharpening don't affect low-frequency structure.
Step 3
64-bit Hamming distanceCount differing bits. ≤ threshold = match. Aspect-ratio check applied first.
Step 4
Live match cardsMatches rendered live. Reference always pinned first, protected from deletion.
Uses the Haar Wavelet Transform at a larger canvas (64×64 for reference search, vs 16×16 in the duplicate finder) for improved accuracy. The wavelet decomposition captures structure at multiple scale levels simultaneously. The top-left 8×8 LL sub-band is extracted and thresholded to produce a 64-bit hash. The larger canvas and multi-scale nature make wHash's reference search particularly good at handling copies where one area of the reference has been locally edited — the unchanged parts still contribute enough to the hash to produce a match. Quality similar to pHash at slightly faster speed.
Step 1
Reference → 64×64 Haar hashMulti-level Haar transform → 8×8 LL sub-band → 64-bit hash. Larger canvas than dup finder.
Step 2
Same for each folder fileMulti-scale capture handles local edits better than single-scale methods.
Step 3
64-bit Hamming distanceCount differing bits vs reference. ≤ threshold = match.
Step 4
Live match cardsReference pinned at position 0. Matches appear as found.
Uses OpenCV.js (WebAssembly) to extract up to 500 distinctive keypoints from your reference and match them against folder files. For the reference search, keypoints are extracted from the reference only once, then matched against each folder file's keypoints using Hamming distance + Lowe's ratio test. ORB is the only algorithm that handles rotation, cropping, and perspective distortion — if your reference has been photographed from an angle, rotated, or heavily cropped, only ORB will find it. For videos, the middle frame is extracted and used for matching. Note: the threshold direction is inverted — higher = stricter (more matching keypoints required).
Step 1
Extract reference keypoints (once)OpenCV detects FAST keypoints + BRIEF descriptors from reference. Stored for all comparisons.
Step 2
Extract folder file keypointsSame process for each folder file. Videos use middle frame.
Step 3
Spatial keypoint matchingHamming distance + Lowe's ratio test. Count of good matches ≥ threshold = match (inverted!).
Step 4
Live match cardsReference stays pinned. Matches rendered as found. ORB is slower — expect longer scan times.
⚠️ ORB threshold is inverted: higher = stricter (more matching keypoints required). Requires OpenCV.js to load (~2–5s on first use). Slower than hash algorithms. Videos use middle frame only for matching.