From Xinwei Wang, Stanford:

"Hope that it can be fixed after next major release. Otherwise, it is not convenient.
I think that many people have this issue."

Same issue in Slicer3, that has not been resolved: http://www.na-mic.org/Bug/view.php?id=715

Posts on user list that requested specifically this feature:

2010: http://slicer-users.65878.n3.nabble.com/editor-label-outline-line-thickness-td931595.html
2012: http://slicer-users.65878.n3.nabble.com/Display-thicker-lable-volume-outlines-td3839396.html

There are two related issues in terms of making slice overlays thicker:

1) the outline mode of a label map (as set by the button in the slice controller widget). For this, we could add an explicit image dilate step in the slice layer pipeline. Note that there may be issues at the borders of labels. The dilate code would have to be added here:

https://github.com/Slicer/Slicer/blob/master/Libs/MRML/Logic/vtkMRMLSliceLayerLogic.cxx#L563

Alternatively the label outline class could be modified to show pixels that are not just on the border, also one or more pixels in from the border. The most general solution would be to do a localized distance transform of some sort. Probably the dilate is easier.

2) the outlines of models intersected with the slice, as selected in the models module. These can easily be made thicker with a property on the actor:

https://github.com/Slicer/Slicer/blob/master/Libs/MRML/DisplayableManager/vtkMRMLModelSliceDisplayableManager.cxx#L318

http://www.vtk.org/doc/nightly/html/classvtkProperty2D.html

Steve, for (1), maybe we can try to add an option to initialize voxel neighborhood in the output instead of just one voxel here: https://github.com/Slicer/Slicer/blob/master/Libs/MRML/Logic/vtkImageLabelOutline.cxx#L158 ?

For (2), does it make sense to add intersection line thickness to the display node, expose it in the Models widget, and initialize on the actor?

For (1), Demian and I talked and he suggested doing an n-pixel erosion and then subtracting it from the label layer. I like this suggestion since we could make the lines arbitrarily thick. Unfortunately we could not find a multi-label erosion filter already implemented in ether vtk or itk, so there some coding to be done to implement that.

For (2), yes, it seems we have some options:
(a) we could expose a per-model slice intersection thickness. Or, (b) we could just change the default thickness from 1 to 3, which would probably always give good results. Or (c) we could make a global thickness setting and use it in the model slice displayable manager. The best overall solution would probably be (a), with an extra option to set the thickness globally on all models in the scene.

BTW, I exchanged email with Xinwei and it seems that issue (1) is the one that causes issues for them right now.

Good idea. I looked around but could not find a filter for (1) either. I will see if I have some down-time during the case to look into this. I would think taking ITK erosion filter, adding extra checks and wrapping ITKVTK should not be very hard, but maybe I am missing something.

For (2), I agree it does not resolve directly the request, but I think would be nice to have this feature anyway, especially since it enables visualization of multiple contours.

It would be great if you could look into (1) Andrey. I agree that writing the vtkITK wrapper would be the right thing, and it could be integrated in the display pipeline. What Demian and I looked for was a filter that would erode all label values in one pass rather than requiring that the image be decomposed into multiple images, one per unique label value to erode. So maybe this requires a custom ITK filter (also possible, but more coding).

This might be relevant, need to investigate: http://old.nabble.com/Multilabel-dilation-td34995623.html

It seems like we could use the slice intersection width parameter being added to the vtkMRMLDisplayNode so that we can support it as a configurable option for volumes and models and other displayable nodes rather than just for model nodes. SliceIntersectionVisibility is already defined there. Adding it as an integer denoting number of voxels in width that the intersection should be.

On my github:
https://github.com/naucoin/Slicer/commit/3cdf2e92f8fb7fa041cbd1896e53027fb62a39cc

svn 21832[1] adds the SliceIntersectionThickness to the vtkMRMLDisplayNode. The widget elements are disabled, please enable them when they're being used.

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21832

That's a great addition - thanks Nicole! Can you elaborate on "please enable them when they're being used." ? Is that something the user needs to do or is there still some programming to do?

I just tried this and was able to set the width with python and the spin box updated (still grayed out) but the width did not change in the slice view. What else needs to be done on this?

Enable the spin box when the updating of the width is done in the slice view (all I did was provide the variable to save the width and the widget to set it). My understanding was that Andrey was going to do the filter update.

Nicole, I thought you are adding model slice intersection thickness. Based on the comment 0007671 from Steve, no additional filter is needed, it should just pass the value to the actor.

Okay - I see - this was actually a simple change so I went ahead and did it. This will be very useful for making image for publication and presentation.

Committed r21840

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21840

Oops, sorry, I didn't read the previous comments closely enough! Thanks Steve!

Referring back to the earlier notes on this bug, we have now implemented the fix for (2), which was the model intersections.

We still need to work on (1) which was the outline width of the labels.

This would be a perfect task for someone who wants to learn a little vtk coding - the fix is probably pretty simple but will require C++ and some testing.

There is a "Slice intersection thickness" display option in the model module. I think it does what is needed.

I don't think the label map outline mode line thickness has been implemented yet though, just the model slice intersections.

Alireza, can you look into this issue of adding the capability to control line thickness for label outline?

This feature was specifically requested by Reinhard, and also by many other users. Thanks.

I agree - this is a doable project and would be helpful for people. Alireza, let me know if you need suggestions on how to approach it. -Steve

The vtkImageLabelOutline filter is a simplified clone of VTK's vtkImageDilateErode3D filter.

The original vtkImageDilateErode3D filter contains a kernel size parameter, so I guess we could just use the original VTK filter or copy the kernel size parameter handling from vtkImageDilateErode3D to vtkImageLabelOutline.

I like the suggestion from Andras. One complication is lightbox mode, where you get 'bleed' from adjacent slices due to the way the slices are extracted. It looks like setting the kernel size to 1 in the slice axis (z) would handle this case. Hopefully this turns out to be an easy fix!

http://www.vtk.org/doc/nightly/html/classvtkImageDilateErode3D.html

I'm looking into implementing this as part of the Radiomics project.

Topic for review (it seems to work not badly in a quick lightbox test):
https://github.com/naucoin/Slicer/tree/2267-Add-line-thickness-for-label-outline

I added using and setting the kernel size on the current filter, cued off of the SliceIntersectionThickness defined on the vtkMRMLDisplayNode (same variable as used with models). That's set by default to 1 in the node constructor.

Two related questions:
Do you want me to change the GUI spin box label to something other than:
Slice Intersections Thickness
And if we change the default for the label maps, will that still work with the models? Or do I need to add a new variable so we can have two different defaults? Or just have the subclasses set it as necessary?

Responding to questions from Andrey via email:

The way the classes are set up, SliceIntersectionThickness is defined on the superclass, vtkMRMLDisplayNode, and it seems to be a general enough name to support an argument to use it in both the model display node and the label map volume display node for showing outlines on the slices. If we decide to update the API to separate the concepts, it would mean:

• removing SliceIntersectionThickness and SliceIntersectionVisibility from the display node
  • double checking that it's not used by any other subclasses (like fiber bundle display)
• adding ModelSliceIntersectionThickness and ModelSliceIntersectionVisibility to the model display node
  • updating uses for models
• adding LabelOutlineThickness to the label map display node (the visibility is defined by a GUI check button right now, so possibly updating that to be a per volume setting rather than just a GUI setting - or deciding if we want to shift the model outline visibility to be a GUI concept rather than a per model concept)
  • updating uses for label volumes
• update the testing macros
• other?

I'm inclined to leave it as is, with setting the higher default for the label volume display node in that constructor, since the current changes resolve the reported feature request. I'm willing to do the work, but would rather get the GUI change checked in now and then update it later on the API side after resolving the questions above.

Pull request:
https://github.com/Slicer/Slicer/pull/266

I didn't try building it but the pull request looks good to me. I'd say go ahead and merge.

Andrey's building it to test, I didn't do extensive testing so I'd like to wait on his report to see if there are outstanding bugs.
And he posted that it works for him as I was posting this, so I'll get it merged.

Fixes commited as
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24203
https://github.com/Slicer/Slicer/commit/cd654faa89279694af12f5d7bbaa053281594881

Nicole, as discussed in the email thread, line thickness is not uniform over the countour. Can you update on the status?

There's clearly something wrong with the underlying filter. See attached image single-pixel.png

Looks better to me now:

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=24256

Another issue fixed in r24257. The outline really does look correct now.

People will love this feature ; )

Wow, good catches, thanks!

Thanks!

Alas on testing this morning I found some odd behavior--(if you zoom in and look at the boundaries of the view there are some asymmetries that are troubling. Particularly noticable when the outlines are very thick.

It seems to be related to the kernel size, kernel middle, and the neighborhood size. I'll hook up a debugger and check the assumptions.

I'll need to re-open the issue.

See notes

Okay, now this one is finally looking correct as of r24260. Pointer arithmetic going on in the guts of this one. I also cleaned up the style a bit to make things easier to debug.

Thanks for working on this Steve