From group discussion> Better not to show it than to show it in the wrong place...

Fiducial and ruler do this (show up in the bottom left hand slice in the lightbox), but the ROI seems to behave properly.

ENH: Easier re-use by adding static sliceView DisplayableManager "Convert" methods

See r21245 / http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21245

JC: This seems to be a step in the right direction, I have to do the opposite (RAS -> Device) when placing the widgets to make sure it's fully working, doing that now....

Nicole:

It means you should probably be adding the static method :ConvertXYZToDevice to vtkMRMLAbstractSliceViewDisplayableManager

Then, you will be able to do:

vtkMRMLAbstractSliceViewDisplayableManager::ConvertRAStoXYZ(...)
vtkMRMLAbstractSliceViewDisplayableManager::ConvertXYZToDevice(...)

Adding the static convenience method: ConvertRAStoDevice to vtkMRMLAbstractSliceViewDisplayableManager could also be helpful.

I'm working in display coordinates rather than device/viewport coordinates with the annotation widgets (as much as possible anyway), since the display coordinates give me the index into lightbox slices as well.
I'll add those convenience methods if necessary.

device is display coordinate. Isn't it ? This at least what I understood reading the comment in Jim code. I then reported it in the doxygen.

device is viewport coordinates, from what I understood from the code.

Based on q quick experiment where I added the following code:

std::cout << "Device(x:" << pos[0] << ", y:" << pos[1] << ") - XYZ(x:" << xyz[0] << ", y:" << xyz[1] << ", z:" << xyz[2] << ")" << std::endl;

at line 755 of vtkMRMLCrosshairDisplayableManager.cxx [1]

Setting the red slice to a 3*2 lightbox, we can clearly see that:

Device is display coordinate: Where in the RenderWindow the mouse pointer is

XYZ is view port coordindate: Coordindate within a given viewport

Associated log:

Entered in (1) (see enclosed screenshot)
Device(x:344, y:623) - XYZ(x:344, y:206, z:0)
Device(x:344, y:623) - XYZ(x:344, y:206, z:0)
Device(x:343, y:621) - XYZ(x:343, y:204, z:0)
Device(x:342, y:614) - XYZ(x:342, y:197, z:0)
Device(x:342, y:612) - XYZ(x:342, y:195, z:0)
Device(x:342, y:611) - XYZ(x:342, y:194, z:0)
Device(x:342, y:610) - XYZ(x:342, y:193, z:0)
Device(x:343, y:610) - XYZ(x:343, y:193, z:0)
Device(x:343, y:611) - XYZ(x:343, y:194, z:0)
Device(x:344, y:612) - XYZ(x:344, y:195, z:0)
Device(x:345, y:612) - XYZ(x:345, y:195, z:0)
Device(x:354, y:613) - XYZ(x:354, y:196, z:0)
//// Point (2) (see enclosed screenshot)
Device(x:376, y:613) - XYZ(x:0, y:196, z:1)
Device(x:380, y:613) - XYZ(x:4, y:196, z:1)
Device(x:387, y:612) - XYZ(x:11, y:195, z:1)
Device(x:388, y:612) - XYZ(x:12, y:195, z:1)
Device(x:392, y:612) - XYZ(x:16, y:195, z:1)
Device(x:394, y:613) - XYZ(x:18, y:196, z:1)
Device(x:398, y:613) - XYZ(x:22, y:196, z:1)
Device(x:399, y:613) - XYZ(x:23, y:196, z:1)
Device(x:404, y:614) - XYZ(x:28, y:197, z:1)
Device(x:407, y:614) - XYZ(x:31, y:197, z:1)
Device(x:408, y:615) - XYZ(x:32, y:198, z:1)
Device(x:410, y:621) - XYZ(x:34, y:204, z:1)
//// Point (3) (see enclosed screenshot)

[1] https://github.com/Slicer/Slicer/blob/master/Libs/MRML/DisplayableManager/vtkMRMLCrosshairDisplayableManager.cxx#L755

According to my understanding of VTK rendering terminology, viewport coordinates always fall between 0-1, they're a normalised version of display coordinates achieved by dividing by the window width/height.
Taking another look at how the terminology is used in Slicer, but I've got a fix for the "click in light box, get the correct RAS location" problem, svn 21255[1] fixes that

Working on updating vtkMRMLAnnotationDisplayableManager::GetWorldToDisplayCoordinates
and how the return coordinates are used to position annotations.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/Modules/Loadable/Annotations/MRMLDisplayableManager/vtkMRMLAnnotationDisplayableManager.cxx?r1=21255&amp;r2=21254&amp;pathrev=21255

Disabling showing fiducials and rulers in 2d slice viewers that are in lightbox mode (also compare viewers as they use lightbox). svn 21263.

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21263

Revisit after RSNA

Cleaned up the displayable manager code a bit in svn 21310[1], updated conversion of RAS to display coordinates to use vtkMRMLAbstractSliceViewDisplayableManager::ConvertRASToXYZ(
but keeping lightbox mode disabled while further debugging it

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21310

Noticed that the number of renderers doesn't necessarily match the number of light boxes (seems to grow but not shrink), so check the lightbox index first in svn 21312[1] and also check if the widget needs it's renderer reset to avoid flickering. The current code also disables moving the widgets while in lightbox mode, that will need to be addressed.

Looking at the Crosshair displayable manager, I think that the annotation displayable managers may need to include a vtkLightBoxRendererManager (from CTK) in order to be able to get the correct renderer to assign to the widgets.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21312

After some research and debugging, Nicole and I realized that the (one) underlying issue is that the render window has more renderers than lightbox cells. This was something Jim apparently ran into and fixed about a year ago for the crosshairs, and he added a proxy that gives access to ctk's lightbox manager. This is needed in order to map XYZ coordinates to the proper renderer, but this has not been generalized to support other displayable managers. (Note that the vtkMRMLModelSliceDisplayableManager also only displays in the first cell of a lightbox.

Suggestions:

For 4.2.1: move the lightbox proxy up to the abstract displayable manager class level so that it is available to all displayable manager subclasses. This would mean adding it to the initialize methods for the displayable manager groups. ThreeD displayable managers could just return the single renderer, while slice views could use the proxy to get the correct renderer for the given coordinate (Z coordinate of XYZ space).

For 4.3: factor out more of the redundant code from displayable managers into the abstract class. Functionality to factor out:

• watching the scene for add/remove of node classes

• adding/removing observers for the nodes in the current scene

• managing display pipelines associated with node instances and triggering updates on those pipelines based on changes to the scene. Note that for displayable managers like the ModelSlice, there needs to be one pipeline PER node instance PER renderer so that the correct slice intersections will show up in each cell of the lightbox.

Another question to investigate: why are there extra renderers in the slice view render windows that do not get removed. Specifically, at startup there are 2 renderers, then going to 3x3 lightbox mode there become 10 renderers (going back to 1x1 there are still 10 renderers). Going to 6x6 led to 45 renderers, and those remain even after going back to 1x1 mode.

I had forgotten about the lightboxmanagerproxy. Yes, I had that same issue that I couldn't map to the correct renderer without asking CTK do it. Of course, the display able managers don't know about CTK, hence the proxy.

I always thought there one extra renderer for the overlay plane. That assumption sounds good until your 6x6 example.

Yes, we were also confused by why there are ever extra and/or non-consistent renderers. We did another test where we tried to only use the last row x column renders in the list but that didn't appear to work either.

Note 7029 sounds like a good approach, I would be happy to review topic regarding the moving of the proxy.

I create issue 0002732 to track it and it is assigned to Jim.

Jim> Can you take care of the refactor ?

NOTE: When done, the change should NOT be pushed on the trunk. Instead, a github topic should be referenced as a note to issue 0002732 for review.

JC, since you do not want this immediately pushed to the trunk, do you want to this based off a particular branch? trunk or 4.2?

Jim: Just based your topic on today's master.

git chechout -b 2732-move-lightbox-to-abstract-displayable-manager

Nicole will then based her topic named "1690-fiducial-shows-in-wrong-lightbox-cell" on yours.

Jim: any updates?

Pushed a patch to https://github.com/millerjv/Slicer4/commit/55f9c1c637f4ef4ba5c0da8b442aac57626d10c7

Branch is "2732-move-lightbox-to-abstract-displayable-manager"

commit 55f9c1c637f4ef4ba5c0da8b442aac57626d10c7
Author: Jim Miller <millerjv@ge.com>
Date: Wed Nov 14 11:29:39 2012 -0500

BUG: 0002732 move light box renderer manager proxy to abstract displayable manager

Moved the LightBoxRendererManagerProxy up to the superclass of the
DisplayableManager hierarchy so that all (2D & 3D) displayable managers
can interact with a lightbox.

Note that light boxes are only currently supported on 2D viewers, so the
proxy is only configured in qMRMLSliceView. CTK will need to be changed to
put the LightBoxManager into ctkVTKAbstractView to make it accessible to
both ctkVTKSliceView and ctkVTKRenderView. Then qMRMLThreeDView could also
create and initialize a LightBoxManagerProxy and set it on its DisplayableManagers.
Here, we would also want to move qMRMLSliceViewPrivate::vtkInternalLightBoxRendererManagerProxy
class to a place where it could be used by both types of VTK widgets.

The proxy can now be set on the DisplayableManagerGroup which broadcasts
the proxy to all the DisplayableManagers in that group.

Thanks Jim. Looks great.

Nicole> Is this sufficient for you to make progress ?

branched from jim's branch and got my github Slicer fork update, but my first attempt to use the GetRenderer(idx) didn't work, will continue in the morning.

Hi Nicole,

Any update regarding that issue ? Are the change of Jim working for you ? Can his topic be integrated ?

Thanks
Jc

Jim's change is helpful, but the problem turned out to be that the widgets being used in the 2d views were using 3d handle representations, and their cameras weren't correct.
Steve and I tired to reset the cameras to something sensible, but that didn't work, and would need to be supported at all levels of the layouts/viewers.
Seed widgets in light box mode did work if I switched to using a 2d point handle (no label text). That also solved the layout change position switching bug as a neat side effect.
The problem with going to a 2d point handle is that I have to redo a lot of the displayable manager code to include a sub case of the 2d case for lightbox (so that we keep the text/colours/glyphs in non light box mode). Markups module rewrite will have two separate dispalayble managers, one for 2d and one for 3d and will avoid this problem.

I cleaned up the first part of the fix and pushed to my github:
https://github.com/naucoin/Slicer/commit/2b21cea6c1a120d8df32919c870c8507df9a7022
That uses the light box proxy renderer, but doesn't fix the location yet.

Have the 2d point handle mostly working :
https://github.com/naucoin/Slicer/commits/1690-fiducial-shows-in-wrong-lightbox-cell

The main problem left is that when you switch into and out of light box mode, the fiducials aren't getting their handles updated. They will update once the fid is moved in 3d, but that's not ideal.
Looking into why not getting the slice node modified event and responding to it.

Thanks for the update. Seems important progress are made :)

Okay, done for now:
the code on my github will favour over processing and resetting the fiducial handles on slice node changes rather than just setting the position if the fid is visible. This fixes (as far as I can tell) swapping into and out of light box mode without breaking anything else.

https://github.com/naucoin/Slicer/commits/1690-fiducial-shows-in-wrong-lightbox-cell

I'm going to submit an experimental build to the dashboard (host name b2-d4-10.bwh.harvard.edu) to see what happens, will look at it again in the morning.

I did some more testing with the prostate demo scene. It looks like things are very close - the crash I found is an issue in VTK - the WorldToView method checks for ActiveCamera, but the ViewToWorld doesn't -- the patch below fixes this and makes the prostate scene load correctly.

There is still the issue that you need to trigger some of the updates manually in order for fiducials to appear. We should look at the scene with Andrey to be sure the fiducials are in the right places.

0000159 Slicer-superbuild $ (cd VTK; git diff)
diff --git a/Rendering/vtkRenderer.cxx b/Rendering/vtkRenderer.cxx
index d99dad5..b739122 100644
--- a/Rendering/vtkRenderer.cxx
+++ b/Rendering/vtkRenderer.cxx
@@ -1322,6 +1322,12 @@ void vtkRenderer::ViewToWorld(double &x, double &y, double &z)
double result[4];

// get the perspective transformation from the active camera

• if (!this->ActiveCamera)
• {
• vtkErrorMacro("ViewToWorld: no active camera, cannot compute world to view, returning 0,0,0");
• x = y = z = 0.0;
• return;
• }
  vtkMatrix4x4 *matrix = this->ActiveCamera->
  GetCompositeProjectionTransformMatrix(
  this->GetTiledAspectRatio(),0,1);

Steve: Thanks for proposing the VTK patch. I guess now is the good time to get your gerrit account for VTK :) See http://www.vtk.org/Wiki/VTK/Git/Develop
Then consider reading section "Share a topic"

Nicole> Jim changes regarding lightbox proxy have been integrated.
See r21431 / http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21431

I am assuming the following commits of your topic are final ? Talking about these commits: https://github.com/naucoin/Slicer/compare/555faa90001b8af89a31a98202142539cb35476e...1690-fiducial-shows-in-wrong-lightbox-cell

Those commits are final, but I'm working on another one to try and fix the prostate demo crash (hopefully just need to set the renderer on the widget representation in create widget).

Nope, quick fix didn't work.

This is kind of odd: in the debugger, at the crash point the renderer is valid but the camera is not:
(gdb) frame 0
#0 0x00007fffe9b05fc4 in vtkRenderer::ViewToWorld (this=0xd9be8e0, x=@0xe20d740, y=@0xe20d748, z=@0xe20d750)
at /projects/birn/nicole/Slicer-git/SlicerSlicer/Slicer-Superbuild/VTK/Rendering/vtkRenderer.cxx:1327
1327 this->GetTiledAspectRatio(),0,1);
(gdb) print this->ActiveCamera
$1 = (vtkCamera *) 0x0

as I was poking through the backtrace, I called GetActiveCamera() and it kept returning a valid camera. Back to frame 0, and the camera is all of a sudden valid again. It turns out that GetActiveCamera sets a camera if one isn't defined according to vtkRenderer.h.
Trying one more thing in the annotation displayable manager...

Pushed a patch to my github[1], making sure to check for a valid renderer and active camera before trying to set the display position on the seeds. Also make sure that on creation that the seed and represetnation have the correct and same renderers.

[1] https://github.com/naucoin/Slicer/commit/813046dc70286c7f81a7c5d4b125e9a5f3f2653d

Does it still make sens to rush with last minute code that may break stuff ?
I set the target date for 4.2.2 to be December 1st.
It would probably make sens to re-target this issue for December 1st.
Let me know what you think ?

Found another issue: the light box in which to display a fiducial isn't being correctly determined if the volume slice spacing is != 1.

In light of this, since we're back to the annotations occasionally showing up in the wrong place, Steve and I feel that we can retarget this for 4.2.2.

I think the central issue here is that the widgets rely on the CAMERA to properly convert to/from world coordinates.

However, Slicer really doesn't utilize the camera in the 2D views. The situation get muddled further when in lightbox mode. It is hard to follow the code but all the panes in the lightbox may share the same camera.

I think what needs to happen is that each renderer in the lightbox needs to have a unique camera AND each camera needs to configured specific for the slice that camera is displaying. This is so the widget/coordinate classes can utilize the camera projection matrix to go from World to View to Normalized Viewport to Viewport to Normalized Display to Display.

The problem here is that all the current renderering in the SliceViews assumes a default camera since handle all the mapping ourselves.

Base on recent finding and discussion. Retargeted for 4.2.2 (Dec 1st)

Make sure to update your topic so that it is based on current trunk:

Rename topic

git checkout 1690-fiducial-shows-in-wrong-lightbox-cell
git branch -M 1690-fiducial-shows-in-wrong-lightbox-cell-old

Update master

git checkout master
git checkout svn rebase

Create new topic and cherry pick commit of interest

git checkout -b 1690-fiducial-shows-in-wrong-lightbox-cell
git cherry-pick 30c8fb4
git cherry-pick 6f5cfe0
git cherry-pick b9b0163
git cherry-pick 2b21cea

Delete local obsolete topic

git branch -D 1690-fiducial-shows-in-wrong-lightbox-cell-old

Push new version of the topic on your fork

git push naucoin 1690-fiducial-shows-in-wrong-lightbox-cell --force

Thanks for the steps. I'm not using git svn, so I had to use
git pull origin master
to get the updates, and then had to issue the cherry pick commands in the reverse order, but it seems to have worked.

From hangout discussion> Make sure to consider spacing when going from Ras to lightbox coordinate.

Checked in an update to my github that takes into account volume slice spacing when in light box mode - only show fiducials that are within 0.5mm of a light box slice.
https://github.com/naucoin/Slicer/commit/9ff3c39a0931c10c2bff9edd2337ef508b54077b

Still working on debugging the swapping between 2d and 3d handles when switch between light box and 1x1 mode.

1) Extra. I added few comment on the last commit of the topic

2) Is the issue "swapping between 2d and 3d handles" a show stopper or simply a aesthetic details ?

3) Steve mentioned he would be working on the "snapping" of annotation to closed slice, has this been addressed yet ?

Hi Jc - Regarding your third point, see child issue 0002821. Nicole will respond on the others.

1. pushed commit responding to the comments
2. show stopper: the fiducials were either not appearing or appearing in the wrong place.

It looks like the current state of my github branch fixes the issues (except for a random reset to a starburst glyph instead of the circle glyph when coming back to 1x1 mode) on Mac, though Linux is still having update/renderer issues (fids show in the wrong light box cell, but update correctly on scroll).

github commit de6aa0c fixed the glyph update when switching out of light box mode.

as of svn 21495, work from github ported back to Slicer trunk. Rulers are disabled, but fiducials are re-enabled.

Should the issue be resolved ?

An other issue to keep track of the fact Ruler are disabled could be created.

There are still some issues with the display on Linux that I'd like to try and track down, but I created another issue for the rulers since they'll have their own special cases, bug # 2823

Would it be possible to list the know issues, I will then mention them in the release notes.

We should probably create separate issue to track this specific issues. That we will be able to close this one. Would that make sens ?

When switching into lightbox mode on some Linux systems (SPL workstations show this behaviour), the fiducials sometimes don't update their position until the slices are scrolled.

Download sample data: MRHead

Step1: Lay down some fiducials along the slicer intersection
Step2: Switch to lightbox. Attempt to move the visible fiducial -> crash

See screenshots issue1690_r21495_step{1,2}.png

I can't replicate the crash reported in 7461. Can you generate a stack trace?

Experience 2:

1) Load sample data MRHead

[[ 2) Enable slice interaction ]] -> don't think that is related to the issue

3) Set annationation mode to persistent

4) Lay down a lot of fiducial.
See experience2_issue1690_r21495_step1.png

5) Switch yellow slice to 1x6 light box.
See experience2_issue1690_r21495_step2.png

6) Try to select the cross -> impossible to really move them.
See experience2_issue1690_r21495_step3.png

7) Go back to normal view 1x1
Forgot to take screenshot ...

8) Go back to 1x6 - move fiducial and or the cross -> crash
See experience2_issue1690_r21495_step5.png

Experience 3: Associated screenshots shows the corresponding stacktrace

I was never able to get it to crash, but I did see that in 1xN modes the conversion from 3D to 2D fiducials and back again wasn't reliable. I can see how this would lead to a crash. I didn't see this for MxN modes where M > 1 so that may be a clue for debugging.

Following JC's steps in note 7463 I was able to get a crash as well. Only some of the fiducials that I placed updated to 2d/3d when swapping in and out of lightbox, but as I interacted with them via the Fids module GUI, updates led to the 3d ones disappearing entirely. Part of it is that the visibility check is done first (is the fid in the fov of the new narrower viewport brought about by swapping to 1xN mode?) and then the 2d/3d update is triggered and that does't happen if the fid isn't visible. Still tracing through all the paths that various events can lead to to try and shut down the error cases.

Double checked this with the Markups module, no crashing, but it is showing some odd behaviour that I think is related to the slice node / layout update and widget refresh rate.

Still working on this one, don't think it'll be done by Tuesday morning.
Issues found/fixed so far:

• use the superclass GetMRMLSliceNode instead of holding onto a local slice node that doesn't get updated
• added a vtkInternal to mirror the crosshair displayable manager and to add an observation on the composite node so get events when change into a new layout and set the background volume
• the widget was being enabled/disabled and over riding the seed handle enabled states, leftover assumptions from the annotations module where there was only one seed per seed widget, still debugging this
• related: need to get the light box index and the proper renderer when in lightbox view and set those on the individual seed handles without getting into a state where the seed widget doesn't have a renderer or has the wrong one. It may come to having to switch to a one seed per widget model when in light box mode...
• having a chicken/egg problem when changing layouts, the layout node broadcasts that it's changed the layout, and a new view node gets added, and the displayable manager is added by the displayable manager group and wants to create and update widgets. The only problem is that the viewers haven't been fully set up yet, so there's either no renderer or no active camera on the renderer and I end up with a null pointer crash in VTK Rendering. This may require some refactoring of events above the Markups module when changing layouts:

Program received signal SIGSEGV, Segmentation fault.
0x00007f173efb7f88 in vtkRenderer::ViewToWorld (this=0x6e10ee0, x=@0x6efd3e0, y=@0x6efd3e8, z=@0x6efd3f0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Rendering/vtkRenderer.cxx:1327
1327 this->GetTiledAspectRatio(),0,1);
(gdb) bt
#0 0x00007f173efb7f88 in vtkRenderer::ViewToWorld (this=0x6e10ee0, x=@0x6efd3e0, y=@0x6efd3e8, z=@0x6efd3f0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Rendering/vtkRenderer.cxx:1327
0000001 0x00007f172ba3de0d in vtkCoordinate::GetComputedWorldValue (this=0x6efd380, viewport=0x6e10ee0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Filtering/vtkCoordinate.cxx:209
0000002 0x00007f1740aff07f in vtkPointPlacer::ComputeWorldPosition (this=0x6ef2a60, ren=0x6e10ee0, displayPos=0x7fff4cb9a970, worldPos=0x7fff4cb9a7b0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Widgets/vtkPointPlacer.cxx:54
0000003 0x00007f1740a82629 in vtkHandleRepresentation::SetDisplayPosition (this=0x6efc700, displyPos=0x7fff4cb9a970)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Widgets/vtkHandleRepresentation.cxx:62
0000004 0x00007f1740af94ed in vtkPointHandleRepresentation2D::SetDisplayPosition (this=0x6efc700, p=0x7fff4cb9a970)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Widgets/vtkPointHandleRepresentation2D.cxx:137
0000005 0x00007f1740b24fda in vtkSeedRepresentation::SetSeedDisplayPosition (this=0x6ef2580, seedNum=0, pos=0x7fff4cb9a970)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Widgets/vtkSeedRepresentation.cxx:115
0000006 0x00007f1706eedd57 in vtkMRMLMarkupsFiducialDisplayableManager2D::UpdateNthSeedPositionFromMRML (this=0x6e2b180, n=0, widget=0x6ef92a0, pointsNode=
0x67e87e0) at /projects/birn/nicole/Slicer42/Slicer/Modules/Loadable/Markups/MRMLDM/vtkMRMLMarkupsFiducialDisplayableManager2D.cxx:421
0000007 0x00007f1706eee9c1 in vtkMRMLMarkupsFiducialDisplayableManager2D::SetNthSeed (this=0x6e2b180, n=0, fiducialNode=0x67e87e0, seedWidget=0x6ef92a0)
at /projects/birn/nicole/Slicer42/Slicer/Modules/Loadable/Markups/MRMLDM/vtkMRMLMarkupsFiducialDisplayableManager2D.cxx:488
---Type <return> to continue, or q <return> to quit---
0000008 0x00007f1706ef2024 in vtkMRMLMarkupsFiducialDisplayableManager2D::PropagateMRMLToWidget (this=0x6e2b180, node=0x67e87e0, widget=0x6ef92a0)
at /projects/birn/nicole/Slicer42/Slicer/Modules/Loadable/Markups/MRMLDM/vtkMRMLMarkupsFiducialDisplayableManager2D.cxx:1039
0000009 0x00007f1706ee3003 in vtkMRMLMarkupsDisplayableManager2D::AddWidget (this=0x6e2b180, markupsNode=0x67e87e0)
at /projects/birn/nicole/Slicer42/Slicer/Modules/Loadable/Markups/MRMLDM/vtkMRMLMarkupsDisplayableManager2D.cxx:1635
0000010 0x00007f1706edbaca in vtkMRMLMarkupsDisplayableManager2D::UpdateFromMRML (this=0x6e2b180)
at /projects/birn/nicole/Slicer42/Slicer/Modules/Loadable/Markups/MRMLDM/vtkMRMLMarkupsDisplayableManager2D.cxx:389
0000011 0x00007f1706edc334 in vtkMRMLMarkupsDisplayableManager2D::UpdateFromMRMLScene (this=0x6e2b180)
at /projects/birn/nicole/Slicer42/Slicer/Modules/Loadable/Markups/MRMLDM/vtkMRMLMarkupsDisplayableManager2D.cxx:530
0000012 0x00007f1748a8ff54 in vtkMRMLAbstractLogic::ObserveMRMLScene (this=0x6e2b180)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLAbstractLogic.cxx:494
0000013 0x00007f1748a8f638 in vtkMRMLAbstractLogic::SetMRMLScene (this=0x6e2b180, newScene=0x21d1b60)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLAbstractLogic.cxx:285
0000014 0x00007f1748df23a1 in vtkMRMLAbstractDisplayableManager::SetAndObserveMRMLDisplayableNode (this=0x6e2b180, newMRMLDisplayableNode=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/DisplayableManager/vtkMRMLAbstractDisplayableManager.cxx:823
0000015 0x00007f1748df72f3 in vtkMRMLDisplayableManagerGroup::SetMRMLDisplayableNode (this=0x6e366f0, newMRMLDisplayableNode=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/DisplayableManager/vtkMRMLDisplayableManagerGroup.cxx:383
---Type <return> to continue, or q <return> to quit---
0000016 0x00007f174ced95fb in qMRMLSliceView::setMRMLSliceNode (this=0x6e0b210, newSliceNode=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Widgets/qMRMLSliceView.cxx:290
0000017 0x00007f174cedbdf8 in qMRMLSliceWidget::setMRMLSliceNode (this=0x69140d0, newSliceNode=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Widgets/qMRMLSliceWidget.cxx:122
0000018 0x00007f174ce7cf5e in qMRMLLayoutManagerPrivate::createSliceWidget (this=0x354da10, sliceNode=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Widgets/qMRMLLayoutManager.cxx:269
0000019 0x00007f174d2f156c in qSlicerLayoutManagerPrivate::createSliceWidget (this=0x354da10, sliceNode=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Base/QTGUI/qSlicerLayoutManager.cxx:75
0000020 0x00007f174ce7daec in qMRMLLayoutManagerPrivate::onNodeAddedEvent (this=0x354da10, scene=0x21d1b60, node=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Widgets/qMRMLLayoutManager.cxx:433
0000021 0x00007f174cf0f677 in qMRMLLayoutManagerPrivate::qt_metacall (this=0x354da10, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff4cb9b2d0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/Slicer-build/Libs/MRML/Widgets/moc_qMRMLLayoutManager_p.cxx:86
0000022 0x00007f1742b51f88 in QMetaObject::activate(QObject, QMetaObject const, int, void**) ()
from /projects/birn/nicole/Qt/QtSDK/Desktop/Qt/474/gcc/lib/libQtCore.so.4
0000023 0x00007f1746fd2eda in ctkVTKConnection::emitExecute (this=0x355f500, _t1=0x21d1b60, _t2=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK-build/CTK-build/Libs/Visualization/VTK/Core/moc_ctkVTKConnection.cxx:99
---Type <return> to continue, or q <return> to quit---
0000024 0x00007f1746fbce3a in ctkVTKConnectionPrivate::execute (this=0x3566320, vtk_obj=0x21d1b60, vtk_event=8193, client_data=0x3566320, call_data=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK/Libs/Visualization/VTK/Core/ctkVTKConnection.cpp:405
0000025 0x00007f1746fbcb8e in ctkVTKConnectionPrivate::DoCallback (vtk_obj=0x21d1b60, event=8193, client_data=0x3566320, call_data=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK/Libs/Visualization/VTK/Core/ctkVTKConnection.cpp:368
0000026 0x00007f172b2a93ab in vtkCallbackCommand::Execute (this=0x36a7be0, caller=0x21d1b60, event=8193, callData=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkCallbackCommand.cxx:42
0000027 0x00007f17415f712a in vtkEventBroker::InvokeObservation (this=0x212c440, observation=0x36a85a0, eid=8193, callData=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkEventBroker.cxx:868
0000028 0x00007f17415f66ff in vtkEventBroker::ProcessEvent (this=0x212c440, observation=0x36a85a0, caller=0x21d1b60, eid=8193, callData=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkEventBroker.cxx:716
0000029 0x00007f17415f7719 in vtkEventBroker::Callback (caller=0x21d1b60, eid=8193, clientData=0x36a85a0, callData=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkEventBroker.cxx:943
0000030 0x00007f172b2a93ab in vtkCallbackCommand::Execute (this=0x36a7b90, caller=0x21d1b60, event=8193, callData=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkCallbackCommand.cxx:42
0000031 0x00007f172b38997f in vtkSubjectHelper::InvokeEvent (this=0x21cf6a0, event=8193, callData=0x6da5920, self=0x21d1b60)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkObject.cxx:620
---Type <return> to continue, or q <return> to quit---
0000032 0x00007f172b389e8f in vtkObject::InvokeEvent (this=0x21d1b60, event=8193, callData=0x6da5920)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkObject.cxx:789
0000033 0x00007f1741795cd0 in vtkMRMLScene::AddNode (this=0x21d1b60, n=0x6da5920) at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkMRMLScene.cxx:1342
0000034 0x00007f1748ab04c3 in vtkMRMLLayoutLogic::CreateMissingViews (this=0x354ec40, layoutRootElement=0x2fbde30)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLLayoutLogic.cxx:1367
0000035 0x00007f1748ab00ab in vtkMRMLLayoutLogic::CreateMissingViews (this=0x354ec40)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLLayoutLogic.cxx:1339
0000036 0x00007f1748aac798 in vtkMRMLLayoutLogic::UpdateFromLayoutNode (this=0x354ec40)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLLayoutLogic.cxx:754
0000037 0x00007f1748aac1d1 in vtkMRMLLayoutLogic::OnMRMLNodeModified (this=0x354ec40)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLLayoutLogic.cxx:659
0000038 0x00007f1748a9006d in vtkMRMLAbstractLogic::ProcessMRMLNodesEvents (this=0x354ec40, caller=0x3562e80, event=33)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLAbstractLogic.cxx:517
0000039 0x00007f1748a8f11b in vtkMRMLAbstractLogic::MRMLNodesCallback (caller=0x3562e80, eid=33, clientData=0x354ec40, callData=0x0)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Logic/vtkMRMLAbstractLogic.cxx:197
0000040 0x00007f172b2a93ab in vtkCallbackCommand::Execute (this=0x356d9a0, caller=0x3562e80, event=33, callData=0x0)
---Type <return> to continue, or q <return> to quit---
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkCallbackCommand.cxx:42
0000041 0x00007f172b38997f in vtkSubjectHelper::InvokeEvent (this=0x354dad0, event=33, callData=0x0, self=0x3562e80)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkObject.cxx:620
0000042 0x00007f172b389e8f in vtkObject::InvokeEvent (this=0x3562e80, event=33, callData=0x0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkObject.cxx:789
0000043 0x00007f172b38a05e in vtkObject::Modified (this=0x3562e80) at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/VTK/Common/vtkObject.cxx:855
0000044 0x00007f1741e2d002 in vtkMRMLNode::InvokePendingModifiedEvent (this=0x3562e80) at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkMRMLNode.h:380
0000045 0x00007f1741e2a000 in vtkMRMLNode::EndModify (this=0x3562e80, previousDisableModifiedEventState=0)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkMRMLNode.h:228
0000046 0x00007f174184dc15 in vtkMRMLLayoutNode::SetViewArrangement (this=0x3562e80, arrNew=12)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Core/vtkMRMLLayoutNode.cxx:205
0000047 0x00007f174ce800ea in qMRMLLayoutManager::setLayout (this=0x3568020, layout=12)
at /projects/birn/nicole/Slicer42/Slicer/Libs/MRML/Widgets/qMRMLLayoutManager.cxx:965
0000048 0x00007f174cf0ec9e in qMRMLLayoutManager::qt_metacall (this=0x3568020, _c=QMetaObject::InvokeMetaMethod, _id=7, _a=0x7fff4cb9be60)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/Slicer-build/Libs/MRML/Widgets/moc_qMRMLLayoutManager.cxx:142
0000049 0x00007f174d35489a in qSlicerLayoutManager::qt_metacall (this=0x3568020, _c=QMetaObject::InvokeMetaMethod, _id=13, _a=0x7fff4cb9be60)
---Type <return> to continue, or q <return> to quit---
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/Slicer-build/Base/QTGUI/moc_qSlicerLayoutManager.cxx:68
0000050 0x00007f17457e333a in PythonQtCallSlot (classInfo=0x2948f90, objectToCall=0x3568020, args=0x35cc5d0, strict=false, info=0x3ea2730, firstArgument=0x0,
pythonReturnValue=0x7fff4cb9c158, directReturnValuePointer=0x0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK-build/PythonQt/src/PythonQtSlot.cpp:171
0000051 0x00007f17457e4d4f in PythonQtSlotFunction_CallImpl (classInfo=0x2948f90, objectToCall=0x3568020, info=0x3ea2730, args=0x35cc5d0, firstArg=0x0,
directReturnValuePointer=0x0) at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK-build/PythonQt/src/PythonQtSlot.cpp:338
0000052 0x00007f17457e3e9d in PythonQtMemberFunction_Call (info=0x3ea2730, m_self=0x35c8110, args=0x35cc5d0, kw=0x0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK-build/PythonQt/src/PythonQtSlot.cpp:250
0000053 0x00007f17457e3ab3 in PythonQtSlotFunction_Call (func=0x35cdb90, args=0x35cc5d0, kw=0x0)
at /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/CTK-build/PythonQt/src/PythonQtSlot.cpp:238
0000054 0x00007f174630ade3 in PyObject_Call () from /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/python-install/lib/libpython2.7.so
0000055 0x00007f17463adf1d in PyEval_EvalFrameEx () from /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/python-install/lib/libpython2.7.so
0000056 0x00007f17463af4ce in PyEval_EvalFrameEx () from /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/python-install/lib/libpython2.7.so
0000057 0x00007f17463b05ce in PyEval_EvalCodeEx () from /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/python-install/lib/libpython2.7.so
0000058 0x00007f174633de51 in function_call () from /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/python-install/lib/libpython2.7.so
0000059 0x00007f174630ade3 in PyObject_Call () from /projects/birn/nicole/Slicer42/Slicer4-SuperBuild-Debug/python-install/lib/libpython2.7.so

The crux of the current problem with changing

Possibly related issue found while trying to debug missing key press events:

I think I copied the method to add an initial initialize step in the displayable mangers from a source with a typo in it.
In vtkMRMLAbstractDisplayableManager.h it's:
AdditionalInitializeStep
but in vtkMRMLCameraDisplayableManager.h it's:
AdditionnalInitializeStep
with an extra n. Using that signature, it was never getting called in my Markups displayable managers.

Doing a quick test to see what happens when I take the extra n out of the camera displayable manager, I noticed that it's got an assert, and that it's setting the active camera on the renderer, which might explain some of the problems seen in this bug if it wasn't getting triggered. Building now and will run tests and upload them to the dashboard with the camera displayable manager change.

Spelling mistakes are nasty bugs. Had one a while ago where the function name in the superclass had a typo. So my classes correctly spelled function override was never called.

Did this fix the issue?

Unfortunately it didn't fix this issue, but I suspect that's partially because I'd already put in code to catch null pointers. I want to check in the fix though as it is a bug and it didn't break any of the tests when I submitted an experimental build, these failing tests are due to a corrupted mrb and a widget size check failing:
http://slicer.cdash.org/viewTest.php?onlyfailed&amp;buildid=158070

Checked in the fix as svn 22611:
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=22611

Backported r22611 to branch Slicer-4-3.

See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=22626

Will take another run at resolving this issue, but if not we will disable the fiducials when in light box mode and provide a dialog box warning users that fiducials will disappear when going into light box mode.

@Steve, @nicole: What about re-using the logic used by the cross-hair ?

@jcfr I'm fine with that. @Nicole let us know if you need another set of eyes on this.

I already implemented the cross hair logic, the error is currently from using the vtkSeedWidget as a 2d implementation. I have some code in a topic branch that might fix it, I need to rebase it and recheck it.

Excellent. Let me know if you like me to test a topic.

For reference, commit r23841 [1] should help to address the "no active camera" warning/issue.

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=23841

Disabling fiducials in light box mode:

I¹m fairly certain that this logic check is backward since the point handles were becoming visible again when I¹d mouse near them after turning their visibility off:
https://github.com/Slicer/VTK/blob/slicer-v6.3.0-2015-07-21-426987d/Interaction/Widgets/vtkPointHandleRepresentation2D.cxx#L176
I can get around it by turning the active representation on in Slicer, will submit a patch when I'm sure it works.

Considering the documentation:

// Description:
// Flag controls whether the widget becomes visible when the mouse pointer
// moves close to it (i.e., the widget becomes active). By default,
// ActiveRepresentation is off and the representation is always visible.

the code makes sense.

By setting the property "ActiveRepresentation" to 1, the widget will be hidden if the mouse is away, and visible if it is nearby.

That said, to ensure that the visibility of a widget representation is not affected by the mouse, seems you need to disable the widget to ensure mouse interaction won't affect the visibility of the associated representations.

See https://github.com/Slicer/VTK/blob/8e43f69ff8ae0b5c464f431acc2ae48780a51ce6/Interaction/Widgets/vtkAbstractWidget.h#L69-L75

For markups, that means that:

• LOCKED:

  • TRUE: widget enabled
  • FALSE: widget disabled

• VISIBLE:

  • TRUE: visibility on
  • FALSE: visbility off + widget disabled

In any case, ActiveRepresentation should be set to 0.

Thanks for the clarification, I'll double check my logic!

I'm still unable to get the seed widget to behave properly when swtiching between lightbox and non light box modes in terms of having the correct types of handles (I'd tried to fix this issue by moving to 2d point handles when in light box) and the correct number of handles (found a state where there's a mix of types). Will pick it up again tomorrow, I won't be able to fix it tonight.

For the ActiveRepresentatin, this is the annotated code snippet that's confusing me:
// by default, the handle is visible:
this->VisibilityOn();
double tol2 = this->Tolerance * this->Tolerance;
if ( vtkMath::Distance2BetweenPoints(xyz,pos) <= tol2 )
{
// the mouse is nearby, the handle is always visible
this->InteractionState = vtkHandleRepresentation::Nearby;
}
else
{
// the mouse isn't nearby
this->InteractionState = vtkHandleRepresentation::Outside;
// if the handle is not supposed to be visible due to other factors than nearby/outside, but active representation is on, this check leaves the handle visible, over riding the visibility off call made elsewhere due to the default above.
if ( this->ActiveRepresentation )
{
this->VisibilityOff();
}
}

I see what you mean about the enabled state, but it seems backward to me that this is the current default behaviour (with active representation off):
I set this handle to be invisible.
I mouse near it, it becomes visible again.

Topic branch disabling showing fiducials has been pushed:
https://github.com/naucoin/Slicer/tree/1690-Fiducial-shows-in-wrong-lightbox-cell
Pull request:
https://github.com/Slicer/Slicer/pull/399

Integrated in r24726
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=24726

Note that in rr24727, I added a check to disable the popup if testing is enabled.

Considering how difficult (I would say practically nearly impossible) to implement interactions correctly in lightbox views - what about taking a different approach and generating lightbox views as static image mosaics instead? Posted more details and asked for feedback here: https://discourse.slicer.org/t/who-uses-lightbox-view/495

Retarget stale issues to backlog.