chore(openjphjs): update OpenJPH submodule to upstream 0.30.1 (pilot)

[sedghi]

Pilot: first of the four submodule upgrades

Bumps packages/openjphjs/extern/openjph from the ~22-month-old pin (e01c7b7, branch merge/aous-20240423) to upstream OpenJPH 0.30.1 + our re-applied patches.

Fork-side PR (the actual rebase + carry/drop rationale): cornerstonejs/OpenJPH#5.

cornerstonejs delta from stock 0.30.1 (3 lines, one file)

• resilient = false → true — decoder tolerates truncated/damaged codestreams (deliberate, carried).
• suppressed the noisy "File terminated early" INFO log (carried).
• Dropped: the cosmetic SIZ-marker message renames (collided with upstream's swap_byte→swap_bytes_if_le rename) and the temporary CMAKE_BUILD_TYPE=Debug toggle.

What this PR validates

This is the first real build of openjph 0.30.1 against our emscripten glue (packages/openjphjs/src/HTJ2K*.hpp) — it was not built locally. CI will confirm:

1. The 0.30.1 headers still compile against our bindings (API-drift check).
2. The pixel-correctness + browser-smoke goldens still pass (esp. that resilient=true doesn't alter output on valid streams).
3. dist-size delta (0.30.1 codegen may shift wasm size — re-baseline if the gate flags it).

If CI is green, this is the template for charls / openjpeg / libjpeg-turbo. If the glue doesn't compile against 0.30.1, that's the pilot's job to surface.

Follow-ups

• After OpenJPH#5 merges, re-point this submodule at the merge commit (currently the branch tip).
• Base is main; independent of the emsdk-bump PRs (separate, later).
• Not stacked on the open correctness-fixes PR (fix: consolidated codec correctness fixes (supersedes #71) #73) per your call.

[coderabbitai]

Warning

Review limit reached

@sedghi, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 488a8257-2cb6-4b24-97f8-a1e97a68d715

📥 Commits

Reviewing files that changed from the base of the PR and between 9c086c9 and dbcfbee.

📒 Files selected for processing (4)

• packages/openjphjs/CMakeLists.txt
• packages/openjphjs/build.sh
• packages/openjphjs/extern/openjph
• packages/openjphjs/src/CMakeLists.txt

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/openjph-submodule-0.30.1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codspeed-hq]

Merging this PR will improve performance by ×2.3

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 15 improved benchmarks
✅ 1 untouched benchmark
⏩ 103 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	decode CT2.j2c (.201 lossless, 512x512x16bit) — warm	31.3 ms	9.5 ms	×3.3
⚡	WallTime	decode CT2.j2c (.201 lossless, 512x512x16bit) — cold	31.3 ms	9.6 ms	×3.3
⚡	WallTime	decode CT1.j2c (.201 lossless, 512x512x16bit) — cold	31.5 ms	9.7 ms	×3.2
⚡	WallTime	decode CT1.j2c (.201 lossless, 512x512x16bit) — warm	31.5 ms	9.7 ms	×3.2
⚡	Simulation	decode CT1.j2c (.201 lossless, 512x512x16bit) — cold	38.8 ms	12.3 ms	×3.1
⚡	Simulation	decode CT2.j2c (.201 lossless, 512x512x16bit) — cold	36.6 ms	12.1 ms	×3
⚡	Simulation	decode CT2.j2c (.201 lossless, 512x512x16bit) — warm	36.6 ms	12.1 ms	×3
⚡	Simulation	decode CT1.j2c (.201 lossless, 512x512x16bit) — warm	36.8 ms	12.3 ms	×3
⚡	WallTime	encode CT1.RAW (HTJ2K lossless) — cold	25 ms	11.2 ms	×2.2
⚡	WallTime	encode CT1.RAW (HTJ2K lossless) — warm	25 ms	11.2 ms	×2.2
⚡	Simulation	encode CT1.RAW (HTJ2K lossless) — cold	35.5 ms	19.5 ms	+82.57%
⚡	Simulation	encode CT1.RAW (HTJ2K lossless) — warm	34.4 ms	19.5 ms	+76.5%
⚡	WallTime	instantiate+destroy HTJ2KEncoder x50	256.8 µs	155.6 µs	+65.02%
⚡	WallTime	instantiate+destroy HTJ2KDecoder x50	669 µs	567.1 µs	+17.99%
⚡	Simulation	instantiate+destroy HTJ2KEncoder x50	447.1 µs	384 µs	+16.42%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing chore/openjph-submodule-0.30.1 (dbcfbee) with main (a88a461)²}

Footnotes

1. 103 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (9c086c9) during the generation of this report, so a88a461 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[sedghi]

Status: ✅ CI fully green — ready to merge

openjph 0.30.1 (was ~22 months behind). All checks pass: build, test, browser-smoke, dist-size, CodSpeed.

What it took (build-integration only — no decoder logic change): 0.30.1 relocated headers under src/core/openjph, renamed the SIMD target (openjphsimd→openjph), and the build was accidentally shipping Debug. Fixes: header include path, link openjph, force OJPH_DISABLE_SIMD=OFF (WASM SIMD), and Debug→Release.

Result vs the previously-shipped artifact: ~3× faster decode/encode and ~87% smaller wasm (2.2 MB → 283 KiB). Decode output is byte-identical (goldens + browser-smoke pass). Note: the speed/size win is dominated by the Debug→Release fix (which applies repo-wide), not the version bump itself.

Fork PR: cornerstonejs/OpenJPH#5 — now MERGEABLE (rebased onto upstream 0.30.1 + 2 carried patches: resilient=true, suppressed early-termination log; dropped a debug-build toggle and cosmetic message renames).

Actions to merge

1. Merge fork OpenJPH#5 first.
2. (Optional) re-point this submodule at the fork's merge commit (currently the branch tip — same tree).
3. Merge this PR.