256b8347e7
This is a fix to pnpm deployment which needs testing as the final part of origin/master release No functional changes * fix(docs): remove stray tool-call tags breaking the MDX build platform/docs/docs/migration-guide/3p12-to-3p13/build-tooling.md ended with two orphan closing tags (leftover tool-call serialization artifacts): </content> </invoke> Docusaurus compiles Markdown as MDX (JSX-aware), so the orphan closing tag failed the docs build: MDX compilation failed ... Unexpected closing slash in tag, expected an open tag first (build-tooling.md line 402) This was the remaining blocker for build-and-deploy-docs once the --no-frozen-lockfile change let the install step succeed. A scan of the docs tree found no other such artifacts. Verified locally: docusaurus build now generates static files with no MDX errors. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Update lockfile and avoid freshness check on every command * fix(release): keep workspace:* in the repo, concretize only at publish The release flow rewrote internal @ohif/* dependency specifiers to the concrete version and committed them, so pnpm-lock.yaml (which records workspace links) drifted from the manifests on every version bump. The resulting ERR_PNPM_OUTDATED_LOCKFILE broke every frozen install: Netlify (viewer-dev), the docs deploy, pnpm's pre-run deps check, and post-merge installs. Keep workspace:* everywhere in the committed repo and move the concrete-version substitution to publish time only: - publish-version.mjs: bump each package's own `version` field only; stop rewriting @ohif/* dependency/peerDependency specifiers. - publish-package.mjs: publish with `pnpm publish --no-git-checks` instead of `npm publish`. pnpm rewrites workspace:* to the exact version in the published tarball; npm would publish the literal "workspace:*", which npm/yarn consumers cannot resolve. - One-time: revert the 25 workspace manifests' @ohif/* specifiers to workspace:* (version fields untouched) and regenerate pnpm-lock.yaml to match. Because internal deps are workspace:* (links, not versions in the lockfile), version bumps no longer change pnpm-lock.yaml, so it stays in sync and frozen installs keep working. Verified: `pnpm install --frozen-lockfile` passes, and `pnpm pack` of @ohif/core emits a tarball whose @ohif/ui dependency is the exact version (3.13.0-beta.92), not workspace:*. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(ci): correct build-docs install comment for workspace:* release flow publish-version.mjs no longer rewrites @ohif/* deps to concrete versions, so the old comment was stale. Internal deps stay workspace:* and the lockfile stays consistent; pnpm publish concretizes only the published tarball. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(docs): use --frozen-lockfile now that the lockfile no longer drifts With internal deps as workspace:* the lockfile stays in sync across version bumps, so the docs deploy can install frozen -- failing fast on genuine lockfile drift instead of silently reconciling. The --no-frozen-lockfile workaround is no longer needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: use --frozen-lockfile in CI install steps now that the lockfile is stable Internal @ohif/* deps are workspace:* so pnpm-lock.yaml no longer drifts; the UNIT_TESTS/BUILD/NPM_PUBLISH installs can run frozen and fail fast on genuine drift. Kept --no-frozen-lockfile only where it is still required: the Dockerfile (platform/docs is excluded from the build context) and the playwright CS3D-version step (mutates @cornerstonejs versions before installing). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: stability of seg load mpr test * Better drag fix for crosshairs --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| .webpack | ||
| assets | ||
| src | ||
| babel.config.js | ||
| CHANGELOG.md | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
Measurement Tracking Mode
Introduction
Measurement tracking mode allows you to:
- Draw annotations and have them shown in the measurement panel
- Create a report from the tracked measurement and export them as DICOM SR
- Use already exported DICOM SR to re-hydrate the measurements in the viewer
Workflow
Status Icon
Each viewport has a left icon indicating whether the series within the viewport contains:
- tracked measurement OR
- untracked measurement OR
- Structured Report OR
- Locked (uneditable) Structured Report
In the following, we will discuss each category.
Tracked vs Untracked Measurements
OHIF-v3 implements a workflow for measurement tracking that can be seen below. In summary, when you create an annotation, a prompt will be shown whether to start tracking or not. If you start the tracking, the annotation style will change to a solid line, and annotation details get displayed on the measurement panel. On the other hand, if you decline the tracking prompt, the measurement will be considered "temporary," and annotation style remains as a dashed line and not shown on the right panel, and cannot be exported.
Below, you can see different icons that appear for a tracked vs. untracked series in OHIF-v3.
Reading and Writing DICOM SR
OHIF-v3 provides full support for reading, writing and mapping the DICOM Structured Report (SR) to interactable Cornerstone Tools. When you load an already exported DICOM SR into the viewer, you will be prompted whether to track the measurements for the series or not.
If you click Yes, DICOM SR measurements gets re-hydrated into the viewer and the series become a tracked series. However, If you say no and later decide to say track the measurements, you can always click on the SR button that will prompt you with the same message again.
The full workflow for saving measurements to SR and loading SR into the viewer is shown below.
Loading DICOM SR into an Already Tracked Series
If you have an already tracked series and try to load a DICOM SR measurements, you will be shown the following lock icon. This means that, you can review the DICOM SR measurement, manipulate image and draw "temporary" measurements; however, you cannot edit the DICOM SR measurement.
