Higher resolution labelmap?

[tommy-qichang]

The cornerstone v.4.0 looks really good, thank you for your great work.

Just one question, I think right now, the resolution of the label map is align with the original dicom dimension. (Am I right?) The contours are very smooth when drawing, but the contour become very zigzag after release the mouse. I think maybe that's because the label map has a small resolution?
I just wondering how can we config the label map to the sub-pixel accuracy? For instance, the original dicom slices are 200x200, the label maps are 600x600 and then scale the dicom slice as the same size of the label map.

Thanks in advance.

[dannyrb]

I don't believe this is currently supported. Labelmaps are the same size as the slice/stack. Is there value in sub-pixel accuracy? I'm not a radiologist, so I would appreciate any info you have on real-world use cases. I'm trying to understand when you would need to be more granular with your measurements than the modality. I'm unsure of what you would be measuring, as anything sub pixel would be an interpolated value.

[JamesAPetts]

The resolution of the label map is align with the original dicom dimension.

You are correct. For now we have binary masks per voxel.
We currently do this because:
a) You can write reasonable implementations on the CPU.
b) Its the simplest implementation and is better than we had before.

In general this isn't a simple issue. If what you want is simply a nice visual representation, then you may be better off using contours (e.g. the FreehandRoiTool + FreehandRoiSculpterTool), depending on your use case. However I understand the alure of the cornerstone labelmaps, as they are certainly more developed and user friendly at the current time.

I just wondering how can we config the label map to the sub-pixel accuracy? For instance, the original dicom slices are 200x200, the label maps are 600x600 and then scale the dicom slice as the same size of the label map.

You have two options here:

• Supersample your images before they are given to cornerstone, and you can just use the current architecture for free (e.g. a 600x600 image will have a 600x600 labelmap per slice).
• Modifiy the labelmap allocation, brush & segmentation tools to multiply the pixel density to a certain desired resolution. This will be a hardfork of the the codebase, however.
  • The issues @dannyrb raised aren't a problem if you super sample so your grid still aligns (i.e. 3x the resolution, as each voxel in 3x3 block would be the same value as the original voxel.
  • However, you would have to worry about counting partial volumes if you upscaled by some arbitrary factor.

I urge caution however, that as the labelmaps get too large you do start to see a performance drop, especially with the outline renderer. An ideal solution would keep the same underlying data and just display them differently.

I know Slicer has the option to resample labelmaps to a smooth isosurface which you can display as a nice smooth contour, but that may be challenging to do well fast in the web on the CPU. If you want to spike a webgl implementation, I'd be very happy to look at it. It may eventually be easier to do this sort of thing in vtkjs.

[pieper]

This is definitely something that would be good to have in the future - it's very common to want to mix and match segmentations and images with different geometries (resolution, but also origin and orientation should be free variables). As James says, this is how Slicer does it and it's important for several clinical scenarios (and for making more faithful representations of anatomy). Even though it's not the most common case, we should be keeping this in mind when implementing CPU and GPU segmentation code.

Note that the DICOM SEG object supports up to 8 bits per segment which can be used to represent fractional coverage for "soft" segmentation, but in my experience you are much better off supersampling a labelmap by 2 in each dimension, so those same 8 bits can encode more information about the intra-voxel shape, while also preventing overlap and being compatible with existing labelmap algorithms.

[tommy-qichang]

If I want include the range from 0.25 to 1.75 what am I actually including? How would you calculate average intensity for the area? Does that math change when we shift to volumes? What does this level of granularity buy us?

I think linear interpolation would be the case. For the current case, what the radiologist want is to display the contours more smoothly. However, to my knowledge, it is useful when contouring the plaques in CTA images. Even though there isn't much information for the sub-pixel grid, the radiologists still could draw a more precise sub-pixel contour when they refer to some other gold standard and higher resolution modality's images.

You have two options here:
Supersample your images before they are given to cornerstone, and you can just use the current architecture for free (e.g. a 600x600 image will have a 600x600 labelmap per slice).

That's my current solution, but as you said, upsampling the DICOM image means increasing transfer data and proceeding time. I think maybe we could consider using float coordinates rather than binary mask in such case in the future.

[gevgeny]

@JamesAPetts

Supersample your images before they are given to cornerstone

Do you know how to intercept the moment of passing image to cornerstone? I would like to do the same for segmentations and I found that segmentation image is rendered into the cornerstone canvas right after creating

cornerstoneTools/src/eventListeners/internals/renderSegmentationFill.js

Line 127 in e70b894

context.drawImage(