One Piece card recognition (release B2.1)

Two small models that find trading cards in a frame of gameplay video and name them, for the One Piece Card Game. An unofficial fan project, not affiliated with or endorsed by Bandai or any publisher. Card names and card art belong to their owners. This model reads cards. It does not generate images, and no card art is included here.

These are the models of Kenbunshoku, a free Apache-2.0 Chrome extension that shows a card's official art when you rest the pointer on it in a YouTube or Twitch video. They were trained with the open-source cardvision toolkit (Python package cardvision, plus a TypeScript runtime for web pages, cardvision-browser). The toolkit is being released separately and is not public yet; Built on cardvision will link it when it is. The labels are in the companion dataset, kenbunshoku-onepiece-labels.

What is in this repository

Release B2.1 (f80d5b56cd907f03) differs from the evaluated release B2 (26a98a0f49a74545) in one catalog entry, OP09-051_p2 (its name, printing and facets corrected from an upstream metadata error), and so in bank.identity-groups.json, where that entry moves from the OP05-067 identity to the OP09-051 identity. The models, the bank vectors and the accept rule are byte-identical. B2.1's final recognition results were not remeasured; unchanged weights and bank vectors do not guarantee identical outputs after an identity-group correction (the held-out labels name neither card, but a changed identity can still be a candidate or runner-up on other cards). The figures below were measured on B2 and are labeled B2.

How it works

The detector finds each card in the frame. For every face it finds, the recognizer makes a vector, and the bank says which card is nearest. A name is shown only when the match is close enough (tau) and clear enough of the runner-up (delta). Otherwise nothing is shown. This is the same pipeline as the toolkit's other releases; the toolkit's docs/how-it-works.md will describe it in full when the toolkit is released.

How to load it

Today, there are two ways.

• In Chrome, on YouTube and Twitch videos: install Kenbunshoku, which ships this release. Its README has the install steps.
• With a standard ONNX runtime: detector.onnx and recognizer.onnx are plain ONNX files that load in ONNX Runtime (for example onnxruntime in Python, or ONNX Runtime Web) or any other ONNX runtime. release.json records the settings they run with: the detector's input size, letterbox, channel order and output columns, its score threshold and NMS, the recognizer's input size, and the accept rule. A few steps, such as the recognizer's crop preparation, are named there (full128) rather than spelled out: the runtime that Kenbunshoku ships implements them, and the toolkit's documentation will describe them. Download the files and check them against SHA256SUMS:

hf download JuicyKaraageNo1/kenbunshoku-onepiece --local-dir kenbunshoku-onepiece
cd kenbunshoku-onepiece
shasum -a 256 -c SHA256SUMS

(hf comes with pip install -U huggingface_hub; cloning the repository with git and git-lfs works too.)

When the toolkit is released, it will verify and run the release directly. These commands do not work yet, because the toolkit is not public:

cardvision verify-release kenbunshoku-onepiece/release.json
cardvision infer YOUR-VIDEO.mp4 --release kenbunshoku-onepiece/release.json --annotate annotated/

verify-release checks every pinned file. infer runs the detector, recognizer, bank and accept rule that release.json pins.

In a web page, the toolkit's browser runtime (cardvision-browser) loads the same release.json, runs both models on ONNX Runtime Web (WebGPU with a WebAssembly fallback), and answers which card is under the pointer. Kenbunshoku ships it as built modules today; its source comes with the toolkit release. release.json pins ONNX Runtime Web 1.29.0.

Training data

Counts only. No frame, image or card art is published with this model.

• Real labeled frames. 23 frames of public videos, from 12 recording groups, in two labeling sittings: 13 frames in the first and 10 in the second.
  • First sitting: 13 frames, 341 boxes.
  • Second sitting: 10 frames, 210 boxes.
  • Their labels are published as manifests in the companion dataset. The frames are not. The manifests list each frame's video id and time today; the toolkit's fetch tool, coming with the toolkit release, will obtain the frames from the public videos.
• Generated scenes. 8,000 scenes made by cardvision make-composites from official card art, which is not included here. The scenes show 5,489 different cards, with 93,790 positive faces and 15,538 backs.
• Card images. The recognizer was trained on, and the bank was computed from, 5,489 official card images that are not included.
• Card-free images (detector). 183 CC0 table-surface scans, which show no cards.
• Detector run. 500 steps of 16 images, starting from YOLOX-Nano pretrained on COCO.
• Recognizer run. 34 epochs of 788 steps at batch 256, 201,740 rows per epoch; the released checkpoint is epoch 30.
• Cards held out of training. 200 printings were kept out of the recognizer's training, to check that a card known only from its image can be found.
• Three more frames from each sitting (six in all) came from three recording groups held out of training. They informed the choice between two candidate models and are not part of the held-out evaluation below.

Held-out evaluation

This is the figure to read, with its size beside it. All held-out figures here were computed with the toolkit's Python package; the browser extension was not tested on the held-out set (see "Python and the browser" below).

The set. 25 frames of 13 videos from 9 recording groups, none of which was in training. It was labeled by position: a person marked the center of every card, and labeled what lies under a seeded set of 100 random points, most of them off the cards. It holds 2 digital recording groups and 7 physical ones (4 webcam or phone, 3 tournament). Its labels are published as the evaluation manifests of the companion dataset. It holds 572 input hover events (472 marked centers and 100 seeded points). For B2, 540 of them are scored: 297 readable faces, 164 backs and 79 off-card positions. The other 32 are outside every rate (1 face labeled unreadable, 30 faces nobody could name, 1 unreadable point). The arms on the older catalog have 571 input events and 539 scored ones, because the one Japanese-printing face (below) is not in that catalog.

The measure. The unit is a hover event: the pointer rests on a position and the system either names a card or shows nothing.

• Named right is right over (right + wrong + nothing), on readable faces.
• Wrong of shown is the number of incorrect names divided by all names shown on scorable events: readable labeled faces, card backs and off-card positions. The 32 unknown/unreadable events are excluded from both numerator and denominator, even if a name was shown there (B2 showed a name on 5 of them). One more exclusion: a name shown on an off-card position just beside a labeled face of that same card (its center inside the shown box) counts in neither rate (B2: 1).

Each arm ran with the accept rule in accept.json (tau 0.62, delta 0.05), not tuned for this game. Intervals are 95% paired or unpaired group-bootstrap intervals over recording groups, 10,000 resamples, seed 0. With 9 groups the intervals are wide, and a percentile bootstrap over so few groups tends to run narrow, so they are if anything optimistic. Read the figures as a rough scale, not as precise rates. One digital recording group holds 135 of the 297 readable faces; the overall figures lean on it.

All events

The arms on the older catalog score 296 readable faces and B2 scores 297, because one face is a Japanese printing that only the newer catalog has. Its inclusion is not a claim of Japanese-card support. The paired comparison of B2 with the baseline is scored on the older catalog, so it counts B2's wrong names as 9 of 229 shown (3.93%).

Physical and digital

Digital figures rest on 2 recording groups and carry no interval. B2 names 54.8% right on physical play and 88.4% on digital, a gap of 33.6 points. The two digital groups range from 86.7% to 94.7%, which is a range, not an interval.

Without DON!! cards

DON!! cards are the game's energy cards. Leaving them out, B2 names 193/256 = 75.4% [50.3%, 84.8%] right and shows 9/202 = 4.5% [1.9%, 13.6%] wrong of shown. Physical play without DON!!: 60/106 = 56.6% [37.8%, 72.7%] named right and 7/67 = 10.4% [3.6%, 23.3%] wrong of shown. Digital without DON!!: 133/150 = 88.7% named right and 2/135 = 1.5% wrong of shown, counts only. For the baseline, the same slice was 84/255 = 32.9% named right.

Paired comparisons

These were written down and frozen (sha256-pinned) in the maintainers' private records on 2026-10-16, before any held-out frame was scored; this is an internal, timestamped plan, not a public pre-registration. They are reported as computed. Each bound below is an end of the paired group-bootstrap 95% interval of the difference (candidate minus base).

• B2 against the baseline, overall. Named right is higher by 42.91 points, lower bound +22.42; wrong of shown is lower by 6.65 points, upper bound -1.15.
• B2 against the baseline, physical only (7 groups). Named right higher by 26.02 points, lower bound +14.41; wrong of shown lower by 12.76 points, upper bound -0.08.
• The registered claim that training on this game's own labels beats the stock models required, on both slices above, a named-right lower bound above 0 and a wrong-of-shown upper bound of at most +2.0 points. It passed. Read it with this beside it: the baseline showed a name on only 104 of the 571 events it was scored on, and a gain over a model that names little is to be read with that in view.
• B2 with the geometric stage against B2, overall. Named right higher by 9.43 points, lower bound +6.65; wrong of shown lower by 1.18 points, upper bound +0.42.
• The same, physical only. Named right higher by 12.90 points, lower bound +6.60; wrong of shown lower by 2.67 points, upper bound +0.65.
• The registered rule for the geometric stage (overall; the physical line is reported, not part of it) required a named-right lower bound above 0 and a wrong-of-shown upper bound of at most +1.0 point. It passed. Correct naming increased; wrong of shown was lower in the point estimate, but its interval also permits a small increase (upper bound +0.42 points overall, +0.65 physical).
• A2 against B2 (reported only). Named right differs by +0.34 points, lower bound -0.99: the two are not separated. B2 was made the default before the test, on the six development frames, by a narrow margin; nothing here shows it better than A2.
• The accept rule recalibrated on the 23 training frames (tau 0.60, delta 0.07), reported only: 226/297 = 76.1% [54.5%, 84.4%] named right and 14/240 = 5.8% [2.2%, 17.3%] wrong of shown. The released rule stays.

The optional geometric stage

After the recognizer picks its best few cards, the toolkit can look at them again by matching local keypoints against the card art. In the Python package it is off by default; it is not part of the release document (release.json), and without the --geometric flag nothing changes. Its settings and a keypoint index built for this bank were fixed before the held-out frames were scored. The settings are those Kenbunshoku bundles as data/geometric.json (ORB features on art scaled to 160 px on the long side, at most 300 per card and 500 per crop, the 10 nearest cards by embedding re-checked, affine RANSAC, fusion weight 1.5 from 15 inliers); the held-out run used the same settings with the keypoint index file orb160-r2-B2.features.json (sha256 cd676903704f456de1790e58d6a2d8941f873c6a5ba548a6ad258c48c13ad4be), built for this bank. The browser loads the same keypoints repacked, through an index manifest with sha256 7b9a96f636611e34183b1a845db93846cb92e5d12ad0d273dd14d1e2c60cef19. Building the index needs the card art, which is not included, and the geometric extra of the toolkit. The held-out result is in the tables above and in the paired comparison with B2.

Python and the browser. The held-out geometric-stage results above were measured in Python. The toolkit's browser runtime has a port of the stage, which runs only with WebGPU. The browser implementation was compared with Python, with this release and these settings, in Chrome, on development data only (394 generated scenes and the 23 training frames), not on the held-out set, under a rule frozen in the maintainers' private records before the run. On generated development scenes, named-right rates were 74.76% in both implementations (difference +0.00 points, 95% interval -0.33 to +0.34); wrong-of-shown was 3.07% in Python and 2.94% in the browser (-0.13 points, -0.50 to +0.20). On the 23 training frames, named right was 94.08% in both. On the faces whose grayscale input was byte-identical on both sides, all 622 final hover answers agreed. However, the stricter pre-registered intermediate-parity check did not pass: vote-count and match agreement were 78.04% and 91.17%, below the 95% requirement. The maintainer chose to enable the browser stage on WebGPU despite that failed check, and Kenbunshoku, the browser extension built on this release, turns it on where WebGPU runs. These development results do not establish the browser extension's held-out accuracy. A diagnostic of the recorded evidence found the vote and match differences only on faces whose ORB descriptors differ between the native OpenCV build and OpenCV.js (on the 48 faces with identical descriptors, votes and matches were 100% identical). On 12 of those faces examined in detail, the cause was ORB's keypoint angle, which the two builds compute differently by under 0.01 degrees; that flips 1 to 5 descriptor bits on about 1% of keypoints. The cause is shown for those 12 faces and is the working explanation for the rest.

Limitations

• A small evaluation set with wide intervals. 25 frames, 13 videos, 9 recording groups, 2 of them digital. Whether two arms differ is read from the paired interval of their difference (under Paired comparisons), not from whether their separate intervals overlap.
• Physical play is clearly below digital. B2 names 54.8% right on physical play against 88.4% on digital. Webcam and phone footage is the hardest slice.
• SAMPLE-stamped cards. Most reference images for set and starter cards, which the bank was built from, carry a large pale "SAMPLE" overprint, and so do some cards in the held-out digital footage. A card shown without the overprint can behave differently. On the held-out digital footage, an automatic check found the overprint on 18 of 168 readable faces: B2 named 15/18 = 83.3% of them right and 134/150 = 89.3% of the others. Counts only, with no claim of cause: in a spot check of the automatic check, 8 of 10 overprint marks were right (the other two belonged to a neighboring card), and 16 of the 18 are in one recording group.
• DON!! cards and their variants. The game's DON!! cards come in many art variants that count as one identity, and they are 40 of the 283 readable faces whose center a person marked. Figures with and without DON!! are both given above.
• Tournament footage from the game's publisher is in both the training and the held-out sources (different recordings). On its held-out faces B2 named 22/28 right; on the other tournament's, 7/16 (counts only).
• Promotional cards. Coverage is incomplete. In an earlier catalog, 152 promo printings had no usable image; such cards are recognized only through another printing of the same card in the bank.
• Cards without art. 13 catalog cards (the promotional cards P-122 to P-134) have no art and are not in the bank. None of them has another printing in the catalog, so this release does not recognize them.
• Incorrect matches remain possible, especially on difficult physical footage. On held-out physical play, 7 of the 75 names B2 showed were wrong. Do not use the output to rule on a game, judge a player, or as evidence of what happened in a match.
• Cards from unreleased sets. In a diagnostic on 184 faces of about 25 EB-05 cards revealed before their release (not in the catalog; from one deck-builder stream), B2 with the geometric stage, in Python, gave a wrong name to 29 of the 184 faces (10 different cards) and showed nothing on 155. That is 15.8% of those faces, not a wrong-of-shown rate. The faces cluster in one source, so read it as a warning, not a rate.
• Not for identifying people, counting cards over time, telling real cards from counterfeits, or grading condition.
• One game. The bank holds this game's cards only. Cards of another game are out of scope: they may be named nothing, but they can also be matched wrongly to a card of this game.

License

The model weights, the bank and the release document are released under Apache-2.0 (LICENSE). The bank is a set of vectors computed from card images; the images themselves belong to their owners and are not included. The labels in the companion dataset are CC BY 4.0.

Citation

@misc{kenbunshoku_onepiece_b2_1,
  title        = {Kenbunshoku One Piece card recognition models, release B2.1 (id f80d5b56cd907f03)},
  author       = {{The Kenbunshoku authors}},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/JuicyKaraageNo1/kenbunshoku-onepiece}}
}

A citation for the cardvision toolkit will come with its release.