--- license: agpl-3.0 library_name: ultralytics pipeline_tag: object-detection base_model: Ultralytics/YOLO11 datasets: - deepghs/danbooru2024 - deepghs/danbooru2024-sfw metrics: - mAP tags: - yolo - yolo11 - ultralytics - object-detection - anime - foot-detection - adetailer - comfyui model-index: - name: foot_anime_yolo11m_v3 results: - task: type: object-detection dataset: name: Anime foot held-out (generated, 100 images / 185 feet) type: custom metrics: - type: mAP50 value: 0.81 name: mAP@50 - type: mAP50-95 value: 0.59 name: mAP@50-95 --- # Anime foot detector (YOLO11m) A small YOLO11m detector that finds feet in anime and illustration images. It has a single class, `foot`. The main use is image generation cleanup: pair it with an ADetailer or Impact Pack workflow in ComfyUI so a detail or inpaint pass can fix feet, which diffusion models often render badly. It was built for the Anima text-to-image model, but it works on anime-style imagery in general, so it should transfer to other anime or illustration generators without retraining. Three versions are provided. They share the same architecture and differ only in training. `v3` is the current production model. ## Which one to use - `foot_anime_yolo11m_v3.pt` is the production model and the one to use. On a held-out test set it has the best box accuracy across every image type and the broadest coverage, including harder cases like stockings and unusual poses. - `foot_anime_yolo11m_v2.pt` is the previous production model, very close behind, and a little better at finding feet in plain, clearly visible shots. A good alternative. - `foot_anime_yolo11m_v1.pt` is the first and weakest version, kept for reference. Start with v3. If it misses a foot in a simple image, try v2. ## Models | file | size | input | role | |---|---|---|---| | `foot_anime_yolo11m_v1.pt` | 40 MB | 640 | seed (reference) | | `foot_anime_yolo11m_v2.pt` | 40 MB | 640 | previous production | | `foot_anime_yolo11m_v3.pt` | 40 MB | 640 | production (recommended) | All are YOLO11m (about 20M parameters), fine-tuned from the COCO-pretrained `yolo11m.pt`. ## Files and formats Each version ships in two formats: - `.pt` is the standard Ultralytics PyTorch checkpoint, and what ComfyUI and `YOLO(...)` load directly. It is a pickle, so the Hub lists its imports; those are the normal torch and Ultralytics imports, and the weights are first-party (trained here). - `.onnx` is a non-pickle export for anyone who would rather not load a pickle, or who wants to run the model with ONNX Runtime outside the Ultralytics stack. Each ONNX file was checked to give the same detections as its `.pt`. ## Why YOLO11m Version. These are built on YOLO11, chosen as the proven, well-supported Ultralytics line: the cleanest ComfyUI integration and a one-line transfer-learning start from `yolo11m.pt`. It is not the newest model. Ultralytics released YOLO26 in January 2026, which is NMS-free and adds small-target-aware training, both of which would suit this task, so a future version will likely move to YOLO26m. YOLO11 was the stable, obvious choice when this line started, and switching architecture partway through would have broken the version-to-version comparison. Size. Medium (about 20M parameters, 40 MB) rather than a larger variant like `yolo11l` or `yolo11x`. The task is narrow, one class in one domain, so medium has plenty of capacity, and on the test set it already maxes out the easy image types. The failures that remain are open-toe footwear and the occasional false positive, which are data and labeling gaps rather than capacity gaps. A heavier backbone will not learn cases it was never shown, so it would cost more for about the same ceiling on the parts that matter. The detector also runs inside a generation pipeline, next to the diffusion model and often SAM, on consumer GPUs. A 40 MB medium model barely touches the VRAM budget and stays fast on every call, while a larger variant would compete for memory and slow each image for little gain on this task. ## Benchmark A held-out set of 100 generated anime images (185 feet) that none of the models trained on, split into four groups of 25. The first row is a generic YOLOv8x foot detector, included only as an external reference point; it is not part of this repository. Scores are mAP50 / mAP50-95. Overall: | model | mAP50 | mAP50-95 | |---|---|---| | generic YOLOv8x (reference) | 0.42 | 0.18 | | v1 | 0.28 | 0.08 | | v2 | 0.81 | 0.50 | | v3 | 0.81 | 0.59 | By image type, v2 against v3: | group | v2 mAP50 | v3 mAP50 | v2 mAP50-95 | v3 mAP50-95 | |---|---|---|---|---| | visible feet | 0.95 | 0.91 | 0.52 | 0.63 | | feet in focus | 0.93 | 0.95 | 0.66 | 0.75 | | stockings / tights | 0.93 | 0.93 | 0.62 | 0.69 | | open-toe footwear | 0.42 | 0.43 | 0.22 | 0.28 | v3 has the better box accuracy (mAP50-95) in every group, and matches or beats v2 at finding feet in most of them. v2 is slightly ahead only on plain visible shots. Open-toe footwear is the hardest case for every model, so expect more misses there. ## Strengths and weaknesses **v3 (recommended).** Best box accuracy on every image type in the test, and the best coverage of harder cases like stockings and unusual poses, since it trained on the largest and most varied set (about 286k images). On plain, clearly visible feet it will occasionally miss one that v2 catches, and open-toe footwear is still hard. **v2.** The best at simply finding feet in clear shots, with high recall, and it behaves predictably because it trained on clean hand-checked data. Its boxes run a little looser than v3 on unseen images, it covers fewer unusual poses, and it is more prone than the others to mistake a hand for a foot. **v1.** Small and fast, and reasonable on plain visible feet, but the weakest overall by a wide margin. It trained on a small set and struggles outside the easy case, and it can occasionally fire on a foot-like shape in a busy or detailed background. Its boxes also tend to cover only part of the foot, often just the toes. Kept only for reference. A note on box coverage: v2 and v3 draw slightly looser boxes that reliably wrap the whole foot, sometimes with a little extra margin, while v1 often boxes only part of it. For a detailer that inpaints the whole region, full coverage matters more than a tight fit, so the looser boxes are usually a benefit here. ## Examples Ten images from the Anima pipeline, each run through all four detectors at once. Every model draws its boxes in its own color, with the confidence printed on the box and a per-image detection count next to each name in the legend. - red: v3 - green: v2 - blue: v1 - yellow: generic YOLOv8x (reference, not part of this repo)
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |