libreyolo formats reports FP16/INT8 as available for combinations that export() rejects #951

What happened

libreyolo formats --family gtr --task semantic prints onnx ... FP16: True, INT8: True, but both model.export(format="onnx", half=True) and model.export(format="onnx", int8=True) raise on the same combination. The two fields are read from format-level class attributes (BaseExporter.supports_fp16 / supports_int8) and are never intersected with the family/task support table that decides tier, so they describe the format, not the combination.

The same output shows FP16: True, INT8: True on openvino and tensorrt while those rows are Tier: blocked, which is the same bug.

Reproduce

Query side (no weights needed):

libreyolo formats --family gtr --task semantic

Export side:

from libreyolo import LibreYOLO

model = LibreYOLO("LibreGTRs-sem.pt", device="cpu")
model.export(format="onnx", half=True)
model.export(format="onnx", int8=True, data="coco8.yaml")

Traceback / output

Command output:

  onnx
    Extension: .onnx, FP16: True, INT8: True
    Tier: available (Portable gated recurrence; the graph slides 1024px windows over a fixed canvas.)
    Constraint: FP32; static 1024x2048 canvas; images are letterboxed into it
  openvino
    Extension: _openvino, FP16: True, INT8: True
    Tier: blocked (GTR currently implements only portable ONNX and TorchScript export.)

Export side, with the raising frame for each:

ValueError: GTR portable export currently requires FP32
    raised at <repo>/libreyolo/models/gtr/model.py:780

NotImplementedError: ONNX INT8 export currently supports YOLO9 detection models only.
    raised at <repo>/libreyolo/export/exporter.py:1840

NotImplementedError: GTR currently exports to ONNX and TorchScript only
    raised at <repo>/libreyolo/models/gtr/model.py:774

Environment

libreyolo 1.6.0, Python 3.10.19, torch 2.11.0+cu128, onnxruntime 1.23.2 (CPU EP only), Windows 10.

Already tried

• Confirmed the fields come from class attributes, not the tier lookup: libreyolo/cli/commands/special.py:484-485 sets "int8": cls.supports_int8 / "fp16": cls.supports_fp16, while only tier / reason / constraint come from get_support(family, task, format).
• Confirmed the mismatch is not GTR-specific: the same command reports FP16: True for coreml and FP16: True, INT8: True for openvino and tensorrt, all Tier: blocked.
• Confirmed the two GTR gates are separate from the format table: FP16 is blocked by the family wrapper, INT8 by a hardcoded yolo9 / detect check inside the ONNX exporter's preflight.
• Searched existing issues for formats, supports_fp16, "YOLO9 detection models only": no duplicate (closest are Add Core ML export support #172 and 436 cleanup flagship models task variants that dont work well #438, unrelated).

Suggested fix

Either gate the two fields on tier != "blocked" (and on the family's own precision policy), or surface the precision the tier actually permits. The Constraint: FP32; ... line already carries the truth for GTR, so the FP16: True, INT8: True line printed next to it is actively contradictory.

Note that fixing this only for GTR would leave every other non-YOLO9 family equally misreported by the INT8 field.

Why this matters

formats is the discoverability surface for export capabilities, so a user picking a precision from it gets a hard error instead of an artifact. The FP32-vs-FP16 question is exactly what someone making a deployment decision asks first.