ldqk/ImageSearch: Local image search and duplicate cleanup on Windows

ImageSearch's local image collection use case

ImageSearch addresses two related problems that ordinary filename search does not: finding an image by its visual content and grouping files that look alike. The intended audience is Windows x64 users with large collections stored on local disks, including photographers, archivists, developers, and anyone who needs to reduce redundant image files without uploading the collection to a web service.

The application supports JPG, PNG, BMP, and GIF for cross-format image search. It can also search video files. For video processing, the README says the application extracts one frame per second, scales each frame to 160 pixels, and indexes those frames. The interface accepts an image through manual selection, drag and drop, or the clipboard, while indexed media remains selected from local folders.

This is an organizational tool rather than an asset-management system. The documented workflow covers indexing, visual matching, duplicate grouping, file actions, and EXIF removal. The README does not describe remote search, shared libraries, multi-user access, web interfaces, or cloud synchronization.

Perceptual hashing and indexed search flow

Image search begins with an index. Users first choose a folder in the main window and update the index. Once indexing is current, a selected image or video becomes the query. The README documents manual selection, drag-and-drop, and clipboard input, so the tool is designed for both deliberate lookups and quick visual searches.

The repository description identifies the project as a .NET 10 case study and utility for local image search. The README names three similarity algorithms in the duplicate scanner: Difference Hash, DCT Hash 32, and DCT Hash 64. Search also lets users select the matching algorithm and adjust similarity. Difference Hash has a minimum interface threshold of 70, while the other algorithms have a minimum threshold of 85. A higher threshold makes filtering stricter, although the actual matches still depend on image content.

Results show the path, match percentage, file size, the number and total size of files in the containing folder, and the selected algorithm. Users can preview the query and matched image, open a result, open its folder, delete it, or move it to the recycle bin. Rotation and flipped-image matching can be enabled during search, which matters for images that were transformed after capture or processing.

Duplicate scanning across files and directories

The “相似文件查找” workflow scans one or more directories for similar files. Directories can be browsed for, typed, pasted, or dragged into the interface. Users can exclude directories, choose whether to scan subfolders, and decide whether duplicates within the same folder should be ignored.

Unlike the query-driven image search, this feature is intended for broad collection cleanup. It supports Difference Hash, DCT Hash 32, DCT Hash 64, or all available algorithms while the scan is running. The interface reports progress, speed, processed-item count, and elapsed time, and the scan can be stopped.

Results are organized into duplicate files and duplicate directories. The latter category appears when duplicate directories are found. Users can switch between list and thumbnail views, change thumbnail size, and filter by folder, mark state, path, algorithm, or minimum similarity. A refresh action removes stale results for files that no longer exist and updates the grouping.

Cleanup decisions can be manual or rule-based. The documented retention rules select the largest or smallest file, the newest or earliest modification, or the shortest or longest filename. Marking can also cover other files in a group, a directory, a directory tree, or a disk. These controls are useful for a large scan, but rule-based retention is still a heuristic and does not establish that a file is visually redundant in every semantic sense.

Indexing controls and Everything integration

Index maintenance is a distinct operation rather than an automatic background behavior described by the README. The update window reports the current file, progress, speed, throughput, and estimated remaining time. Users can stop an update, and the “移除无效索引” option cleans records that are no longer valid during the update.

ImageSearch can also use Everything on Windows. If Everything is running and `Everything64.dll` is present in the program directory, the application calls Everything to locate files. The directory being scanned must already be included in the Everything index. Removing `Everything64.dll` disables that integration, while direct directory scanning remains available according to the README.

This creates two indexing paths with different responsibilities. ImageSearch maintains the visual search index, while Everything supplies file discovery. The README does not say that Everything builds ImageSearch's hash index or that the two indexes synchronize automatically. Users who rely on the integration should therefore understand that missing files from Everything and missing visual hashes are separate failure possibilities.

Windows setup, FFmpeg, and first image search

The README does not provide installation commands, a download command, a package name, or a step-by-step installation procedure. It identifies the runtime and platform requirements instead: Visual Studio 2026 for development, .NET 10 Desktop for the runtime, and Windows x64 for the application. Video processing additionally requires FFmpeg, with `ffmpeg.exe` available through `PATH`.

For a first real use, start the Windows x64 application, choose a folder in the main window, and update the image index. The update view should show the file being processed, progress, speed, throughput, and an estimated completion time. After the index finishes, choose an image manually or drag one into the window. The README also says that an image already present in the clipboard can be used as the search input.

Select a matching algorithm and a similarity value, then start the search. The result list should show candidate paths, match percentages, file sizes, folder summaries, and the algorithm used. Preview a candidate before taking file action. If the search produces no useful result, the first thing to check is whether the folder was indexed after its contents changed. The README does not document an installation command, a portable package layout, or a rollback procedure.

Limits of whole-image matching and batch deletion

ImageSearch compares entire images. The README explicitly states that searching only a selected region inside an image is not supported. That limitation rules out common visual-search tasks such as finding a product from a cropped screenshot, identifying a logo within a larger photograph, or finding a face in a group image without first extracting the relevant region.

The similarity threshold is also not a general guarantee. The README says that Difference Hash starts at 70 and the other algorithms at 85, and that results depend on image content. Similar hashes can arise from images with shared composition, repeated textures, or similar layouts, while transformations may alter the result. Rotation and flipped-image matching can be enabled, but the documentation does not claim that all crops, edits, color changes, or video frames will match.

Deletion and replacement deserve more caution than searching. The interface supports deleting files, moving them to the recycle bin, and replacing group members. The “抑制所有确认提示” option skips confirmation for deletion and overwrite operations. The README warns to check paths and marks carefully. It does not document a recycle-bin fallback for every deletion action, an undo command, or an application-level backup, so bulk cleanup should not be treated as reversible without separate verification.

ImageSearch versus DuplicateCleaner and manual hashing

The README presents ImageSearch as inspired by and broadly comparable to DuplicateCleaner. Its documented approach is a .NET 10 Windows desktop application with local image indexing, image and video query search, perceptual hash algorithms, duplicate-directory grouping, retention rules, and EXIF removal positioning. The project claims to be faster than DuplicateCleaner, but the README provides no benchmark data, test procedure, hardware configuration, or comparison criteria for that claim, so the performance claim cannot be independently assessed from the repository information.

DuplicateCleaner is not technically documented here beyond the reference link and the stated design goal. The real distinction supported by the README is ImageSearch's added query workflow: users can index a folder and search by a selected image, video frame, or clipboard image. The alternative approach is manual comparison based on filenames, dates, file sizes, or isolated hashing in separate tooling. Manual methods avoid this application's index update step, but they do not provide the documented visual grouping and retention interface.

ImageSearch also includes an EXIF information removal tool as part of its stated scope. The README does not specify its command-line interface, batch behavior, metadata fields, or preservation policy, so EXIF users should inspect that tool before assuming it covers every metadata type.

Maintenance status, releases, and upgrade implications

The repository is not archived, and its last push was on 2026-10-15. Recent releases include 6.0 on 2026-10-14, 5.0 on 2026-10-08, and 4.2 on 2026-09-19. Release 6.0 is labeled as containing “6.0中断性变更,” which indicates breaking changes. The README does not document the specific migration steps or compatibility effects, so upgrading across major versions requires checking the release information and validating existing indexes and settings.

The project is licensed under MIT. That license permits use and modification under its stated terms, but this review does not interpret its legal implications. The practical upgrade cost is likely higher than for a small utility because image indexes, GUI behavior, algorithm options, and file actions may change across major releases. The repository layout contains a solution and a C# application directory, while the documented runtime target is .NET 10 Desktop on Windows x64.

Editorial conclusion

ImageSearch fits Windows users managing large local collections of JPG, PNG, BMP, GIF, or video files who need similarity-based search and duplicate organization. It is a poor fit for macOS or Linux users, people searching only within a crop of an image, or users who need documented rollback behavior for deletions. Before adopting it for bulk cleanup, verify that whole-image matching and the selected algorithm produce acceptable results on a small sample, then check deletion paths and retention marks before enabling any confirmation-suppressing option.

Frequently asked questions

Official sources

1. Issues
2. ldqk/ImageSearch on GitHub
3. License: MIT
4. README
5. Releases