# PicImageSearch and the case for one interface over fifteen search engines

> PicImageSearch is a Python library that wraps reverse image search engines behind a single interface, covering ASCII2D, SauceNAO, IQDB, Google Lens, Yandex and others. It saves you from writing a client per site, at the cost of depending on how those sites happen to respond today.

**kitUIN/PicImageSearch** — 整合图片识别 API，用于以图搜源 / Aggregator for Reverse Image Search API

- Repository: https://github.com/kitUIN/PicImageSearch
- Website: https://pic-image-search.kituin.fun/
- Stars: 737 · Forks: 63
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/kituin-picimagesearch

## One call site instead of fifteen HTTP clients

PicImageSearch describes itself as an aggregator for reverse image search APIs, and the problem it solves is concrete. Reverse image search is spread across a dozen sites with different upload endpoints, different result markup, and different notions of what a match means. Working with one of them is easy. Working with all of them means a separate HTTP client, a separate parser and a separate set of edge cases per site.

The library collapses that into one Python package. The supported engines listed in the README are AnimeTrace, ASCII2D, Baidu, Bing, Copyseeker, E-Hentai, Google Lens, IQDB, SauceNAO, Tineye, TraceMoe and Yandex, plus two entries marked deprecated, Google and Lenso.

Who it is for is fairly narrow: developers building tools around anime artwork identification, image attribution or content tracing. The topic tags on the repository match, with ascii2d, iqdb, saucenao, tracemoe and e-hentai all listed, and the engine table itself tells you where the traffic comes from. Anyone expecting a general purpose image similarity engine will find the coverage skews towards anime and illustration sources.

## Two import paths, and the asynchronous one is the recommended one

The API surface has two entry points and the README is direct about which to use. Synchronous usage imports from `PicImageSearch.sync`, while asynchronous usage imports `Network` and the rest from the top level `PicImageSearch` package. The README marks asynchronous usage as recommended.

That recommendation makes sense for the shape of the work. A reverse image lookup is a network round trip, and a fan-out across several engines is several round trips in parallel. If you are building a tool where a user uploads one image and you query five sites, the synchronous path serialises those waits and the asynchronous path does not.

The choice is not free of consequences. The asynchronous API requires an event loop and an async client, so a synchronous application has to think about where the loop lives. Developers working in a script can start from the sync import and move later, while server frameworks that already run an event loop can go straight to the async path.

## The dependency list shows HTML parsing, not a schema-based API

The runtime dependencies in `pyproject.toml` are short and revealing: `httpx2[http2]>=2.13.1`, `lxml>=6.1.3,<6.1.4` and `pyquery>=2.1.0`. There is no SDK from any of the fifteen providers in that list.

Read together, those three packages describe the mechanism. The HTTP client is httpx2 with HTTP/2 support enabled, which matters for sites that negotiate HTTP/2. The two HTML libraries, lxml and pyquery, sit above the client, which is consistent with parsing result pages rather than consuming a documented data format. pyquery in particular gives a jQuery-like selector API over lxml, which is the natural choice for extracting result rows out of markup.

This is the single most important thing to understand about the project before adopting it. The library is built on how these sites respond and how their markup is structured, not on a published contract that a provider could change without notice.

## Installing with pip, and the optional socks dependency

Installation is a standard pip install, and the README requires Python 3.10 or above. The documented command is `pip install PicImageSearch`, and for networks where the default index is slow the README offers the Tsinghua mirror, `pip install PicImageSearch -i https://pypi.tuna.tsinghua.edu.cn/simple`.

There is one optional dependency group declared, `socks`, which pulls in `socksio>=1.0.0`. That is the switch to flip when you need to route requests through a SOCKS proxy, which is a common requirement for users in regions where some of these search sites are unreachable, and it is optional rather than bundled so that everyone else pays nothing for it.

The package is built with hatchling and the version is dynamic, read from the path `PicImageSearch/__init__.py`. The project also ships a `typings/` directory, and the development configuration is basedpyright with ruff for linting and a line length of 120, so type information for the library is part of the repository rather than an afterthought.

## Deprecated engines are a warning about the maintenance model

Two entries in the supported engine table carry the word deprecated: Google, pointing at the classic image search page, and Lenso. Their presence in the table, with a working link each, tells you the project keeps a record of engines that no longer function as they once did rather than quietly removing them.

That is the honest shape of a reverse image search aggregator. Each engine sits behind a decision made by a company you do not control, and when the product changes, the parsing code breaks. The Lenso entry is a case in point: a service that was listed for a while and then stopped working as expected.

The practical consequence is that you should treat engine support as a moving target. The README does not state a service level for any engine, does not document retry or backoff behaviour, and does not describe how failures on one engine are surfaced when several are queried at once. If an engine breaks, you will find out from your own monitoring.

## Recorded HTTP responses in the test suite

The development dependency group is informative about how the project is tested. Alongside pytest and pytest-asyncio it lists `pytest-vcr>=1.0.2` and `vcrpy>=8.3.0`, which is a library for recording and replaying HTTP interactions.

The practical effect is that the test suite does not need to hit the live engines on every run. Interactions can be captured and replayed, which makes the tests repeatable and keeps the suite from depending on the availability of fifteen third-party sites. It also means a passing test run does not prove the current live behaviour is unchanged, since the fixtures are snapshots.

Documentation is built with mkdocs and the mkdocs material theme, with mkdocs-static-i18n for translations and mkdocstrings to pull docstrings from the code. The README is available in English, Simplified Chinese, Russian and Japanese, which tells you the intended audience is international.

## What the library does not give you

There is no caching layer, no result normalisation layer and no rate limiting described in the documentation. Every call appears to be a fresh request to the engine you ask for, and the result objects will carry whatever fields that engine's page exposes.

That has a direct consequence for anyone building on top of it. If you query SauceNAO for an anime frame, the response is SauceNAO's shape. If you query Google Lens for the same frame, the response is a different shape. The library gives you a uniform way to ask, but it does not claim to give you uniform answers, and the README does not describe a common result type across engines.

The mitigation is on your side of the boundary. Wrap each engine call in your own adapter that returns the fields your application actually needs, and keep that adapter separate from the PicImageSearch call itself. The `demo/code/` directory in the repository is the place the project points to for example code, so it is worth reading before writing those adapters from scratch.

## Conclusion

PicImageSearch is a good fit if you need to fan a lookup across several reverse image search engines and would rather not maintain a separate HTTP client for each one, especially for anime artwork where ASCII2D, IQDB, SauceNAO and TraceMoe answer different questions. It is the wrong choice for a single engine workflow, for a service where a scraper-shaped dependency is unwelcome, and for anyone needing a contractual API. Verify first that the engine you care about is in the supported table and has not been marked deprecated, as the Google and Lenso entries are, and check the `httpx2[http2]` and `lxml` dependencies in `pyproject.toml` against the network your deployment allows.

## FAQ

### How do I install PicImageSearch?

The README gives `pip install PicImageSearch`, or `pip install PicImageSearch -i https://pypi.tuna.tsinghua.edu.cn/simple` to use the Tsinghua mirror. Python 3.10 and above is required.

### Which reverse image search engines does PicImageSearch support?

The README lists AnimeTrace, ASCII2D, Baidu, Bing, Copyseeker, E-Hentai, Google Lens, IQDB, SauceNAO, Tineye, TraceMoe and Yandex, with Google and Lenso marked deprecated. The project documentation is linked at pic-image-search.kituin.fun.

### Should I use the synchronous or asynchronous API of PicImageSearch?

The README recommends asynchronous usage, importing `Network` and the rest from the top level `PicImageSearch` package. Synchronous usage is available by importing from `PicImageSearch.sync`, and the asynchronous path is preferable when querying several engines for the same image.

### How do I use a SOCKS proxy with PicImageSearch?

The project declares an optional dependency group named `socks`, which installs `socksio>=1.0.0`. The runtime dependencies otherwise consist of `httpx2[http2]`, `lxml` and `pyquery`.

### What licence is PicImageSearch released under?

PicImageSearch is released under the MIT licence, declared in `pyproject.toml` and with the LICENSE file at the repository root.

## Sources

- [kitUIN/PicImageSearch on GitHub](https://github.com/kitUIN/PicImageSearch)
- [License: MIT](https://github.com/kitUIN/PicImageSearch/blob/main/LICENSE)
- [Project website](https://pic-image-search.kituin.fun/)
- [README](https://github.com/kitUIN/PicImageSearch/blob/main/README.md)
- [Releases](https://github.com/kitUIN/PicImageSearch/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kituin-picimagesearch