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 | ||
Total Metabolic Tumor Volume
Introduction
Total Metabolic Tumor Volume (TMTV) workflow mode enables quantitatively measurement of a tumor volume in a patient's body. This mode is accessible in any study that has a PT and CT image series as you can see below
Note: If the study does not have a PT and CT image series, the TMTV workflow mode will not be available and will become grayed out.
Layout
The designed layout for the viewports follows a predefined hanging protocol which will place 10 viewports containing CT, PT, Fusion and Maximum Intensity Projection (MIP) PT scenes.
The hanging protocol will match the CT and PT displaySets based on series description. In terms of PT displaySets, the hanging protocol will match the PT displaySet that has attenuated corrected PET image data.
As seen in the image below, the first row contains CT volume in 3 different views of Axial, Sagittal and Coronal. The second row contains PT volume in the same views as the first row. The last row contains the fusion volume and the viewport to the right is a MIP of the PT Volume in the Sagittal view.
Synchronization
The viewports in the 3 rows are synchronized both for the Camera and WindowLevel. It means that when you interact with the CT viewport (pan, zoom, scroll), the PT and Fusion viewports will be synchronized to the same view. In addition to camera synchronization, the window level of the CT viewport will be synchronized with the fusion viewport.
MIP
The tools that are activated on each viewport is unique to its data. For instance, the mouse scroll tool for PT, CT and Fusion viewports are scrolling through the image data (in different directions); however, the mouse scroll tool for the MIP viewport will rotate the camera to match the usecase for the MIP.
Panels
There are two panels that are available in the TMTV workflow mode and we will discuss them in detail below.
SUV Panel
This panel shows the PT metadata derived from the matched PT displaySet. The user can edit/change the metadata if needed, and by reloading the data the new metadata will be applied to the PT volume.
ROI Threshold Panel
The ROI Threshold panel is a panel that allows the user to use the RectangleROIStartEnd
tool from Cornerstone to define and edit a region of interest. Then, the user can
apply a threshold to the pixels in the ROI and save the result as a segmentation volume.
By applying each threshold to the ROI, the Total Metabolic Tumor Volume (TMTV), and the SUV Peak values will get calculated for the labelmap segments and shown in the panel.
Export Report
Finally, the results can be saved in the CSV format. The RectangleROI annotations can also be extracted as a dicom RT Structure Set and saved as a DICOM file.
Video Tutorial
Below you can see a video tutorial on how to use the TMTV workflow mode.
https://user-images.githubusercontent.com/7490180/171065443-35369fba-e955-48ac-94da-d262e0fccb6b.mp4