Page MenuHomePhabricator

[Image Rendering] Color change/ Opacity strange behaviour (only in Windows installers)
Closed, ResolvedPublic

Assigned To
Authored By
gaoh
Jan 27 2021, 12:34 PM
Referenced Files
F2072162: image.png
Jan 27 2021, 12:34 PM
F2072160: image.png
Jan 27 2021, 12:34 PM
F2072158: image.png
Jan 27 2021, 12:34 PM

Description

  • Add Pic3D
  • Directly change the Opacity, or Color of the image in the Data Manger.

Result:
Sometimes it works correctly, sometimes only the Coronal View changes color/opacity, sometimes when zooming e.g. into Axial the color is set back to white for Axial... ,

image.png (382×770 px, 110 KB)

Sometimes nothing changes:
image.png (446×1 px, 157 KB)

So there are different possible scenarios, basically when playing with the settings every combination of applied/not applied to different Views can be created:
image.png (384×1 px, 106 KB)

Event Timeline

gaoh triaged this task as Normal priority.Jan 27 2021, 12:34 PM
gaoh created this task.
kislinsk raised the priority of this task from Normal to Unbreak Now!.Jan 27 2021, 2:07 PM
kislinsk added a subscriber: kislinsk.

Wow, this is really a blocker. Didn't work in the December snapshot installer neither. Is it specific to installed versions maybe? I will try with a build-tree version...

It is dependent of the crosshair position. If you do not see anything, carefully move the crosshair around in a 2d window and there is always at least a pixel or region, where the changes are visible. What is going on? 🐛

Only happens in Windows installers. How do we debug this?

kislinsk renamed this task from [Image Rendering] Color change/ Opacity strange behaviour to [Image Rendering] Color change/ Opacity strange behaviour (only in Windows installers).Jan 27 2021, 2:46 PM

Zoom into the image until you have big pixels. Click in a pixel, crosshair snaps to that pixel, color/opacity is not shown. Click on that pixel again and it works. You can also click, hold, and move the cursor. As soon as you move the cursor it works. Stops working as soon as you leave the pixel and the crosshair snaps to the next pixel.

It's definitely linked to the crosshair. If you disable the crosshair everything works immediately.

I could also reproduce this bug in a build-tree version of MITK. As Hanno wrote, sometimes every render window is affected, sometimes only a few, sometime it works. So I guess there is a race condition. Good thing is, that you do not have to reopen the workbench for it to happen, it is enough to reopen the editor to eventually provoke the issue. I already added debug output to the ApplyColor() method of the 2-d image mapper, but it does what it is supposed to do.

I cannot imagine that this issue was not detected for a very long time. We have a few prime candidates:

  • Upgrade from VTK 8.1 to VTK 9
  • Daniel Maleike's pull request to fix MITK/VTK 2-d interaction

I am currently building the snapshot before the VTK upgrade...

Zoom into the image until you have big pixels. Click in a pixel, crosshair snaps to that pixel, color/opacity is not shown. Click on that pixel again and it works. You can also click, hold, and move the cursor. As soon as you move the cursor it works. Stops working as soon as you leave the pixel and the crosshair snaps to the next pixel.

It's definitely linked to the crosshair. If you disable the crosshair everything works immediately.

When it seems like not all windows are affected, i. e., only one window needs the extra step described above to eventually show the color, one can provoke the missing color also on the other windows by zooming or panning in them:

  • When the obviously erroneous window currently shows color, everything is okay
  • When it doesn't, the color suddenly isn't applied to the zooming/panning window neither

Update: Didn't happen with October snapshot (VTK 8.1).

kislinsk claimed this task.

Fixed! :) Was a line that I introduced in the VTK 9 migration. The plane geometry 3-d mapper accesses the 2-d image mapper textures to use them also for 3-d rendering. It also used the VTK properties of the 2-d mapper actors and manipulated them for 3-d rendering which also modified them for the 2-d mappers, though. During migration I changed that to a deep copy of the VTK properties. However, the deep copied VTK properties still contained some same pointers so there still was an interference. I fixed it now by manually copying only color and opacity VTK properties.