All hash-based algorithms—aHash, dHash, BlockHash, pHash, and wHash—share a fundamental limitation: they compare the whole image as a fixed grid. Rotate an image 90° and every cell in the grid shifts. The hash changes completely, and no hash algorithm will find the match at any threshold.
That’s where ORB (Feature Matching) comes in. Instead of a global hash, ORB detects hundreds of individual visual landmarks—corners, edges, and blobs—and computes a compact descriptor for each one. Two images are compared by matching these landmarks spatially using Hamming distance plus Lowe’s ratio test. A rotated image has the same landmarks in different positions, but each descriptor is still recognisable and matchable.
For rotated, cropped, perspective‑warped, or mirrored copies, ORB is the only algorithm that works.
What makes ORB different from hash-based algorithms?
All hash algorithms encode the whole image as one unit. They produce a single hash that represents the entire image’s structure. This is fast and reliable for normal copies, but breaks completely under rotation or cropping.
ORB takes a fundamentally different approach:
| Hash Algorithms (aHash, pHash, dHash, wHash, BlockHash) | ORB | |
|---|---|---|
| What it encodes | One global fingerprint per image | Hundreds of local feature descriptors per image |
| How it compares | XOR + popcount (one operation) | Match each feature against all features in the other file |
| Rotation handling | ❌ Fails completely | ✅ Works at any angle |
| Cropping handling | ❌ Fails if >30% removed | ✅ Works if keypoints remain |
| Perspective handling | ❌ Fails | ✅ Works for moderate angles |
| Speed | Very fast (nanoseconds per comparison) | Slow (microseconds per comparison) |
The key insight: ORB doesn’t care where in the image a keypoint appears. It only cares that the same keypoint exists in both files. A rotated image has the same keypoints in different positions, but each keypoint’s descriptor is computed relative to its own local orientation—so the descriptors remain consistent regardless of rotation angle.
How the algorithm works: a deep dive
Let’s walk through exactly what happens when you scan a folder with ORB.
Step 1: Load OpenCV.js
OpenCV.js is a WebAssembly‑compiled version of OpenCV. It runs entirely in your browser and loads automatically when the page opens. This happens once on first page load and is cached for all subsequent visits. If it hasn’t finished loading when you click Select Folder, the scanner shows a toast and waits up to 10 seconds.
Step 2: Video frame extraction (for video files)
For video files, Sakarto extracts 3 frames at regular intervals. ORB keypoint detection runs on each frame and the frame with the most detected keypoints is selected as the representative for that video. This maximises match quality since feature‑rich frames give more reliable descriptors than dark or blurry ones.
Step 3: Resize and convert to grayscale
Each image (or selected video frame) is resized to 320×320 pixels and converted to grayscale using the standard luminance formula: Gray = 0.299 × Red + 0.587 × Green + 0.114 × Blue
Feature detection works on intensity gradients—colour adds complexity without improving keypoint quality.
Step 4: Detect keypoints with Oriented FAST
FAST (Features from Accelerated Segment Test) scans the image for pixels that are significantly brighter or darker than surrounding pixels—these are corners and edge junctions. ORB then computes a dominant orientation for each detected corner based on the local intensity centroid. This orientation is what makes ORB rotation‑invariant: every feature knows which way it’s pointing.
Step 5: Compute Rotated BRIEF descriptors
For each keypoint, BRIEF (Binary Robust Independent Elementary Features) computes a 256‑bit binary descriptor by comparing brightness pairs within the local patch. ORB rotates the sampling pattern to align with the keypoint’s orientation, making descriptors consistent even if the image is rotated.
Step 6: Match descriptors using Hamming distance
To compare two files, for each descriptor in file A, the closest descriptor in file B is found using Hamming distance. A match is “good” if the distance is 40 or less. The total count of good matches is the similarity score used for grouping.
Step 7: Lowe’s ratio test
For each keypoint, the best match and the second‑best match are compared. If the best match is not significantly better than the second‑best (if best/second > 0.75), the keypoint is ambiguous and rejected. This dramatically reduces false matches.
Step 8: Aspect‑ratio pre‑check
Before feature extraction, Sakarto checks that the two files have similar aspect ratios. Pairs differing by more than 10% are skipped—comparing a tall portrait to a wide landscape is unlikely to yield meaningful matches.
What ORB finds well
| Type of duplicate | How well it works | Why |
|---|---|---|
| Rotated copies (any angle) | ✅ Excellent | Orientation‑normalised descriptors make rotation invisible. |
| Mirrored copies | ✅ Excellent | Descriptors are computed on local patterns, not global position. |
| Heavily cropped copies | ✅ Very Good | Only needs shared keypoints; cropping removes some but not all. |
| Scanned documents photographed at an angle | ✅ Very Good | Perspective distortion changes position but not local patterns. |
| Perspective‑warped images | ✅ Good | Moderate perspective changes preserve local descriptor patterns. |
| Slightly resized versions | ✅ Good | Descriptor resolution is 320×320; small resizing works. |
| Minor brightness or colour adjustments | ✅ Good | Grayscale conversion and local patterns are robust to lighting changes. |
| Videos with visually similar frames | ✅ Good | Best‑keypoint frame selection works well. |
| Images with very few features (plain skies, solid colours) | ⚠️ May struggle | Few keypoints = few matches. Use hash algorithms instead. |
| Cartoon or heavily stylised art | ⚠️ May struggle | Few corners and edges = few keypoints. |
| Strongly blurred images | ⚠️ May struggle | Blur destroys edge keypoints. |
| Extremely aggressive JPEG re‑compression | ⚠️ May struggle | Compression can destroy the local patterns BRIEF relies on. |
Understanding the similarity threshold slider
The Similarity Threshold slider controls the minimum number of good feature matches required for two files to be grouped as duplicates. Important: ORB’s threshold direction is the opposite of all hash‑based algorithms. A higher value requires more matching features and is therefore stricter.
| Threshold range | What it does | When to use |
|---|---|---|
| 30–50 (Very strict) | Requires many good feature matches. Only near‑identical files or very lightly transformed copies will match. | Use when you want high confidence and very few false positives. |
| 15–25 (Balanced) | A reasonable number of feature matches required. Catches rotated copies, perspective‑warped images, and video frame matches. | Default and recommended. Good starting point for most use cases. |
| 5–10 (Loose) | Only a few matching features required. Catches very heavily cropped copies but more false positives. | Use when you expect heavily cropped copies where many original keypoints are out of frame. |
Tip: Start at 15. If you’re missing duplicates you know exist, lower the threshold. If you’re getting too many false positives, raise it.
How to use ORB: step by step
Step 1: Wait for OpenCV.js to load
OpenCV.js loads in the background when the page opens. If you click Select Folder while it’s loading, the scanner shows a toast and waits up to 10 seconds. It’s cached after the first visit so subsequent loads are instant.
Step 2: Select a folder to scan
Click 📁 Select Folder to Scan or drag and drop a folder onto the page. Supported formats: JPEG, PNG, GIF, WebP, BMP (images) and MP4, WebM, MOV (videos). Files over 40 MB are skipped.
Tip: ORB is significantly slower than hash algorithms. For large folders, scan a targeted subfolder or run a hash algorithm first to narrow candidates, then use ORB on those batches.
Step 3: Wait for the scan to run
A progress bar shows how many files have been processed. Duplicate groups appear live as they’re found. Image processing continues in the background even if you switch tabs. Video processing pauses when you leave the tab and resumes when you return (browser limitation). Click Stop Scan at any time—results so far remain visible.
Step 4: Adjust the similarity threshold
Use the Similarity Threshold slider to tune groupings. Remember: for ORB, higher = stricter. The slider debounces for 3 seconds then re‑clusters in a background Worker—no re‑scan needed. Raise to reduce false positives; lower to catch more matches.
Step 5: Review the duplicate groups
Results are shown in numbered groups. Each group contains files that look similar to each other.
- Click a card to select it (blue border)
- Ctrl+Click (Cmd on Mac) to add to the compare list (purple border)
- Click the 🔍 icon on hover to preview full size
- Right‑click any card for the context menu
- Click & drag on empty space to box‑select multiple cards
Step 6: Compare side‑by‑side
Ctrl+Click two or more cards, then click ⚖️ Compare in the toolbar. A modal opens showing both files at full size with metadata and a similarity percentage. Always compare before deleting—rotated matches can look less obviously related at thumbnail size.
Step 7: Take action—Move, Delete, or Copy
Select files and use the toolbar buttons. With Queue Mode on (recommended), files are staged for review first:
- 📋 Copy — copy filename(s) to clipboard
- 📂 Move — stage for move to a named folder
- 🗑️ Delete — stage for permanent deletion
- ⚖️ Compare — view selected files side‑by‑side
Warning: Deletions are permanent. The File System Access API bypasses the recycle bin. Always use Queue Mode and preview before deleting—especially important with ORB since rotated matches can look less obviously related at thumbnail size.
Step 8: Execute queued actions
Switch to the Move Queue or Delete Queue tab in the sidebar to review staged files, remove any you changed your mind about, then execute when ready.
When to use ORB vs. the other 6 algorithms
Sakarto gives you seven visual algorithms for a reason—each one handles a different type of duplication problem. Here’s when to pick ORB over the others:
Color Signature — colour accuracy
Color Signature is the only algorithm that compares actual colour.
Use ORB instead: Your copies have been rotated, cropped, or perspective‑warped. Color Signature is position‑sensitive—a rotated copy’s colour grid shifts completely.
aHash (Average Hash) — speed above all else
aHash is the fastest algorithm—it reads individual pixels and compares them to the overall mean.
Use ORB instead: Your copies have been rotated or cropped. aHash fails completely on rotation because the 16×16 grid shifts.
BlockHash — noise tolerance
BlockHash averages brightness over blocks, making it tolerant of compression noise.
Use ORB instead: Your copies have been rotated or cropped. BlockHash fails on rotation because blocks shift.
dHash (Difference Hash) — brightness and exposure-adjusted copies
dHash encodes gradient directions and handles exposure shifts well.
Use ORB instead: Your copies have been rotated or cropped. dHash fails on rotation because gradient directions shift.
pHash (Perceptual Hash) — format conversions and watermarks
pHash uses the Discrete Cosine Transform to extract low‑frequency structural data—the most precise hash algorithm.
Use ORB instead: Your copies have been rotated or cropped. pHash fails on rotation because the DCT coefficients shift.
wHash (Wavelet Hash) — speed and quality balance
wHash uses the Haar Wavelet Transform—similar quality to pHash at lower CPU cost.
Use ORB instead: Your copies have been rotated or cropped. wHash fails on rotation because wavelet coefficients shift.
ORB — geometry specialist
ORB is the only algorithm that handles rotation, cropping, and perspective distortion. Use it when hash algorithms fail.
Use ORB when: Your copies have been rotated, mirrored, cropped, or photographed from an angle. It’s the only option for these cases.
Algorithm quick reference
| Algorithm | Best for | Colour‑aware? | Handles rotation? | Handles cropping? | Handles perspective? | Speed |
|---|---|---|---|---|---|---|
| Color Signature | Same colour palette, social media re‑uploads | ✅ Yes | ❌ No | ❌ No | ❌ No | Fast |
| aHash | Large folders, speed priority | ❌ No | ❌ No | ❌ No | ❌ No | Fastest |
| BlockHash | Heavily compressed JPEGs, noisy images | ❌ No | ❌ No | ❌ No | ❌ No | Very Fast |
| dHash | Brightness/exposure‑adjusted copies | ❌ No | ❌ No | ❌ No | ❌ No | Very Fast |
| pHash | Format conversions, watermarks, precision | ❌ No | ❌ No | ❌ No | ❌ No | Fast |
| wHash | Speed + quality balance | ❌ No | ❌ No | ❌ No | ❌ No | Fast |
| ORB | Rotated, cropped, perspective‑warped | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | Slower |
Privacy: your files never leave your device
Like every Sakarto tool, the ORB duplicate finder runs entirely in your browser:
- Zero network activity after page load. All feature extraction and matching runs locally via WebAssembly. No file data is ever transmitted.
- OpenCV runs entirely client‑side. The WebAssembly module processes files locally. No image or video data reaches any server at any point.
- No accounts, no cookies, no analytics. The only localStorage data saved is your checkbox preferences.
- Folder access is scoped and session‑only. Permission lasts only while the tab is open and is revocable from browser site settings.
Frequently asked questions (ORB specific)
“Why use ORB instead of aHash, pHash, dHash, or wHash?”
All hash algorithms (aHash, pHash, dHash, wHash, BlockHash) encode the image as a fixed‑size grid and compare the whole image as one unit. Rotate the image 90° and every cell in the grid shifts—the resulting hash is completely different, and no hash algorithm will find the match at any threshold. ORB works differently: it detects up to 500 individual visual landmarks (keypoints) like corners and blobs, computes a 32‑byte orientation‑normalised descriptor for each, then matches keypoints between images spatially using Hamming distance plus Lowe’s ratio test. A rotated image has the same keypoints in different positions, but each descriptor is still recognisable and matchable. Use ORB when you have rotated, mirrored, perspective‑distorted, or significantly cropped copies that hash algorithms simply cannot find. For standard collections without geometric transformations, hash algorithms are much faster.
”Why is the ORB threshold ‘higher = stricter’ when all other algorithms are ‘lower = stricter’?”
Hash algorithms measure distance (the number of differing bits)—lower distance means more similar, so lower threshold = stricter. ORB measures the count of good keypoint matches—more matching keypoints means more similar, so higher threshold = stricter. For example, a threshold of 30 means “two files must share at least 30 good keypoint matches to be grouped.” Raise the threshold to reduce false positives (require more evidence). Lower it if expected duplicates aren’t appearing (accept fewer matches as sufficient). The scale depends on the images—feature‑rich photos with lots of edges and texture produce hundreds of keypoints, while flat backgrounds produce very few.
”Does ORB work on video files?”
Yes. For each video file, Sakarto extracts 3 frames at regular intervals and runs ORB keypoint detection on each. The frame with the most detected keypoints is selected as the representative frame for that video—maximising the number of potential matches. The rest of the pipeline is identical to images: the selected frame’s descriptors are compared against every other file’s descriptors using Hamming distance and Lowe’s ratio test. Video cards show a 🎬 VIDEO badge. Note that ORB only uses the middle‑area frame, not motion or audio, so two videos are compared purely on visual keypoints from a single extracted frame.
”ORB isn’t finding a rotated or cropped copy I know exists. What should I try?”
First, lower the threshold to accept fewer matching keypoints as sufficient evidence. Second, consider the visual content of the images: ORB keypoints are detected at corners, blobs, and textured regions. Images with large flat areas (plain sky, solid backgrounds, white walls) produce very few keypoints, leaving little for ORB to match. If both the original and the copy are low in visual texture, ORB will struggle regardless of threshold. Third, check whether the copy has been very heavily compressed or significantly blurred—BRIEF descriptors are computed from local pixel patterns, and severe compression or blur can destroy the distinguishing patterns around keypoints. For heavily degraded copies, hash algorithms may actually perform better.
”ORB seems much slower than the hash algorithms. Is that expected?”
Yes, and it’s inherent to the algorithm. Hash algorithms are O(n²) in comparisons but each comparison is a single 64‑bit XOR+popcount operation taking nanoseconds. ORB is O(n²) in comparisons but each comparison involves matching up to 500 32‑byte descriptors between two files using Hamming distance, which is orders of magnitude more expensive. Additionally, OpenCV.js loads as a WebAssembly module (~2‑5 seconds on first use) and keypoint detection itself is more CPU‑intensive than a simple downscale and hash. For large collections, consider scanning a fast hash algorithm first to eliminate obvious duplicates, then using ORB on a smaller subset of suspected rotated or transformed copies.
”What is Lowe’s ratio test, and why does ORB use it?”
When matching a keypoint from image A against all keypoints in image B, the best match is the descriptor with the lowest Hamming distance, and the second‑best match is the next closest. Lowe’s ratio test accepts a match only if the best match is significantly better than the second‑best—specifically, if the best‑match distance divided by the second‑best distance is below 0.75. If the best and second‑best matches are similarly close, the keypoint is ambiguous (appears multiple times in the image) and is rejected. This dramatically reduces false keypoint matches and is the reason ORB can reliably match rotated images without an explosion of spurious pairings.
”Why does video scanning pause when I switch tabs?”
Browsers throttle background video decoding when a tab is hidden. Sakarto detects this and pauses video frame extraction, resuming when you return. Image keypoint detection runs in a background Web Worker (after OpenCV.js initialises) and is not throttled by tab visibility—images continue processing at full speed regardless of which tab is active.
”Can I recover files after deleting them?”
No. The File System Access API’s remove() method permanently deletes files without the OS Recycle Bin or Trash. Queue Mode is on by default: files are staged for review before execution. For ORB results specifically, always use the Compare modal to visually verify matches, since ORB can occasionally match visually distinct images that share strong keypoint patterns (repeated textures, similar architectural elements). Move to a subfolder rather than Delete if you have any doubt.
”What file types are supported?”
Images: JPEG, PNG, GIF, WebP, BMP. Videos: MP4, WebM, MOV (one representative frame extracted and processed with ORB). Files over 40 MB are skipped. HEIC/HEIF, SVG, RAW formats, and TIFF are not supported due to browser decoder limitations. Note that MKV is not listed for ORB video support—the middle‑frame extraction uses an HTML video element which may have more limited codec support than the image pipeline.
”Does this work on Firefox or Safari?”
OpenCV.js loads and runs correctly in Firefox and Safari, so keypoint detection, matching, result display, and the Compare modal all work. Move and Delete are the exception—they require the File System Access API (Chrome 86+ and Edge 86+ only). In other browsers, complete the scan, review and compare results, and use Download List to export a report for manual file management.
Final thoughts
ORB is the specialist. It’s not the algorithm you reach for on every scan—it’s the algorithm you reach for when hash algorithms have failed. For rotated, cropped, perspective‑warped, or mirrored copies, ORB is the only tool that works.
It’s particularly effective for:
- Rotated scans. Photos that were taken sideways and later rotated.
- Cropped images. Versions where a significant portion of the frame has been removed.
- Perspective‑warped photos. Documents or book covers photographed from an angle.
- Mirrored images. Copies that have been flipped horizontally or vertically.
- Video frame matching. The same scene appearing at different times in different video files.
Where ORB falls short—feature‑sparse images (plain skies, solid colours) and very heavily compressed or blurred copies—hash algorithms may actually perform better. ORB needs rich visual detail to produce reliable keypoints.
If you’re working with rotated or cropped images, ORB is the algorithm that finds the duplicates the others miss.
Ready to find rotated and cropped duplicate images and videos?
- Open ORB Duplicate Finder — free, browser‑based, no install
- Try Reverse Image Search with ORB — upload one reference file and find its copies
- Explore All 7 Image & Video Algorithms — compare with Color Signature, aHash, BlockHash, dHash, pHash, and wHash