dtourolleandClaude Opus 5
e26f71d15d
The weights were in two places: face detection and recognition in `models/face/`, segmentation in `core/dr-segment/models/`. Nothing was wrong with either path, but between them there was nowhere to look to answer "how much model does this application carry", and that number is about to start growing. So the crate-local copy moves up beside the other. `models/` now holds `face/` and `segment/`, and a `du -sh` of one directory is the whole answer. No content changes: the .onnx and its vocabulary are byte-identical, and `LICENCE.md` moves up a level to cover the tree rather than one crate. The LFS pattern in `.gitattributes` is `*.onnx` and already matched both locations, so only its comment needed the new path. `include_bytes!` is relative to the source file and `build.rs` runs with the crate root as its working directory, which is why the two paths climb a different number of levels. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.7 KiB
Model weights — licensing
yolo26n-seg.onnx is exported from Ultralytics YOLO26n-seg
(https://huggingface.co/Ultralytics/YOLO26, yolo26n-seg.pt) by
tools/export-seg-model.sh. yolo26n-seg.classes.json is that checkpoint's
class vocabulary, written out by the same script.
The grant
Ultralytics releases YOLO under AGPL-3.0, and the weights carry the same
grant as the framework — the HuggingFace repository declares agpl-3.0 for the
checkpoints themselves, not merely for the training code. A commercial licence
is offered separately; DarkRoom does not use it and does not need it.
What that means for DarkRoom
DarkRoom is GPL-3.0-or-later. GPLv3 §13 explicitly permits combination with AGPL-3.0 code, so redistributing these weights inside this repository is allowed — this is not the situation the InsightFace "buffalo" weights would have created, where a non-commercial research grant is simply incompatible with the project's licence and with F-Droid, Flatpak and Play distribution (NFR-COMPAT-2, D13).
The consequence, and it is a real one: the combined work is effectively AGPL-3.0. §13's permission runs one way — the AGPL's §13 network-use condition attaches to the portion under that licence. For a local-first desktop and Android photo editor that condition has no practical bite, because there is no network service offering the combined work to remote users. It would acquire bite the moment any hosted or server-side rendering appeared, and that is the thing to remember rather than rediscover.
This was decided deliberately (D14), not arrived at by accident, and
docs/segmentation.md §7 records the reasoning.
Class vocabulary — a caveat worth reading
docs/segmentation.md §4 specified YOLO pretrained on ADE20K, whose 150
classes include the stuff categories that matter most in photography — sky,
vegetation, water, wall, mountain.
No such model exists in usable form. Checked 2026-08-21: Ultralytics ships
YOLO26-seg trained on COCO, whose 80 classes are all things — person,
dog, car, bird, potted plant — and the one HuggingFace repository claiming a
YOLO/ADE20K combination (laxmacl/yolov8-ade20k) is empty. ADE20K semantic
models do exist, but as SegFormer/OneFormer/MaskFormer transformers, not YOLO.
So the shipped vocabulary selects subjects, not stuff. "Select the person" works; "select the sky" does not come from the model and must come from the watershed hierarchy instead. That is a narrower arm B than §4 assumed, and it raises rather than lowers the importance of arm C.
The loader treats the vocabulary as model metadata rather than compiled-in knowledge, so adding a stuff-class model later is a file plus a descriptor, not a code change.