# Three files declare three different minimum versions

> DeepDanbooru trains a multi-label tag estimator for anime images from a SQLite database beside a folder tree. Its README asks for Python 3.11 and TensorFlow 2.17, its requirements file agrees, and its packaging declares Python 3.6 and puts TensorFlow behind an extra. Its release tags are training run names, and the newest is from 2022.

**KichangKim/DeepDanbooru** — AI based multi-label girl image classification system, implemented by using TensorFlow.

- Repository: https://github.com/KichangKim/DeepDanbooru
- Stars: 2,945 · Forks: 266
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/kichangkim-deepdanbooru

## The README, the requirements file and the packaging declare three floors

The dependency story in this repository is told three times and the three tellings do not match. The README says the project is written in Python 3.11 and lists seven packages with fairly recent lower bounds: Click at 8.1.7, numpy at 1.26.4, requests at 2.32.3, scikit-image at 0.24.0, six at 1.16.0, tensorflow at 2.17.0 and tensorflow-io at 0.31.0. The requirements file lists those same seven with those same bounds.

The packaging file says something different. It declares python_requires as 3.6 or newer, and its install list uses much older floors for the same five non-TensorFlow packages: Click 7.0, numpy 1.16.2, scikit-image 0.15.0, requests 2.22.0 and six 1.13.0. TensorFlow, when it appears at all, starts at 2.7.0 rather than 2.17.0.

So a resolver reading the packaging will happily install on Python 3.6 with a TensorFlow four years older than the one the project was written against, and nothing in the package metadata contradicts that.

## One install route pulls in TensorFlow and the other deliberately does not

There are two documented ways to install, and they produce different environments. The first is the requirements file, and the README presents it as the easy option. That file contains tensorflow and tensorflow-io at their newer floors, so this route installs the framework.

The second is the package itself, and here the behaviour is deliberate. The documentation states plainly that by default TensorFlow is not included, and that adding the extra package is how you get it. So `pip install .` gives you the command line tool without the framework, and `pip install .[tensorflow]` adds it. There is a second extra as well, named test, carrying pytest, flake8 and mypy.

That split is defensible, and it keeps the evaluation path usable without a training stack. It is also the reason the floor numbers disagree: the light install can support an older interpreter than the full one, and the packaging file expresses the light case while the README expresses the heavy one. A user who reads only the requirements file gets the heavy case by default without being told they chose it.

## The version number is read out of the main module with a regular expression

The packaging does not carry a version field. Instead it opens the package's main module, searches its text for a version assignment with a regular expression, and uses the captured string. So the single source of truth for the version is a line inside deepdanbooru/__main__.py, and every published artifact gets its number from there rather than from a value a maintainer edits twice.

The rest of the packaging is conventional. The long description is read from the README with an explicit encoding, and its content type is declared as markdown. Packages are discovered automatically rather than listed, and the console entry point maps a command named deepdanbooru onto the main function of that same module.

The classifiers are where the metadata gets thin. Python 3 is listed with no minor version, and the operating system is declared independent, in a repository that ships a Windows batch file at its root and a Travis configuration for its tests.

## Release tags are training run identifiers, and the newest is from 2022

The three published releases are named like experiments rather than versions. They are v3 with a date of 20211112, the optimiser sgd and 28 epochs; v4 with a date of 20200814, sgd and 30 epochs; and v3 with a date of 20200915, sgd and 30 epochs. Each display name calls itself a pretrained model release.

Read as a scheme, a tag tells you which model family, which training run date, which optimiser and how long it trained. It does not tell you a semantic version, so there is no way to ask whether one is newer in the ordinary sense, and the listed order is not chronological either: the 2020 v4 tag was published before the 2020 v3 one, and the 2021 run was published in February 2022.

The gap that matters is between code and weights. The newest release was published on 2022-02-03. The repository is not archived and the last push to master is dated 2026-07-04, so the code is being touched while the newest pretrained artifact is more than four years old. Anyone planning to use published weights rather than train their own is working from 2022.

## Tags come either from Danbooru with an account, or from a text file you write

A project folder is the unit of training and it holds exactly two files: a project configuration file and a tag list. The tag list is described as a simple newline separated text file, one tag per line, with the first entries shown as 1girl and ahoge.

You can write that file yourself, and the documentation says so. Or you can have the tool fetch the current tags, and that path is where an account appears. The download command takes a username and an API key for Danbooru, and the README states in the same sentence that both are needed. Nothing else in the workflow requires credentials, so the account is scoped to this one step.

The upstream dataset is treated the same way. If you do not have a dataset, the documentation points at a separate downloader project for Danbooru, and if you want to build your own it points at the dataset structure section instead. Between the two steps, the pipeline is: prepare data, create the project, optionally convert rating and score into system tags, point the project file at your SQLite file, then train.

```
> deepdanbooru create-project [your_project_folder]
> deepdanbooru download-tags [your_project_folder] --username [your_danbooru_account] --api-key [your_danbooru_api_key]
> deepdanbooru make-training-database [your_dataset_sqlite_path] [your_filtered_sqlite_path]
> deepdanbooru train-project [your_project_folder]
> deepdanbooru evaluate [image_file_path or folder]... --project-path [your_project_folder] --allow-folder
```

Every one of those is a subcommand of the single console entry point, and the last one is the only one you run against your own images rather than a training artifact.

## The dataset is one SQLite file beside a two level image tree

The data contract is small and worth stating exactly, because anything that produces this shape can be used as input. Images live under a folder named images, and inside it every file sits in a subfolder named for the first two characters of its own filename, which gives sixteen buckets from 00 to ff. The SQLite file can have any name but must sit beside that images folder.

Inside, one table called posts carries five columns: an integer id, the md5 as text, the file extension as text, a tag string as text, and an integer tag count. Each image file must be named with its md5 followed by a dot and its extension, and the documentation notes that if the images are your own the md5 does not have to be a real hash.

The tag string is the whole label space: a space separated list such as 1girl ahoge long_hair. And the tag count is the filter knob, because it is what the minimum_tag_count project setting compares against, keeping only images at or above the threshold.

## The demo link is a bare address on a high port

Two demo endpoints are advertised. One is a normal application URL on a subdomain, described as a live site where you can estimate your own images. The other sits in the badge row at the top of the README and is a plain host address on port 8003, with no path and no scheme beyond what the browser infers.

That second one is worth a note because it is the address a reader is most likely to try first. It is a self-hosted-looking endpoint exposed directly rather than behind a named domain, and nothing in the README explains who runs it, whether it is the same service as the other link, or why the two are different. The same author contact appears in the packaging, so both look like the same person's infrastructure.

The repository root is small in the same spirit: a gitignore, a Travis file, the licence, the README, the package directory, the requirements file, two packaging files, a Windows batch file for repeating a run, and a tests directory.

## Conclusion

DeepDanbooru is a working reference for anyone who wants a tag estimator trained on their own image set rather than downloading a finished model, and the data contract it defines is small enough to reimplement elsewhere. Four things to settle first. Pick your dependency floors deliberately, because the README, the requirements file and the packaging disagree and only the README matches what the code was written against. Decide whether you want TensorFlow at all before you install, since one documented route pulls it in and the other deliberately does not. Note that the pretrained releases stop at the start of 2022 while the code itself was pushed to in July 2026, so treat any published weights as old. And if you take tags from Danbooru rather than writing your own list, budget for an account and an API key for that step alone.

## FAQ

### deepdanbooru vs wd14

This repository does not make that comparison. What it documents is its own path: a SQLite file with a posts table beside an images tree split into subfolders by the first two characters of each filename, a project folder holding a configuration file and a tag list, and commands for creating a project, downloading tags, building the training database, training and evaluating.

### What are the requirements for DeepDanbooru?

The README says Python 3.11 and lists Click, numpy, requests, scikit-image, six, tensorflow and tensorflow-io with lower bounds, including tensorflow at 2.17. The packaging file disagrees, declaring Python 3.6 or newer and TensorFlow from 2.7 inside an optional extra.

### How do I install DeepDanbooru?

Two documented routes that differ in one important way. Installing from requirements.txt includes TensorFlow, because that file lists it. Installing the package does not, and TensorFlow is added by asking for the tensorflow extra. A second extra named test brings pytest, flake8 and mypy.

### Where does DeepDanbooru get its tag list?

Either from you or from Danbooru. The download command fetches the latest tags from the Danbooru server and needs an account and an API key, but the tag file in the project folder is a plain newline separated list that you can write yourself, so that step is optional.

## Sources

- [Issues](https://github.com/KichangKim/DeepDanbooru/issues)
- [KichangKim/DeepDanbooru on GitHub](https://github.com/KichangKim/DeepDanbooru)
- [License: MIT](https://github.com/KichangKim/DeepDanbooru/blob/master/LICENSE)
- [README](https://github.com/KichangKim/DeepDanbooru/blob/master/README.md)
- [Releases](https://github.com/KichangKim/DeepDanbooru/releases)

---

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