no redraw appears... but mouse over the images and see that the values of the MRML image data have been updated

The behavior is correct. It's because the original labelmap imagedata is connected to a pipeline (vtkImageThreshold).

When I do:
1) Load volume (get the MRHead from SampleData).
2) Enter Editor and select default color map.
3) In python
lbnode = getNode('MRHead-label')
lbnode.GetImageData().GetProducerPort().GetProducer()

I got the following output: (vtkImageThreshold)06D11B70

This means that even if you later override the image data in lbnode, because it is connected to an upstream pipeline, next time the render requests the image data, it will reexecute it.

No - the problem is not that there's a pipeline -that's fine. The actual underlying problem is that calling modified on the lbnode does not trigger a redraw of the slice views.

Let me try to remember what I discovered. You have the following pipeline:

source -> A (vtkImageThreshold) -> B (vtkImageReslice) -> C (vtkImageMapper)

Between each filter (A <-> B and B <-> C) there is a temporary vtkImageData.
The Editor edits a temporary vtkImageData between A and B.
2 problems:

• Sending ModifiedEvent on a temporary image data doesn't trigger an "update request" event on the pipeline. So when the vtkimagemapper needs to display its slice, it won't update the pipeline. -> The request needs to come from a filter.
• Whatever is changed in the temporary image (between A and B) will be erased next time the filter A is re-executed.

I guess I'm not explaining this well :)

Ignore the editor, just load the MR head sample data and do the following in the python console:

n = getNode('MR*')
i = n.GetImageData()
e = vtk.vtkImageEllipsoidSource()
e.Update()
i.DeepCopy(e.GetOutput())
n.Modified()

Notice that the slice viewers don't redraw until you try to pan or zoom. The point is that changing the image data should trigger a render.

For reference the same sequence does cause a redraw in slicer3.

(Slicer3) 49 % MRMLWatch
mRMLWatcher0
(Slicer3) 50 % set n $::MRML(MR-head)
vtkTemp6794
(Slicer3) 51 % set i [$n GetImageData]
vtkTemp7003
(Slicer3) 52 % set e [vtkImageEllipsoidSource New]
vtkObj7004
(Slicer3) 53 % $e Update
(Slicer3) 54 % $i DeepCopy [$e GetOutput]

I didn't try that script, but I agree with VTK that it shouldn't work :-)

When you deep copy, you modify an intermediate image (between 2 filters: vtkImageThreshold and vtkImageReslice).
You trigger a refresh in the view by doing n.Modified(), however, when the image mapper (end of the pipeline) is checking if the pipeline is up-to-date, it queries the mtime of the filters, not the mtime of the intermediate images (because they are not supposed to be changed by anything else than a filter).

Later, when you pan and zoom, you change the parameters of the reslice filter, which changes its MTime, so the pipeline becomes obsolete, and when the image mapper checks the pipeline, it asks for an update, it then finally propagates the "temporary" image data downstream along the pipeline (it reslices it first, then apply some window/level...).

In slicer3, it was working because we were not using a "true" VTK demand-driven pipeline.

No - the DeepCopy goes into the vtkImageData that is in the mrml volume node. It is not in the middle of any pipelines, it is at the beginning. This should be the input data to whatever pipelines make use of the volume node for rendering or other uses.

What vtkImageThreshold and vtkImageReslice are you talking about? In the example n.GetImageData().DeepCopy(e.GetOutput()) is copying the updated image data from the vtkImageEllipsoid source and putting it into the image data of the mrml node -- there shouldn't be any other filters putting data into the mrml node's image data.

Dear issue reporter,

Good news :) Slicer developers SOLVED the problem you reported - YOU now need to VERIFY and CLOSE this issue.

Issue was fixed by ensuring that label maps do not have 'lingering' producer ports after creation.