chore(openjpeg): update OpenJPEG submodule to upstream v2.5.4 - #78
Conversation
Advances from 2d606701 (~2.5.0-era, Oct 2022) to upstream v2.5.4 (2025-09-20). No custom fork patches (clean version advance). Fork PR: cornerstonejs/openjpeg. CI is the first build/validation of v2.5.4 against our glue.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe changes add ChangesOpenJPEG build updates
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This updates OpenJPEG and refreshes its generated artifact size baselines; validated builds and decoding outputs indicate no remaining merge-readiness risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Merging this PR will regress 1 benchmark
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing Footnotes
|
Status: green except dist-size (small, expected size growth)openjpeg v2.5.4 (from ~2.5.0-era, Oct 2022). All real checks pass: build, test, browser-smoke, CodSpeed. No build fixes, no glue changes — clean same-minor-line advance, no custom patches. Decode output byte-identical (goldens pass). The one red —
Not a bug — a re-baseline decision. This fits the "modest growth for currency/stability" bar. Fork PR: cornerstonejs/openjpeg#3 — MERGEABLE. Actions to merge
|
jbocce
left a comment
There was a problem hiding this comment.
Merged in main. Tested in most recent cornerstone3D main (2189b0169e31f8120bdbb99e6d3af323540483fd) and OHIF master (8889c7514574aa837b8f5bc40eee29e8206b0c12) using viewer-testdata https://github.com/OHIF/viewer-testdata/blob/master/dcm/colorEncode/jpeg2000-lossless.dcm and https://github.com/OHIF/viewer-testdata/blob/master/dcm/grayEncode/jpeg2000-lossless.dcm
Also tested using cornerstone3D example dicomimageloaderwadouri
OpenJPEG 2.5.4 is genuinely larger than the 2.5.x build the baseline
recorded. The dist-size job reported 8 regressions, all in this package,
from run 34269973607:
openjpegjs.js 737.8 -> 746.5 KiB raw (+1.18%)
195.0 -> 197.9 KiB gzip (+1.50%)
openjpegjs_decode.js 529.0 -> 537.5 KiB raw (+1.62%)
136.4 -> 139.3 KiB gzip (+2.12%)
openjpegwasm.wasm 359.9 -> 364.2 KiB raw (+1.20%)
124.5 -> 126.5 KiB gzip (+1.63%)
openjpegwasm_decode.wasm 249.9 -> 254.2 KiB raw (+1.74%)
82.3 -> 84.3 KiB gzip (+2.42%)
Scoped to openjpeg, following bdd25d6. A bare `--update` rewrites all
eight packages, and this run carried incidental drift in every one of
them -- charls, openjphjs and libjpeg-turbo-12bit within 0.12%,
libjpeg-turbo-8bit slightly smaller, and the two pure-JS packages up
30 bytes each on a ~1 KiB file. Every one of those passed the tolerance
check as `ok`, so folding them in would absorb drift no reviewer asked
about and bury the change that matters. Only openjpeg's ten entries move
here.
Verified: node tools/dist-size/check.js --artifacts <run 34269973607
dists> reports PASS, 0 size regressions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Added: a new
|
| artifact | raw | gzip |
|---|---|---|
openjpegjs.js |
737.8 to 746.5 KiB (+1.18%) | 195.0 to 197.9 KiB (+1.50%) |
openjpegjs_decode.js |
529.0 to 537.5 KiB (+1.62%) | 136.4 to 139.3 KiB (+2.12%) |
openjpegwasm.wasm |
359.9 to 364.2 KiB (+1.20%) | 124.5 to 126.5 KiB (+1.63%) |
openjpegwasm_decode.wasm |
249.9 to 254.2 KiB (+1.74%) | 82.3 to 84.3 KiB (+2.42%) |
I made the new numbers from the artifacts of run 34269973607, which is this PR's own CI run. node tools/dist-size/check.js --artifacts <dists> then gave PASS: 0 size regression(s).
The commit changes the openjpeg entries only
A plain --update rewrites all 8 packages. This run also carried a small drift in every other package. charls, openjphjs and libjpeg-turbo-12bit stayed inside 0.12%. libjpeg-turbo-8bit became a few bytes smaller. The two pure-JS packages grew 30 bytes each, on a file of about 1 KiB.
The tolerance check gave ok to each of those changes. Therefore I kept the recorded numbers for those 7 packages. The diff shows the 10 openjpeg entries only. bdd25d6 used the same method for the two libjpeg-turbo packages.
The push removes the approval. Please approve this PR again, or use the administrator bypass.
A native cmake configure in either libjpeg-turbo package writes a build-libjpeg/ tree: 6.4 MB under the 8-bit package and 3.5 MB under the 12-bit one. Neither package's .gitignore covered it, because build.sh uses build/ and that is the only name the ignore files listed. Both packages already ignore their own build output locally rather than from the root .gitignore, so extend those two files instead of adding a root rule. This is about a stray `git add -A` more than about disk. Both submodule pointers in this worktree can sit at an OLDER commit than the branch records while a submodule upgrade is in progress, so an untracked 9.9 MB of cmake output is exactly the thing that gets swept into a commit next to a silent submodule downgrade. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Third codec submodule upgrade (after openjph #76, charls #77).
Bumps
packages/openjpeg/extern/openjpegfrom2d606701(~2.5.0-era, Oct 2022) to upstream OpenJPEG v2.5.4 (2025-09-20). Fork PR: cornerstonejs/openjpeg#3.CI validates compile against our glue + byte-identical pixel goldens + dist-size. Not built locally; iterating on CI. Not for merge.
Update 2026-09-09 (minor change)
This push adds two commits. Neither commit changes the OpenJPEG submodule pointer, and neither commit changes the
dist-sizebaseline.fb85c65mergesorigin/maininto this branch. The merge brings ind546620 chore(release): publish. The merge changes 5 files: twoCHANGELOG.mdfiles, twopackage.jsonfiles, andpnpm-lock.yaml. The merge touches no submodule.3e34c93addsbuild-libjpegto two files:packages/libjpeg-turbo-8bit/.gitignoreandpackages/libjpeg-turbo-12bit/.gitignore.Why the ignore rule is in this pull request
A native cmake command writes a
build-libjpeg/directory. The directory holds 6.4 MB of output in the 8-bit package, and 3.5 MB in the 12-bit package. Git tracked neither directory, becausebuild.shuses the namebuild/, and that name is the only name that the two ignore files held.Each package ignores its own build output in its own
.gitignorefile. Therefore this commit extends those two files, and adds no rule to the root.gitignorefile.The reason for the rule is a possible
git add -A, and not disk space. A submodule pointer in a work tree can be at an older commit than the branch records, if an upgrade of that submodule is in progress. An untracked 9.9 MB of cmake output can then go into a commit together with a silent downgrade of a submodule.The maintainer asked for this rule in this pull request, and asked for no separate pull request.
🤖 Generated with Claude Code
Summary by CodeRabbit
Chores
Impact