Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(windowing): more robust loading of multi-component DICOMs #578

Merged
merged 2 commits into from
Apr 29, 2024

Conversation

PaulHax
Copy link
Collaborator

@PaulHax PaulHax commented Apr 13, 2024

Attached DICOM was freezing app.
1-001.zip

Copy link

netlify bot commented Apr 13, 2024

Deploy Preview for volview-dev ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 4bb28a5
🔍 Latest deploy log https://app.netlify.com/sites/volview-dev/deploys/662bc7c60ef728000861a2b2
😎 Deploy Preview https://deploy-preview-578--volview-dev.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@@ -30,7 +59,8 @@ function useAutoRangeValues(imageID: MaybeRef<Maybe<string>>) {

// Pre-compute the auto-range values
const scalarData = imageData.value.getPointData().getScalars();
const [min, max] = scalarData.getRange();
// Assumes all data is one component
const { min, max } = fastComputeRange(scalarData.getData());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the original getRange() call causing any particular issue?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was working perfectly for one component, which caused NANs in downstream windowing calculations.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it makes sense to treat multi-component data as single-component data. How about instead just picking out the first component using scalarData.getRange(0)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try it

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scalarData.getRange(0) is the default and what was happaning before with just scalarData.getRange(). That is a problem when we compute the autoRangeValues, which computes the histogram from all components from scalarData.getData(). Histogram including all compnents does not make sense to me eather.

We are rendering all components. Looks like a single Window and Level are getting applied to all components:
https://github.com/Kitware/vtk-js/blob/master/Sources/Rendering/OpenGL/ImageMapper/index.js#L638-L655

I see this PR as a cludge to keep the app trucking along while still sort of supporting RGB images.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, this is fine. We will have to revisit this at some point.

import useWindowingStore from '@/src/store/view-configs/windowing';
import { Maybe } from '@/src/types';
import type { TypedArray } from '@kitware/vtk.js/types';
import { watchImmediate } from '@vueuse/core';
import { MaybeRef, computed, unref, watch } from 'vue';

// Original source from https://www.npmjs.com/package/compute-range and vtkDataArray
// Modified to assume one component array
function fastComputeRange(arr: number[] | TypedArray) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is accessible via vtkDataArray.fastComputeRange. You should be able to just use that + set numComponents to 1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@PaulHax PaulHax force-pushed the multi-component-hax branch from 6b7cb40 to 4bb28a5 Compare April 26, 2024 15:27
@floryst
Copy link
Collaborator

floryst commented Apr 29, 2024

LGTM!

@floryst floryst added this pull request to the merge queue Apr 29, 2024
Merged via the queue into Kitware:main with commit fccefa9 Apr 29, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants