Missing scene view thumbnails, Marianna redid them and gave me a new .mrb file to upload for nightly testing. Waiting on Midas registration.

New mrb uploaded and test updated, svn 21020.

Restoring scene views is crashing, parsing of the compare view layout.

On scene view restore, the mrml layout manager gets in a state with an invalid relationship between view and viewNode and widgets. Trying to reset at that point just pushes the crash to the second view restore.

When loading the scene, get two vtkMRMLViewNodes in the scene, both with singleton tags '1' and '2', and ids: vtkMRMLViewNode1, vtkMRMLViewNode2 (both have the attribute MappedInLayout set to 1)

Getting the first scene view's node collection, it has one view node, with singleton tag '2' and id vtkMRMLViewNode2.

Turns out that the mrml file has some errors in it: the scene views referenced both view node 1 and 2 but view node 1 isn't defined in the scene views. On restore, view node 1 is removed and the restored camera node points to an invalid view. I wasn't able to make the layout manager gracefully recover from this error state, so I'm uploading a new .mrb file with a corrected .mrml file in it.

Got it to upload with the same id, so tests should run with the new .mrb file from now on.

This test was crashing for the last few days in an assert due to missing views on scene restore.

I found a fix for this that avoids the crash and appears to be consistent with the logic of the layout manager as far as I can tell. I will go ahead and commit it and then email this note to Julien so he can have a look.

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

The brain atlas test was also crashing, even after the fix to the abdominal atlas case. The fix in revision 21176 fixes the issue with the layout node becoming invalid.

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

Comment 0006520:
Concerning, http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21174, I don't understand why onSceneRestoredEvent was needed in the first place. Jim, do you remember what was your issue at that time?
From my understanding, qMRMLLayoutManager should only be answering to BatchProcess events: after a batch process (restoring should be a batch process) first the widgets are updated from the view nodes in the scene, and then the layout is refreshed from the layout node.
So onSceneRestoredEvent shouldn't be needed (why does it call Modified() on the layout node if the layout node hasn't been modified ?). Moreover, as it is mentioned in here, the order of calls is sensitive. Maybe onSceneRestoredEvent is calling things too early (before the EndBatchProcessEvent calls are made.) Maybe updateWidgetsFromViewNodes and updateLayoutFromMRMLScene should just be called from a single slot that ensures the order.

Comment 0006521:
Concerning http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21176, I don't understand why the layout node should be cleared when a scene is restored. The layout being a singleton, and the fact that there is a layout node in all scene views, the layout node should stay valid even after the scene is being restored. Maybe the issue you experienced come from a) where onSceneRestoredEvent shouldn't even be called.
As a side note, I would agree that vtkMRMLLayoutLogic::LayoutNode could be a SmartPointer for more safety.

I think there's also an issue with the test download mechanism - it just checks that there's already a file on disk with the given name, and it's not getting the updated mrb with the fixed MRML file (I just uploaded a new copy, the URL and name are the same, but file sizes are different: 34.2Mb for the second version, 36.4Mb for the first version).
When I had been digging into this crash these sound like the issues I was encountering, I'm rebuilding and testing the current code with both versions of the mrb now...

Yes, if the data changes right now you would need to give it a new name in midas. (actually a new name in the temp directory is enough).

I added a topic for the January meeting to discuss self-tests (we can make this a formal project and discuss our experiences).

http://www.na-mic.org/Wiki/index.php/AHM_2013

Added a note to the documentation.

http://www.slicer.org/slicerWiki/index.php?title=Documentation%2FNightly%2FDevelopers%2FTutorials%2FSelfTestModule&diff=28528&oldid=28357

Instead of giving a different name, I would suggest these two possible approaches:

1) Hardcode the md5 into the sampledata module. Before re-downloading a file, the module would compare the hard-coded MD5 with the MD5 of the file on disk. To avoid computing the MD5, the module could simply create a file named: <name-of-file>.md5 and compare the content of that file with the hard-coded one.

We could also download the file from midas using their md5 ... 

2) If we don;t want to hard-code the md5, we could also teach the module how to retrieve the md5 from midas.

I would suggest we implement approach (1).

Tested on Mac 64 bit using rc 1 2012-10-29 svn r21280 - segmentation volume color table is all black

Tested on Linux 64 bit using rc 1 2012-10-29 svn r21280 - segmentation volume color table is all black

Since MRB and sceneview are not required to run the tutorial, these issues are considered resolved.

Nicole, make sure to provide archive with MRML file(s) and data in a archive file that could be used after being extracted.

Thanks

Segmentation volume color table being all black was resolved, mrb is working well now:
http://slicer.kitware.com/midas3/download?items=8301

Excellent.
Is there anything to update on the 4.2 branch ? Self test may be ?

No update needed, new revision of the mrb uses the same url.
The tests for all atlases are already in place and running nightly or as self tests via the AtlasTests.py file.

Closing resolved issues that have not been updated in more than 3 months