Upload README.md with huggingface_hub

README.md

@@ -26,12 +26,21 @@ decoder once per click.
 The encoder ships in fp32 only, and that is not an omission. Its backbone is RepViT,
 which is convolutional, and XNNPACK serializes convolution weights as fp32 whatever
 dtype the graph carries, so fp16 came out at 19.8 MB (100.5%) and buys nothing.
-Dynamic int8 is a different matter: it annotates `aten.linear` and this graph has
-none — all 50 nn.Linear in EdgeTAM sit in the mask decoder, not on the
-image-embedding path — so it leaves the encoder at the same 19.7 MB. Static int8 is
-the recipe that would reach convolution weights, and it has not been run here. At
-19.7 MB the fp32 encoder is already smaller than SAM 2.1 hiera-tiny's *fp16* encoder
-(55.6 MB).
+
+Both int8 recipes were measured. Dynamic int8 annotates `aten.linear` and this graph
+has none — all 50 nn.Linear in EdgeTAM sit in the mask decoder, not on the
+image-embedding path — so it leaves the encoder at the same 19.7 MB. Static int8 does
+reach convolution weights, and on paper it is the build you would want: **5.4 MB and
+24.7 ms** against fp32's 19.7 MB and 31.0 ms on the same machine. It is the masks that
+stop it. Feeding its embeddings to the same fp32 decoder, over 37 clicks the fp32 arm
+answered, the worst decoded mask comes back at **0.0185 IoU** against the fp32
+encoder's — the median holds at 0.887, but a build that loses the mask outright on
+some clicks is not one to publish. Measured with a global per-channel static
+configuration calibrated on ten photographs; a narrower annotation might do better and
+has not been tried.
+
+At 19.7 MB the fp32 encoder is already smaller than SAM 2.1 hiera-tiny's *fp16*
+encoder (55.6 MB).
 
 EdgeTAM is Meta's on-device SAM 2 (CVPR 2025). Its encoder is **5.5× smaller than
 SAM 2.1 hiera-tiny's** (19.7 MB vs 109.2 MB) for the same output contract, so an