Added OpenTag3D parsing (v2.0) - #27
thekakester wants to merge 1 commit into
Conversation
Tested by reading real tags from Polar Filament Added test cases using dumps from a real tag and the expected parsed output. Implemented using the OpenTag3D spec.json file to make future updates easier. The spec.json file defines all the parameters, data types, parsing info, etc. Dropping in a new spec.json file for future versions should automatically bring this up to date (unless the schema format changes).
|
@suchmememanyskill any timeline on this being merged? I'm adding support to paxx12 u1 for opentag3d, and it looks like this would take care of most of it. |
|
For context: I implemented an OpenTag3D processor for the Snapmaker U1 extended firmware overlay (paxx12-snapmaker-u1/SnapmakerU1-Extended-Firmware), carried as a local patch against a pinned OpenRFID. Once this merges I'd rather delete mine and depend on yours. Comparing the two, there are a few things mine handles that this doesn't, and I'd rather contribute them upstream than keep carrying a fork. v1 memory map. SCHEMAS.get(version // 1000) returns None for v1, and the comment notes it's pending. I have a v1 map validated field by field against the published spec.json at v1.003, including the manufacturer gap at 0x1B. As a schemas/v1.json it should drop into your decoder without touching the processor. I only have v2.001 tags in hand (Polar Filament), so the v1 map is spec-validated rather than hardware-tested — worth stating plainly. Four defensive cases in __to_filament. None of these change behaviour for a well-formed tag; they only matter for partially written ones, which we do see in the wild: A zero alpha byte almost always means "never written" rather than "transparent". Keeping it produces a fully transparent primary colour, which downstream of us becomes an ARGB value with alpha 0 and renders invisible. Forcing 0xFF when alpha is 0 fixed that. One thing yours does better than mine, for the record: deriving unique_id from the tag UID rather than from a content hash. Mine collides across two physically distinct but identical spools; yours doesn't. I'll be adopting that. Happy to send these as a PR against your branch now, or as a follow-up after this merges — whichever you prefer. |
Tested by reading real tags from Polar Filament
Added test cases using dumps from a real tag and the expected parsed output.
Implemented using the OpenTag3D spec.json file to make future updates easier. The spec.json file defines all the parameters, data types, parsing info, etc. Dropping in a new spec.json file for future versions should automatically bring this up to date (unless the schema format changes).