The duplicate finder is great when you don’t know what you’re looking for. It scans a folder and automatically groups everything similar. But what if you already know exactly which file you want copies of—and those copies have been rotated, cropped, or photographed from an angle?
That’s where ORB Reverse Search comes in. Instead of grouping everything, you upload one reference file first. Sakarto processes it immediately using OpenCV.js, then scans your chosen folder and returns only the files that look like that specific reference—even if they’ve been rotated, mirrored, cropped, or perspective‑warped. The reference is pinned at the top with a protected badge—it can never be accidentally moved or deleted.
With the ORB (Feature Matching) algorithm, you get the only tool in Sakarto’s toolkit that handles geometric transformations. All hash-based algorithms—aHash, dHash, pHash, wHash, and BlockHash—fail completely on rotated images because the grid shifts. ORB detects individual visual landmarks (keypoints) and compares their spatial arrangement, making rotation invisible to the algorithm.
What makes ORB reverse search different from hash-based algorithms?
All hash-based algorithms encode the whole image as one unit. They produce a single hash that represents the entire image’s structure. 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.
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 reverse search works
The standard Find Duplicate Images & Videos workflow scans a folder and compares every file against every other file. That’s O(n²) complexity—fine for a few hundred images, but it gets slower as the folder grows.
Reverse Search does something much smarter. It extracts features from your reference once, then compares each folder file only against that reference. That’s O(n) complexity—linear scaling. A folder of 10,000 images takes roughly the same time per file as a folder of 100. The scan speed depends only on the number of files, not how many of them are similar to each other.
This makes reverse search the faster choice for large folders where you already know what you’re looking for—even with ORB’s heavier per-file cost.
The reference protection system
The reference file is treated differently from every other file in the scan. When you upload it, Sakarto immediately:
- Extracts ORB keypoints and descriptors using OpenCV.js
- Shows a thumbnail preview so you can confirm the right file was loaded
- Pins it at the top of the results as soon as scanning starts
- Displays a blue REFERENCE badge on the card
- Prevents it from being moved or deleted—Move and Delete buttons are disabled on the reference card
This last point is critical. If you’re using reverse search to find copies of a file you want to keep, you don’t want to accidentally delete the original. The reference protection system makes that impossible.
How the ORB algorithm works
ORB (Oriented FAST and Rotated BRIEF) combines FAST keypoint detection and BRIEF descriptor computation with orientation awareness. Here’s exactly what happens when you run an ORB reverse search:
Step 1: Load OpenCV.js
OpenCV.js is a WebAssembly‑compiled version of OpenCV. It runs entirely in your browser. 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: Extract reference features immediately
When you select your reference image or video, Sakarto processes it right away—before any folder scanning begins. The image is resized to 320×320, converted to grayscale, and ORB detects up to 500 keypoints (corners, edges, blobs). For each keypoint, a 32‑byte orientation‑normalised descriptor is computed. A thumbnail preview appears so you can confirm the correct file was loaded.
For videos, the middle frame is extracted and used as the reference. Video references show a 🎬 VIDEO badge on the reference card.
Step 3: Extract features from each folder file
For each image in the scanned folder, Sakarto runs the same ORB pipeline: resize to 320×320, convert to grayscale, detect keypoints, compute descriptors. In Fast Mode, JPEG files use their embedded EXIF thumbnail. For video files, the middle frame is extracted and processed the same way.
Step 4: Match descriptors against the reference using Hamming distance
The folder file’s descriptors are matched against the reference descriptors using a brute‑force Hamming distance matcher. For each reference keypoint, the closest match in the folder file is found. A match is counted as “good” if the Hamming distance is 40 or less.
Step 5: 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 6: Count good matches and compare to threshold
The number of good matches is compared to the similarity threshold. If the count meets or exceeds the threshold, the file is shown as a match. The reference card is always rendered first; matches appear live as they’re found.
Threshold direction: For ORB, higher = stricter (more matching keypoints required). This is the opposite of all hash‑based algorithms.
What ORB reverse search finds well
| Type of copy | How well it works | Why |
|---|---|---|
| Rotated copies of your reference (any angle) | ✅ Excellent | Orientation‑normalised descriptors make rotation invisible. |
| Mirrored copies of your reference | ✅ Excellent | Descriptors are computed on local patterns, not global position. |
| Significantly cropped versions | ✅ Very Good | Only needs shared keypoints; cropping removes some but not all. |
| Scanned documents that are photographed versions of the reference | ✅ Very Good | Perspective distortion changes position but not local patterns. |
| Perspective‑distorted versions (photographed from an angle) | ✅ Good | Moderate perspective changes preserve local descriptor patterns. |
| Re‑saved copies at different quality levels | ✅ Good | Descriptor quality is stable across moderate compression. |
| Copies with minor brightness or contrast adjustments | ✅ Good | Grayscale conversion and local patterns are robust to lighting changes. |
| Video files—middle frame extracted for matching | ✅ Good | The middle frame of both reference and folder videos are compared. |
| References with very few features (plain skies, solid colours) | ⚠️ May struggle | Few keypoints = few matches. Use hash algorithms for feature‑sparse images. |
| Heavily blurred copies | ⚠️ May struggle | Blur destroys edge keypoints. |
| Extremely low‑quality or tiny versions | ⚠️ May struggle | Small images produce unreliable keypoints. |
| Cartoon or line‑art references | ⚠️ May struggle | Few high‑contrast points. |
Understanding the similarity threshold slider
The Similarity Threshold slider controls the minimum number of good feature matches required between a folder file and the reference for it to appear in results. 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. Feature‑rich references will produce many matches. |
| 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 ORB reverse searches. |
| 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 reverse search: step by step
Step 1: Wait for OpenCV.js to load
OpenCV.js loads in the background when the page opens. If you click Choose Reference File while it’s loading, a toast appears and the process waits up to 10 seconds. It’s cached after the first visit so subsequent loads are instant.
Step 2: Select your reference file
Click Choose Reference File in the left panel. Select any image or video from your computer. A preview appears immediately so you can confirm you picked the right file. Sakarto processes the reference file right away—extracting its keypoints and descriptors before you even select the folder. This means the search starts instantly once you pick a folder.
Tip: The reference file does not need to be inside the folder you’re about to scan. It can be from anywhere on your computer. For the best results, choose a feature‑rich reference with plenty of texture, edges, and detail.
Step 3: Select the folder to search
Once a reference file is loaded, the Choose Folder to Search button becomes active. Click it to open a native folder picker (Chrome/Edge). Or drag and drop a folder onto the page. The folder count shows how many files were found. The Start Search button activates once both the reference file and a folder are selected.
Tip: Enable Fast Mode in the toolbar if you’re scanning many JPEG files—it reads embedded thumbnails and is 5–10× faster than loading full images.
Step 4: Start the search
Click 🔍 Start Search. The reference file card appears immediately at the top of the results with a blue REFERENCE badge. A progress bar shows how many files have been scanned. You can switch browser tabs during the search—image processing continues in the background. Video processing pauses when the tab is hidden and resumes when you return.
Step 5: Adjust the threshold if needed
Use the Similarity Threshold slider to tune matching sensitivity. Releasing the slider triggers an instant re-search using already-computed descriptors—no re-scan needed. Remember: for ORB, higher = stricter. If expected copies are missing, lower the threshold. If too many unrelated files appear, raise it.
Step 6: Review matches as they appear
Every time a matching file is found, it appears as a new card next to the reference. The header count updates live. Once the scan finishes, a final summary shows the total number of similar files found.
- Click a card to select it (blue border)
- Ctrl+Click (Cmd+Click on Mac) to add to the compare list (purple border)
- Click the 🔍 icon on hover to preview full size with metadata
- Right‑click any card for the context menu (the reference card has Move/Delete grayed out)
- Click & drag on empty space to box‑select multiple result cards
Step 7: Compare reference vs. match side‑by‑side
Ctrl+Click the reference card and one or more match cards, then click ⚖️ Compare in the toolbar. A modal opens showing all selected files side‑by‑side with their dimensions, file size, path, and a similarity percentage. For 3+ files, a full pairwise similarity matrix is shown. Similarity percentages above 80% are shown in green, 50–80% in amber, and below 50% in red—giving you a quick visual indicator of how close each match is to your reference.
Important: Rotated or cropped matches can look less obviously related at thumbnail size. Always use Compare to verify visually before deleting.
Step 8: Act on matches—Move, Delete, or Copy
Select the files you want to act on (not the reference—it’s protected) and use the toolbar. With Queue Mode on (recommended), files are staged first:
- 📋 Copy — copy filename(s) to clipboard
- 📂 Move — stage matches for move to a named folder
- 🗑️ Delete — stage matches 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 to review before executing. The reference file cannot be deleted or moved.
Step 9: Queue Mode—review before you commit
When Queue Mode is enabled (the default), clicking Move or Delete stages files rather than acting immediately. Switch to the Move Queue or Delete Queue tab in the sidebar to review what’s staged, remove individual files, then execute when ready.
Reverse Search vs. Find Duplicates: which to use?
| Reverse Search | Find Duplicates | |
|---|---|---|
| What it does | Finds copies of one specific reference file | Groups all similar files in a folder |
| Complexity | O(n) — each file compared against reference | O(n²) — all files compared against each other |
| Speed | Faster for large folders | Slower for large folders |
| Reference protection | Yes — reference pinned and cannot be deleted | No — all files are treated equally |
| Best for | You know exactly which file you’re looking for | You want to see every duplicate group in a folder |
| When to use | ”I need to find every copy of this specific photo" | "I need to clean up my entire photo library” |
Recommendation: Use both. Run Find Duplicates to see the big picture. Then use Reverse Search for specific important files to clean up their copies without risking the originals.
When to use ORB vs. the other 6 algorithms for reverse search
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 reference’s 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 reference’s 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 reference’s 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 reference’s 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 reference’s 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 reference’s 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 reference’s copies have been rotated, mirrored, cropped, or photographed from an angle. It’s the only option for these cases.
Algorithm quick reference for reverse search
| 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 reverse image search 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 reverse search specific)
“Why use ORB reverse search instead of aHash, dHash, or pHash?”
All hash algorithms encode the image as a fixed‑size grid. Rotate the image and every cell in the grid shifts—the resulting hash is completely different and the match is lost, regardless of threshold. ORB takes a fundamentally different approach: it finds up to 500 individual visual landmarks (corners, blobs, edges) in your reference image, computes an orientation‑normalised 32‑byte descriptor for each, then searches for those same descriptors in each folder file. A rotated copy has the same keypoints in different positions, but each descriptor is still recognisable. ORB is the only algorithm in Sakarto that handles rotation, mirroring, and perspective distortion. Use it specifically for those cases—for standard unrotated copies, any hash algorithm will be much faster.
”Why is the ORB threshold ‘higher = stricter’ when all other algorithms are ‘lower = stricter’?”
Hash algorithms measure Hamming distance (the count of differing bits between two fingerprints)—lower distance means more similar, so lower threshold = stricter. ORB measures the count of good keypoint matches between reference and folder file—more matches means more similar, so a higher required count = stricter. For example, a threshold of 30 means “only show this file if at least 30 good keypoint matches were found between it and the reference.” Raise the threshold if you’re getting too many unrelated results; lower it if genuine rotated copies aren’t appearing.
”Does ORB support video files as reference or folder files?”
Yes. Both the reference and folder files can be videos. Sakarto extracts the middle frame from each video file and runs ORB keypoint detection on that single frame. The rest of the pipeline is identical to images: reference keypoints are matched against folder file keypoints using Hamming distance plus Lowe’s ratio test. Video result cards show a 🎬 VIDEO badge. Important caveat: ORB uses only one frame per video, so if the middle frame of a video is dark, blurred, or a scene transition, matching will be less reliable. For videos, hash algorithms that average multiple frames (aHash, pHash, wHash) may give more consistent results.
”Does my reference file need to be inside the folder I’m scanning?”
No—select it from anywhere on your computer. If it also lives inside the scanned folder, Sakarto detects and skips it automatically using filename, file size, and last‑modified timestamp. The reference card is always pinned at position 0 with a blue REFERENCE badge and is fully protected from deletion.
”A rotated or cropped copy of my reference isn’t appearing. What should I try?”
First, lower the threshold to accept fewer matching keypoints as sufficient evidence. Second, check the visual content of both files: ORB needs corners, blobs, and textured regions to detect reliable keypoints. Images with large flat or uniform areas (solid sky, plain backgrounds, white walls) produce very few keypoints, leaving little for the algorithm to match. If both the reference and the copy are low in visual texture, ORB will struggle regardless of threshold. Third, check that both files have similar aspect ratios—pairs differing by more than 10% are excluded by the pre‑check. Fourth, check for very heavy compression on the copy: BRIEF descriptors are computed from local pixel patterns and severe blur or compression artifacts can destroy the patterns around keypoints.
”What is Lowe’s ratio test and why does ORB use it?”
When matching a keypoint from the reference against all keypoints in a folder file, the best match is the descriptor with the lowest Hamming distance. Lowe’s ratio test compares the best match distance to the second‑best match distance. If the two are too similar (the ratio exceeds 0.75), the keypoint appears ambiguous—it matches multiple regions in the folder file equally well—and is rejected. Only keypoints where the best match is clearly better than all alternatives are accepted as “good matches.” This dramatically reduces false keypoint pairings and is the reason ORB can reliably find rotated images without producing noise‑level false positives.
”Why is ORB reverse search much slower than hash‑based reverse search?”
Hash algorithms produce one compact hash (64 bits or 256 bits) per file and compare it against the reference hash in a single XOR+popcount operation taking nanoseconds. ORB produces up to 500 32‑byte descriptors per file and must match each one against all reference descriptors using Hamming distance—orders of magnitude more computation per file. Additionally, OpenCV.js is loaded as a WebAssembly module (~2‑5s on first use), and keypoint detection itself is more CPU‑intensive than a simple downscale. For large folders, consider running a fast hash algorithm first to eliminate obvious non‑rotated duplicates, then use ORB on a smaller subset.
”Can I recover files after deleting them?”
No. The File System Access API’s remove() method permanently deletes files without going through the OS Recycle Bin or Trash. The reference file is fully protected and can never be deleted regardless. For ORB results specifically, always use the Compare modal to visually verify matches before acting—ORB can occasionally match visually distinct images that share strong repeated textures or similar architectural elements. Move to a subfolder rather than Delete if you have any doubt.
”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 search and use Download List to export a report for manual file management.
Final thoughts
ORB reverse search 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 copies the others miss.
Ready to find every copy of your reference image or video—even rotated or cropped?
- Open ORB Reverse Search — free, browser‑based, no install
- Try Find Duplicates with ORB — auto‑group all similar files without a reference
- Explore All 7 Reverse Image & Video Algorithms — compare with Color Signature, aHash, BlockHash, dHash, pHash, and wHash