npm - @ar-js-org/artoolkit5-ts - Versions diffs - 0.2.1 → 0.2.2 - Mend

@ar-js-org/artoolkit5-ts 0.2.1 → 0.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (4) hide show

package/CHANGELOG.md CHANGED Viewed

@@ -1,224 +1,243 @@
-# Changelog
-All notable changes to this project are documented in this file.
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
-and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-## [Unreleased]
-## [0.2.1] - 2026-09-19
-### Added
-- `MarkerPose.vertex` — the four corners of the detected square, in camera
-  image coordinates with the origin at top-left. Closes #54.
-  The WASM binding already returned these; only the TypeScript types and
-  `processFrame` did not carry them through, so no rebuild of
-  `@ar-js-org/artoolkit5-wasm` was needed. `MarkerInfo.vertex` is declared
-  for the same reason.
-  Unlike `matrix` and `matrixGL`, which are views onto buffers reused every
-  frame, `vertex` is freshly allocated per frame and is safe to retain
-  without copying. Corner order depends on the marker's rotation —
-  `vertex[(4 - dir) % 4]` is the marker's top-left corner, the rest clockwise
-  from there — which matters for anything orientation-sensitive and not at all
-  for outlining the square.
-  Corners let a consumer draw a marker outline, hit-test or build an occlusion
-  mask without needing the camera projection matrix at all.
-### Changed
-- `MarkerInfo` gained `vertex` as a **required** field. Nothing in the
-  library constructs a `MarkerInfo` — they come from the WASM binding, which
-  already supplied corners — but a hand-written `ARToolKitCore` double in a
-  consumer's tests now fails to typecheck until it supplies four points.
-- Lockfile moved onto `@ar-js-org/artoolkit5-constants` 0.3.1, whose published
-  metadata now correctly declares MIT rather than GPL-3.0. No code changed
-  upstream; only the declaration was wrong. Closes #53.
-## [0.2.0] - 2026-09-17
-### Upgrading from 0.1.0
-Three changes need action. Each is described in full further down; this is the
-short list for anyone upgrading.
-1. **`state.markers` is gone**, replaced by `state.patternMarkers` and
-   `state.barcodeMarkers`. Read the one matching the family you registered.
-2. **`FrameResult.lost` now holds objects, not numbers** — `LostMarker`
-   (`{ id, type }`) rather than a bare ID. This is the one to look for: it does
-   not throw, so `lost.forEach((id) => hide(id))` keeps running and silently
-   stops matching anything. Use `lost.forEach(({ id }) => hide(id))`, and note
-   that `id` alone is no longer unique across families.
-3. **Several `configureDetector` option values were respelled** — see the table
-   under Changed. TypeScript catches these; plain JavaScript gets a thrown
-   `ARToolKitError` naming the option and listing the valid values.
-### Added
-- `configureDetector(state, opts)` — detector tuning: `detectionMode`, `matrixCodeType`,
-  `threshold`, `thresholdMode`, `labelingMode`, `imageProcMode`, `patternRatio`,
-  `nearPlane`, `farPlane`, and `minConfidence` (described below). Applies only the
-  keys present, so a later call can adjust a single setting mid-session.
-- `@ar-js-org/artoolkit5-constants` as a direct dependency (`^0.3.0`). All ARToolKit5
-  integers used internally come from it — `src/config.ts` is the only module in
-  the codebase that imports one.
-- `trackBarcodeMarker(state, barcodeId, markerWidth?)` — registers a barcode
-  (matrix code) marker. Unlike a pattern marker there is nothing to load first:
-  the ID is encoded in the marker's geometry, not assigned by the engine.
-- `MarkerType` (`'pattern' | 'barcode'`) on `MarkerPose`, and `LostMarker`
-  (`{ id, type }`) as the element type of `FrameResult.lost`.
-- **Independent ID spaces for the two marker families.** `ARToolKitState` now holds
-  separate `patternMarkers` and `barcodeMarkers` registries instead of a single
-  `markers` map, so a pattern marker and a barcode marker may both be registered
-  as `7` and tracked simultaneously. Pattern IDs are engine-assigned from 0 while
-  barcode IDs are chosen by whoever printed the marker, so collisions are ordinary
-  rather than exceptional — `patt.hiro` is ID `0`. The engine reports each family
-  through its own field (`idPatt` / `idMatrix`), and each is matched only against
-  its own registry. This mirrors `artoolkit5-js`, which has kept the two separate
-  all along. ([#36](https://github.com/AR-js-org/artoolkit5-ts/issues/36))
-- **Combined pattern+barcode detection.** `'color_and_matrix'` and `'mono_and_matrix'` detect
-  both marker families in a single frame, verified against a real camera rather than a
-  mock. This required a fix in the WASM binding, which exposed only a field the engine
-  leaves unassigned in those modes
-  ([artoolkit5-wasm#23](https://github.com/AR-js-org/artoolkit5-wasm/issues/23)); see
-  `docs/DESIGN-detector-and-barcode.md` §9 for the full analysis. `examples/barcode/`
-  gained a detection-mode switcher and a per-frame detection log demonstrating it.
-- **Match confidence, and a per-family `minConfidence` filter.** `MarkerPose` gains
-  `confidence` (0–1, read from the matching family's own `cfPatt`/`cfMatrix`), and
-  `configureDetector` gains `minConfidence: { pattern?, barcode? }`.
-  Unlike every other detector option this one never reaches the engine: ARToolKit's
-  confidence cutoff is a compile-time constant with no setter, so the threshold is
-  applied by `processFrame` and can only ever be stricter than the built-in 0.5.
-  The families take separate thresholds because their confidences are not comparable,
-  and **both default to `0`** — nothing is filtered unless you ask for it. Measured on a
-  real camera, the genuine and false ranges overlap for both families: a genuine pattern
-  match scored `0.506` against a false one at `0.554`, and a genuine barcode scored
-  `0.500` at an awkward angle while a phantom barcode reached `0.867`. The same barcode
-  marker ranged `0.500`–`0.967` across viewing angles. Confidence is a continuous quality
-  score for both families rather than a verdict, so no threshold avoids both missed
-  markers and admitted phantoms; the README documents the measurements and the trade-off.
-  ([#38](https://github.com/AR-js-org/artoolkit5-ts/issues/38))
-- `examples/barcode/`, tracking a 3x3 matrix code marker. `examples/index.html`
-  now links to both examples.
-### Changed
-- **`configureDetector`'s option values now use spellings also used by AR.js.** This is a
-  deliberate public-vocabulary choice; the `artoolkit5-js` peer exposes raw numeric modes
-  rather than these strings:
-  | was | now |
-  |---|---|
-  | `'color+matrix'` | `'color_and_matrix'` |
-  | `'mono+matrix'` | `'mono_and_matrix'` |
-  | `'black-region'` / `'white-region'` | `'black_region'` / `'white_region'` |
-  | `'auto-median'` / `'auto-otsu'` / `'auto-bracketing'` | `'auto_median'` / `'auto_otsu'` / `'auto_bracketing'` |
-  | `'3x3_hamming63'`, `'4x4_bch_13_9_3'`, … | `'3x3_HAMMING63'`, `'4x4_BCH_13_9_3'`, … |
-  | option `pattRatio` | option `patternRatio` |
-  `'matrix'` keeps its name — AR.js exposes no equivalent. `thresholdMode` and
-  `imageProcMode` have no AR.js counterpart at all, so their values simply follow
-  the same snake_case convention for internal consistency.
-  This deliberately inherits one wart from AR.js: snake_case for mode names but
-  SCREAMING_SNAKE for matrix algorithm suffixes. Matching the ecosystem was judged
-  worth more than tidiness in isolation. ([#34](https://github.com/AR-js-org/artoolkit5-ts/issues/34))
-- **`FrameResult.lost` is now `LostMarker[]` rather than `number[]`.** It carries
-  `type` alongside `id` because the two families have independent ID spaces, so an
-  ID on its own can no longer say which marker disappeared. Unlike the respellings
-  above this one is silent in plain JavaScript — the array is still iterable and
-  still the right length, the elements are simply objects now.
-- Depends on `@ar-js-org/artoolkit5-wasm@^0.3.0`, up from `^0.1.3`. `0.3.0` is required,
-  not merely preferred: it is the first release to bind `idPatt`/`idMatrix`, without
-  which the combined detection modes silently report nothing or the wrong marker.
-### Removed
-- **`ARToolKitState.markers`**, replaced by the `patternMarkers` and `barcodeMarkers`
-  registries described under Added. There is no combined view: the two families have
-  independent ID spaces, so merging them back into one map is exactly the collision
-  the split exists to prevent.
-### Notes
-`thresholdMode: 'auto_adaptive'` is not offered: the WebARKitLib build this
-library ships compiles that mode's implementation out, and passing it would
-silently degrade to `'manual'`.
-`matrixCodeType: 'global_id'` is not offered either. The engine decodes that
-mode into `markerInfo->globalID`, a 64-bit field the WASM binding does not
-expose ([artoolkit5-wasm#29](https://github.com/AR-js-org/artoolkit5-wasm/issues/29)),
-so nothing here can read the result. Worse than unreadable, it would alias:
-the engine also reports the code through `idMatrix`, where a global ID below
-32768 arrives as itself but every larger one arrives as `0`. A barcode
-registered as `0` would match every large global-ID marker in view. Re-adding
-the option once the field is bound is a non-breaking addition.
-([#41](https://github.com/AR-js-org/artoolkit5-ts/issues/41))
-## [0.1.0] - 2026-08-16
-### Added
-- `createARToolKitState` / `disposeARToolKitState` — lifecycle. Dispose calls
-  the core's `teardown()` and then Embind's `delete()`; skipping the first leaks
-  the ARToolKit handles the instance owns. Idempotent.
-- `ARToolKitError`, thrown by every operation called on a disposed state, so a
-  use-after-dispose names the misused function instead of crashing somewhere
-  inside the WASM module.
-- `loadPatternMarker` and `trackMarker` for registering markers.
-- `processFrame`, returning `{ detected, lost }`.
-- `getCameraProjectionMatrix`, `transMatToGLMat` and `arglCameraViewRHf`.
-- Vitest suite covering the matrix maths, the visibility state machine and the
-  dispose lifecycle, running without WASM or a browser against a mocked core.
-- CI on Node 22 and 24: typecheck, test, build, and a packaging check.
-- Release workflow, run manually with a version. It runs the checks, sets the
-  version, promotes this changelog, derives notes from the commits, tags,
-  creates the GitHub Release and publishes to npm with provenance. A `dry_run`
-  input rehearses all of it without tagging or publishing.
-- `scripts/release-notes.mjs`, which groups Conventional Commits since the
-  previous tag so release notes reflect what actually landed, and
-  `scripts/promote-changelog.mjs`, which promotes the Unreleased section.
-- Webcam example: camera to Three.js cube overlay.
-- This changelog.
-### Changed
-- `processFrame` returns `{ detected, lost }` rather than `MarkerPose[]`. The
-  visibility transition was already computed internally and then discarded,
-  forcing consumers to diff successive results to recover it.
-- Named `@ar-js-org/artoolkit5-ts`, matching the rest of the organisation.
-- Depends on `@ar-js-org/artoolkit5-wasm@^0.1.3` from npm rather than a pinned
-  git commit. `three` moved to `devDependencies`; only the examples use it.
-### Fixed
-- `arglCameraViewRHf` allocated a `Float64Array` while every type declaration
-  promised `Float32Array`. Consumers reading `matrixGL` would have received a
-  different array type than the published types described, and the AR.js-next
-  marker event contract specifies `Float32Array(16)`.
-- `processFrame` allocated roughly three typed arrays per marker per frame. Both
-  matrix helpers now write into caller-supplied buffers, with one module-scoped
-  scratch array for the intermediate 4×4.
-- Debug logging removed from `src/`, which dumped the entire WASM module to the
-  console on every marker load and every `trackMarker` call.
-- `favicon.svg` and orphaned `.d.ts.map` files no longer ship in the package.
-### Notes
-Pattern markers only. Barcode support is planned; NFT is out of scope for this
-project. Worker compatibility is untested — nothing in `src/` touches the DOM,
-which is necessary but not proof.
-[Unreleased]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.2.1...HEAD
-[0.2.1]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.2.0...v0.2.1
-[0.2.0]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.1.0...v0.2.0
-[0.1.0]: https://github.com/AR-js-org/artoolkit5-ts/releases/tag/v0.1.0
+# Changelog
+All notable changes to this project are documented in this file.
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+## [Unreleased]
+## [0.2.2] - 2026-09-19
+### Changed
+- Releases now publish to npm through trusted publishing (OIDC) rather than an
+  automation token. For consumers the visible effect is that the published
+  package carries a provenance attestation again, verifiable with
+  `npm view @ar-js-org/artoolkit5-ts@<version> dist.attestations`.
+  0.2.0 and 0.2.1 have no attestation. The package requires 2FA to publish,
+  which rejects automation tokens, so the workflow's publish step failed on
+  both and each was completed by hand — and npm only generates provenance from
+  a supported CI provider. 0.1.0, published from CI before that setting
+  changed, does have one.
+  Nothing in the library changed. The code published as 0.2.2 is the code
+  published as 0.2.1.
+## [0.2.1] - 2026-09-19
+### Added
+- `MarkerPose.vertex` — the four corners of the detected square, in camera
+  image coordinates with the origin at top-left. Closes #54.
+  The WASM binding already returned these; only the TypeScript types and
+  `processFrame` did not carry them through, so no rebuild of
+  `@ar-js-org/artoolkit5-wasm` was needed. `MarkerInfo.vertex` is declared
+  for the same reason.
+  Unlike `matrix` and `matrixGL`, which are views onto buffers reused every
+  frame, `vertex` is freshly allocated per frame and is safe to retain
+  without copying. Corner order depends on the marker's rotation —
+  `vertex[(4 - dir) % 4]` is the marker's top-left corner, the rest clockwise
+  from there — which matters for anything orientation-sensitive and not at all
+  for outlining the square.
+  Corners let a consumer draw a marker outline, hit-test or build an occlusion
+  mask without needing the camera projection matrix at all.
+### Changed
+- `MarkerInfo` gained `vertex` as a **required** field. Nothing in the
+  library constructs a `MarkerInfo` — they come from the WASM binding, which
+  already supplied corners — but a hand-written `ARToolKitCore` double in a
+  consumer's tests now fails to typecheck until it supplies four points.
+- Lockfile moved onto `@ar-js-org/artoolkit5-constants` 0.3.1, whose published
+  metadata now correctly declares MIT rather than GPL-3.0. No code changed
+  upstream; only the declaration was wrong. Closes #53.
+## [0.2.0] - 2026-09-17
+### Upgrading from 0.1.0
+Three changes need action. Each is described in full further down; this is the
+short list for anyone upgrading.
+1. **`state.markers` is gone**, replaced by `state.patternMarkers` and
+   `state.barcodeMarkers`. Read the one matching the family you registered.
+2. **`FrameResult.lost` now holds objects, not numbers** — `LostMarker`
+   (`{ id, type }`) rather than a bare ID. This is the one to look for: it does
+   not throw, so `lost.forEach((id) => hide(id))` keeps running and silently
+   stops matching anything. Use `lost.forEach(({ id }) => hide(id))`, and note
+   that `id` alone is no longer unique across families.
+3. **Several `configureDetector` option values were respelled** — see the table
+   under Changed. TypeScript catches these; plain JavaScript gets a thrown
+   `ARToolKitError` naming the option and listing the valid values.
+### Added
+- `configureDetector(state, opts)` — detector tuning: `detectionMode`, `matrixCodeType`,
+  `threshold`, `thresholdMode`, `labelingMode`, `imageProcMode`, `patternRatio`,
+  `nearPlane`, `farPlane`, and `minConfidence` (described below). Applies only the
+  keys present, so a later call can adjust a single setting mid-session.
+- `@ar-js-org/artoolkit5-constants` as a direct dependency (`^0.3.0`). All ARToolKit5
+  integers used internally come from it — `src/config.ts` is the only module in
+  the codebase that imports one.
+- `trackBarcodeMarker(state, barcodeId, markerWidth?)` — registers a barcode
+  (matrix code) marker. Unlike a pattern marker there is nothing to load first:
+  the ID is encoded in the marker's geometry, not assigned by the engine.
+- `MarkerType` (`'pattern' | 'barcode'`) on `MarkerPose`, and `LostMarker`
+  (`{ id, type }`) as the element type of `FrameResult.lost`.
+- **Independent ID spaces for the two marker families.** `ARToolKitState` now holds
+  separate `patternMarkers` and `barcodeMarkers` registries instead of a single
+  `markers` map, so a pattern marker and a barcode marker may both be registered
+  as `7` and tracked simultaneously. Pattern IDs are engine-assigned from 0 while
+  barcode IDs are chosen by whoever printed the marker, so collisions are ordinary
+  rather than exceptional — `patt.hiro` is ID `0`. The engine reports each family
+  through its own field (`idPatt` / `idMatrix`), and each is matched only against
+  its own registry. This mirrors `artoolkit5-js`, which has kept the two separate
+  all along. ([#36](https://github.com/AR-js-org/artoolkit5-ts/issues/36))
+- **Combined pattern+barcode detection.** `'color_and_matrix'` and `'mono_and_matrix'` detect
+  both marker families in a single frame, verified against a real camera rather than a
+  mock. This required a fix in the WASM binding, which exposed only a field the engine
+  leaves unassigned in those modes
+  ([artoolkit5-wasm#23](https://github.com/AR-js-org/artoolkit5-wasm/issues/23)); see
+  `docs/DESIGN-detector-and-barcode.md` §9 for the full analysis. `examples/barcode/`
+  gained a detection-mode switcher and a per-frame detection log demonstrating it.
+- **Match confidence, and a per-family `minConfidence` filter.** `MarkerPose` gains
+  `confidence` (0–1, read from the matching family's own `cfPatt`/`cfMatrix`), and
+  `configureDetector` gains `minConfidence: { pattern?, barcode? }`.
+  Unlike every other detector option this one never reaches the engine: ARToolKit's
+  confidence cutoff is a compile-time constant with no setter, so the threshold is
+  applied by `processFrame` and can only ever be stricter than the built-in 0.5.
+  The families take separate thresholds because their confidences are not comparable,
+  and **both default to `0`** — nothing is filtered unless you ask for it. Measured on a
+  real camera, the genuine and false ranges overlap for both families: a genuine pattern
+  match scored `0.506` against a false one at `0.554`, and a genuine barcode scored
+  `0.500` at an awkward angle while a phantom barcode reached `0.867`. The same barcode
+  marker ranged `0.500`–`0.967` across viewing angles. Confidence is a continuous quality
+  score for both families rather than a verdict, so no threshold avoids both missed
+  markers and admitted phantoms; the README documents the measurements and the trade-off.
+  ([#38](https://github.com/AR-js-org/artoolkit5-ts/issues/38))
+- `examples/barcode/`, tracking a 3x3 matrix code marker. `examples/index.html`
+  now links to both examples.
+### Changed
+- **`configureDetector`'s option values now use spellings also used by AR.js.** This is a
+  deliberate public-vocabulary choice; the `artoolkit5-js` peer exposes raw numeric modes
+  rather than these strings:
+  | was | now |
+  |---|---|
+  | `'color+matrix'` | `'color_and_matrix'` |
+  | `'mono+matrix'` | `'mono_and_matrix'` |
+  | `'black-region'` / `'white-region'` | `'black_region'` / `'white_region'` |
+  | `'auto-median'` / `'auto-otsu'` / `'auto-bracketing'` | `'auto_median'` / `'auto_otsu'` / `'auto_bracketing'` |
+  | `'3x3_hamming63'`, `'4x4_bch_13_9_3'`, … | `'3x3_HAMMING63'`, `'4x4_BCH_13_9_3'`, … |
+  | option `pattRatio` | option `patternRatio` |
+  `'matrix'` keeps its name — AR.js exposes no equivalent. `thresholdMode` and
+  `imageProcMode` have no AR.js counterpart at all, so their values simply follow
+  the same snake_case convention for internal consistency.
+  This deliberately inherits one wart from AR.js: snake_case for mode names but
+  SCREAMING_SNAKE for matrix algorithm suffixes. Matching the ecosystem was judged
+  worth more than tidiness in isolation. ([#34](https://github.com/AR-js-org/artoolkit5-ts/issues/34))
+- **`FrameResult.lost` is now `LostMarker[]` rather than `number[]`.** It carries
+  `type` alongside `id` because the two families have independent ID spaces, so an
+  ID on its own can no longer say which marker disappeared. Unlike the respellings
+  above this one is silent in plain JavaScript — the array is still iterable and
+  still the right length, the elements are simply objects now.
+- Depends on `@ar-js-org/artoolkit5-wasm@^0.3.0`, up from `^0.1.3`. `0.3.0` is required,
+  not merely preferred: it is the first release to bind `idPatt`/`idMatrix`, without
+  which the combined detection modes silently report nothing or the wrong marker.
+### Removed
+- **`ARToolKitState.markers`**, replaced by the `patternMarkers` and `barcodeMarkers`
+  registries described under Added. There is no combined view: the two families have
+  independent ID spaces, so merging them back into one map is exactly the collision
+  the split exists to prevent.
+### Notes
+`thresholdMode: 'auto_adaptive'` is not offered: the WebARKitLib build this
+library ships compiles that mode's implementation out, and passing it would
+silently degrade to `'manual'`.
+`matrixCodeType: 'global_id'` is not offered either. The engine decodes that
+mode into `markerInfo->globalID`, a 64-bit field the WASM binding does not
+expose ([artoolkit5-wasm#29](https://github.com/AR-js-org/artoolkit5-wasm/issues/29)),
+so nothing here can read the result. Worse than unreadable, it would alias:
+the engine also reports the code through `idMatrix`, where a global ID below
+32768 arrives as itself but every larger one arrives as `0`. A barcode
+registered as `0` would match every large global-ID marker in view. Re-adding
+the option once the field is bound is a non-breaking addition.
+([#41](https://github.com/AR-js-org/artoolkit5-ts/issues/41))
+## [0.1.0] - 2026-08-16
+### Added
+- `createARToolKitState` / `disposeARToolKitState` — lifecycle. Dispose calls
+  the core's `teardown()` and then Embind's `delete()`; skipping the first leaks
+  the ARToolKit handles the instance owns. Idempotent.
+- `ARToolKitError`, thrown by every operation called on a disposed state, so a
+  use-after-dispose names the misused function instead of crashing somewhere
+  inside the WASM module.
+- `loadPatternMarker` and `trackMarker` for registering markers.
+- `processFrame`, returning `{ detected, lost }`.
+- `getCameraProjectionMatrix`, `transMatToGLMat` and `arglCameraViewRHf`.
+- Vitest suite covering the matrix maths, the visibility state machine and the
+  dispose lifecycle, running without WASM or a browser against a mocked core.
+- CI on Node 22 and 24: typecheck, test, build, and a packaging check.
+- Release workflow, run manually with a version. It runs the checks, sets the
+  version, promotes this changelog, derives notes from the commits, tags,
+  creates the GitHub Release and publishes to npm with provenance. A `dry_run`
+  input rehearses all of it without tagging or publishing.
+- `scripts/release-notes.mjs`, which groups Conventional Commits since the
+  previous tag so release notes reflect what actually landed, and
+  `scripts/promote-changelog.mjs`, which promotes the Unreleased section.
+- Webcam example: camera to Three.js cube overlay.
+- This changelog.
+### Changed
+- `processFrame` returns `{ detected, lost }` rather than `MarkerPose[]`. The
+  visibility transition was already computed internally and then discarded,
+  forcing consumers to diff successive results to recover it.
+- Named `@ar-js-org/artoolkit5-ts`, matching the rest of the organisation.
+- Depends on `@ar-js-org/artoolkit5-wasm@^0.1.3` from npm rather than a pinned
+  git commit. `three` moved to `devDependencies`; only the examples use it.
+### Fixed
+- `arglCameraViewRHf` allocated a `Float64Array` while every type declaration
+  promised `Float32Array`. Consumers reading `matrixGL` would have received a
+  different array type than the published types described, and the AR.js-next
+  marker event contract specifies `Float32Array(16)`.
+- `processFrame` allocated roughly three typed arrays per marker per frame. Both
+  matrix helpers now write into caller-supplied buffers, with one module-scoped
+  scratch array for the intermediate 4×4.
+- Debug logging removed from `src/`, which dumped the entire WASM module to the
+  console on every marker load and every `trackMarker` call.
+- `favicon.svg` and orphaned `.d.ts.map` files no longer ship in the package.
+### Notes
+Pattern markers only. Barcode support is planned; NFT is out of scope for this
+project. Worker compatibility is untested — nothing in `src/` touches the DOM,
+which is necessary but not proof.
+[Unreleased]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.2.2...HEAD
+[0.2.2]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.2.1...v0.2.2
+[0.2.1]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.2.0...v0.2.1
+[0.2.0]: https://github.com/AR-js-org/artoolkit5-ts/compare/v0.1.0...v0.2.0
+[0.1.0]: https://github.com/AR-js-org/artoolkit5-ts/releases/tag/v0.1.0

package/LICENSE CHANGED Viewed

@@ -1,28 +1,28 @@
-MIT License
-Copyright (c) 2026 AR-js-org
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
----
-This library wraps a WebAssembly build of ARToolkit5 (WebARKitLib), which is
-licensed under the GNU Lesser General Public License v3.0. Redistributing a
-build that includes the ARToolkit5 (WebARKitLib) WebAssembly binary carries the
-obligations of that licence in addition to the terms above.
+MIT License
+Copyright (c) 2026 AR-js-org
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+---
+This library wraps a WebAssembly build of ARToolkit5 (WebARKitLib), which is
+licensed under the GNU Lesser General Public License v3.0. Redistributing a
+build that includes the ARToolkit5 (WebARKitLib) WebAssembly binary carries the
+obligations of that licence in addition to the terms above.