| gaoh | |
| Jan 27 2021, 12:34 PM |
| 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 |
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... ,
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | kislinsk | T28000 MITK v2021.02 | ||
| Resolved | kislinsk | T28211 [Image Rendering] Color change/ Opacity strange behaviour (only in Windows installers) |
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? 🐛
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.
Another impact is shown in T28245: [Segmentation] 3D Region Growing preview does not show a binary mask in Windows Installer.
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:
I am currently building the snapshot before the VTK upgrade...
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:
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.