Compare loading a .wnft target against jsartoolkitNFT's .iset/.fset/.fset3

Why

#35 measured what compiling a target offline saves within this repository: on the pinball image, buildTargetFromImage costs ~84 ms and decode-ing the resulting .wnft costs ~0.40 ms — a factor of about 200. That answers "is a compiled target worth it?" but not the question anyone coming from the org's existing NFT stack will actually ask, which is how does .wnft compare with the format jsartoolkitNFT already ships?

Worth answering. Worth not answering badly, which is the point of this issue.

The trap: it is not a like-for-like comparison today

jsartoolkitNFT loads an NFT marker as a set of three files — .iset, .fset, .fset3 (per its README's Python-bindings section and emscripten/markerDecompress.h, whose markerContentStruct holds exactly those three payloads) — or as a single compressed .zft bundle of them.

A .wnft produced by compile-target today carries keypoints and descriptors only. patches and referenceImage are specified (§5.7, §5.8) but optional, and buildTargetFromImage does not fill them — they arrive with M4. If the three-file set also carries image data for the AR2/texture-tracking stage, then a straight "load one file vs load three" benchmark compares a file holding less against a file set holding more, and .wnft wins by construction. That number would be worse than useless: it would be quotable.

First task of this issue is therefore not a benchmark. It is establishing what each of the three files actually contains, from the WebARKitLib sources rather than from the names.

Verified starting point: bytes on disk

Same target image in both repositories (examples/DataNFT/pinball.* there, examples/targets/pinball.wnft here), so at least the input is not a variable:

Two things to note before anyone does arithmetic on that table:

• The .wnft row is not comparable to the total, for the reason above.
• pinball.zft is larger than the three files it bundles, while jsartoolkitNFT's README presents .zft as "faster loading times and reduced file sizes". That may be a stale artifact, a different compression level, or something the bundle carries that the loose files do not. It is an observation about committed file sizes, not a claim about the format — but it is worth resolving before anyone cites either number.

Three axes, which must not be mixed

1. Bytes transferred. The number a user actually feels on a slow connection. Nearly measurable today, once axis 0 (what is in each file) tells us which subsets to compare, and once counts are normalised — 2062 keypoints against whatever .fset3 holds is not a ratio, it is two unrelated numbers.
2. Parsing / load cost. Comparable only at parity of content: either after M4, when .wnft carries patches and a reference image too, or by isolating the stage that produces matchable descriptors on both sides.
3. Cost of getting into the WASM heap. jsartoolkitNFT's core is WebARKitLib compiled to WASM, so loading goes through Emscripten's virtual filesystem. That is a real cost for a real user, but it is a different kind of cost from parsing, and folding it into axis 2 would flatter whichever side runs in plain JavaScript.

Also worth stating plainly in whatever comes out of this: the two formats were designed for different tracker architectures. .wnft is not trying to be a better .fset3; a comparison is useful for sizing the gap M4 has to close, not for declaring a winner.

This is more tractable than it looks

Three things make a real, headless, reproducible benchmark possible rather than aspirational:

• jsartoolkitNFT ships a Node build (dist/ARToolkitNFT_node.js) and experimental Python bindings, so neither side needs a browser.
• Its own Node example already loads DataNFT/pinball — the same target image this repository's demos and fixtures use.
• Both sides can therefore be driven from one script on one machine, which is the only way the numbers mean anything.

Not scheduled

Nobody is working on this. Opened so the question has a home and so the framing above is written down before someone runs the easy, misleading version of the measurement.

Start by reading WebARKitLib sources and markerDecompress.h to establish what .iset, .fset, and .fset3 contain, then inspect dist/ARToolkitNFT_node.js and its Node example. Build a headless comparison using the pinball target from both repositories, keeping transferred bytes, parsing cost, and WASM-heap loading separate. Done means the content subsets are documented and the measurements are reproducible and comparable.