Any Solution for this??
This should help: https://www.slicer.org/wiki/Documentation/Nightly/FAQ/DICOM#Image_is_stretched_or_compressed_along_one_axis
Yes this helped me i have changed regularization transform form the settings now the images are looking normal, But why threshold is only applying for particular region?
is this because ROI is following old data reference? How can i set this to auto like above setting?
i found that harden transform works for this, how can i automate this, is their any setting , Or can i apply this using python code?
This is the python call:
slicer.vtkSlicerTransformLogic.hardenTransform(volumeNode)
Acquisition regularization seems to work well. Should we change the DICOM importer in Slicer nightly version to enable regularization by default?
A few things still do not support dynamically applied non-linear transforms, such as volume rendering, and extent computation in Segment Editor, but we should be able to fix these (e.g., by hardening the transform in the volume rendering displayable manager and computing segmentation extents from transformed volume’s corners).
1 Like
Are you thinking of automating the hardening (e.g by comparing a LastHardernedTime of a copy of the volume node with the MTime of the selected volume. Ideally, the two volume would share the same image data …)
1 Like
My concern about this is that it can hide potentially serious issues with the data. I think irregular image geometry should always be a red flag. I would feel fine if the user by default was warned about this issue, and asked to confirm the default choice of regularization. But I think right now the only way to learn about it is in the “Advanced” mode, or via the logs, which I don’t think will draw attention from most users.
About this note in the FAQ referenced earlier:
Scanners may create image volumes with varying image slice spacing.
I think it is still more likely to have a volume where some slices are simply missing, than varying slice spacing. For what it’s worth, I have never encountered a volume with varying slice spacing, but have seen many with missing slices.
I’m thinking about just resampling the volume in the volume rendering displayable manager (we can use filter pipeline, so probably we would not need to manually manage MTime).
We still display the same warning popup when we load an image with varying slice spacing, regardless of acquisition transform is enabled or not. Acquisition transform cannot solve all problems, but I don’t see how it could make things worse.
I agree that it would be nice to improve warning display, as the advanced section of the DICOM is quite complex. The upcoming DICOM browser update allows us to store additional information in Slicer’s DICOM database that can be shown in the series table (not just in the advanced tab). We could also store user’s responses to warning popups (approve loading, apply acquisition transform or not, which loadable to use) so that we would need to only ask once and not every time the user loads the data.
It’s actually pretty common in some CT acquisitions to vary the slice spacing - e.g. fine cuts near the renal arteries, thicker down the aorta, then fine again in the pelvis. The goal is to maximize the clinical value while minimizing radiation (and to minimize extra non-valuable images for review).
But yes, users should definitely be made aware when their data doesn’t match the default assumptions of the majority of our processing tools. I like the idea of automating the hardening operation, but I also think it should be configurable in the Volumes module (e.g. to pick the reference geometry and sampling resolution, as in CropVolume).
It could make sense to add methods to vtkMRMLVolumeNode like GetHardenedImageData, GetHardenedImageDataConnection, SetHardeningReferenceGeometry.
1 Like
@lassoan definitely, if the new DICOM browser would allow to prominently label volumes that have irregular slicing, I would not have any concern enabling regularization by default.
Makes sense, I just shared my personal anecdotal evidence. I am not saying how generalizable it is. I don’t think I ever encountered those myself.
NOTE: Support for regularization transform hardening in DICOM Scalar plugin has been added. See link.