fireviewer/litert-models

FireViewer · LiteRT sur Android

Des modèles feu/fumée documentés, avec adaptation locale et checkpoints vérifiables.

Conversions de détection et de pointage pour des intégrations Android expérimentales. Les têtes ou sorties peuvent apprendre à partir d’annotations revues ; les réseaux visuels restent figés. Cette livraison ne constitue pas un système d’alerte incendie ou une validation opérationnelle.

Français · English
Prise en main · Catalogue et preuves · SDK Kotlin · Apprentissage continu

Variantes livrées	Apprentissage sur hôte	Android autonome
6, dont 5 entraînables	5 conversions vérifiées	YOLO11 M learning vérifié sur émulateur

Les six variantes restent non qualifiées dans Vision Dataset Studio. Le succès du SDK YOLO ne valide ni les autres modèles ni leur intégration dans l’application. Aucun téléphone ARM physique, score de détection ou test d’oubli n’est documenté.

Trouver le bon composant

Famille	Usage et fichiers
D-FINE M strict v1	Détection et adaptation des propositions
RT-DETRv2 R50	Détection et adaptation des propositions
YOLO11 M strict v1	Inférence · Variante entraînable
RF-DETR Medium 1.10	Détection et adaptation des propositions
DINOv3 pointing pilot v1	Segmentation, pointage, présence et abstention

La source optionnelle SegFormer-B2 n’était pas disponible : aucun modèle SegFormer n’est livré ici. Les adaptations de détection ne créent pas de propositions absentes du détecteur figé.

Démarrer sans ambiguïté

1. Choisir une variante et lire son README, son contrat et ses notices.
2. Télécharger une révision épinglée et vérifier le manifeste des artefacts.
3. Appliquer exactement normalisation, disposition des tenseurs, classes et transformation des coordonnées.
4. Tester l’inférence avant l’apprentissage ; fournir uniquement des annotations connues et revues.
5. Conserver l’original, enregistrer les checkpoints séparément et évaluer un candidat avant activation.

Guide complet et exemples de téléchargement · Cycle des checkpoints.

SDK et architecture

Le SDK Kotlin expose infer, train, save et restore. Ses générations conservent paramètres, moments SGD et compteur d’étapes ; les reçus contrôlent modèle, schéma de labels et intégrité des fichiers. L’application qui l’intègre reste responsable de la validation métier et du choix des poids actifs.

YOLO accepte des dimensions H/W multiples de 32. Les autres modèles redimensionnent dans le graphe vers leur grille interne. Le SDK historique utilise TensorFlow Lite et Select TF Ops 2.16.1 ; le correctif Flex 16 Ko de Vision Dataset Studio est une livraison distincte, pas une qualification rétroactive de ce SDK.

Résultats documentés

Variante / Variant	Hôte / Host	SDK	Application / App
D-FINE M · learning	PASS	—	Non qualifié / Not qualified
DINOv3 pointing · learning	PASS	—	Non qualifié / Not qualified
RF-DETR Medium · learning	PASS	—	Non qualifié / Not qualified
RT-DETRv2 R50 · learning	PASS	—	Non qualifié / Not qualified
YOLO11 M	N/A	—	Non qualifié / Not qualified
YOLO11 M · learning	PASS	PASS	Non qualifié / Not qualified

Les rapports séparent fidélité de conversion, apprentissage synthétique sur hôte, SDK Android et intégration applicative. Rapport détaillé · Reçu de livraison · Sources de conversion.

Droits et utilisation responsable

Les poids, jeux de données et composants amont gardent leurs licences et restrictions propres. Lire les fichiers de droits et notices de chaque modèle ; la disponibilité au téléchargement n’accorde pas à elle seule un droit d’usage commercial. Aucun droit n’est élargi par cette documentation.

Les contrôles synthétiques montrent des mises à jour et leur persistance. Ils ne mesurent ni précision sur terrain, ni généralisation, ni capacité à déclencher une alerte fiable. La sélection finale exige un corpus autorisé représentatif, une revue humaine et des mesures sur l’appareil cible.

_{Documentation actualisée le 23 septembre 2026 · Preuves historiques conservées · Aucun poids modifié.}