Page MenuHomePhabricator
Create Task
Maniphest T12815

surface normals not computed / rendered
Closed, ResolvedPublic
Actions

Description

If I create a surface with ManualSegmentationToSurfaceFilter then the surface normals are not computed, or at least they are not rendered correctly.

Reproducing the issue:

  • Build the example plugins.
  • Open a 3D image and calculate the surface with the ISO Surface view.
  • Rotate the surface by mouse dragging in the 3D render window.

You will see that the dark and light side of the object remains the same, although the object should be enlightened from the front always.

However, if you save the surface in stl format and then open the file, the surface is rendered correctly.

Saving the image in vtk/vtp format did not solve the problem, I attached a fix for this. (It also fixes a potential memory leak, a Delete() invocation was put in a wrong place.)

But I could not figure out how to display the correct surface without saving and reopening the image.

mitkVtkSurfaceReader.cpp3 KBDownload

Event Timeline

espak added projects: MITK, Bugzilla.Aug 7 2012, 7:04 PM
neher added a subscriber: neher.Sep 5 2012, 5:28 PM

Removed release as target milestone because this view is not part of the release.

• kilgus added a subscriber: • kilgus.Sep 25 2012, 3:53 PM

The component of this bug is unclear. Miklos used the example view to reproduce this issue.

Todo: Check where exactly the problem is.

franza added a subscriber: franza.Oct 31 2012, 4:53 PM

We created a surface using the ISO Surface view. The image was "Pic3D.nrrd" from the MITK-data repository. Threshold -500. There was no problem with the surface normals in this case. We also saved/loaded the surface (stl format) and it looked exactly the same. I'll attach a screenshot of the surface.

Setting the bug to "works for me". Please reopen if there is still a problem. Best is to also provide test data.

franza added a comment.Oct 31 2012, 4:53 PM

Screenshot of the surface

ScreenshotOfSurface.jpg (829×1 px, 165 KB)

zombori added a subscriber: zombori.Jan 9 2013, 7:56 PM

Hi there,
this bug is still present in our latest MITK fork, with upstream merged in December.

As before, the surface normals are still incorrect which results in the lights and shades being "stuck", so they does not follow the camera rotation. However if we save the surface to stl and load it back again it works perfectly while saving it to vtk format preserves the issue.

I am attaching a vtk example file which appears to be incorrect.

zombori added a comment.Jan 9 2013, 8:00 PM

Ok, the file was too large for attaching here, please find it on SendSpace:
http://www.sendspace.com/file/it377p

Cheers

• fetzer added a subscriber: • fetzer.Jan 23 2013, 2:11 PM

Updating target_milestone

• mersmann added a subscriber: • mersmann.Feb 6 2013, 3:44 PM

I see the problem in the data gzombori attached to this bug and try to reproduce the actual issue.

• mersmann added a comment.Feb 6 2013, 4:52 PM

@ Miklos and gzombori: As Alfred I cannot reproduce the problem from Miklos description. I see the problem in the .vtk data you attached to this bug, can you attach the source data the surface was generated from together with a detailed description of the parameters you used to generate the surface.
Did you use the 12-12 release or do you compile MITK from the current git repository?

espak added a subscriber: espak.Feb 6 2013, 6:03 PM

We use our MITK fork that has been updated to the upstream after the 12.12 release. Earlier I tried to use the "official" MITK from your git repo, but the result was the same.

Please download a sample image from here:
http://www.sendspace.com/file/dj9fld

(Max. attachment size here is 1MB.)

The easiest way to reproduce the problem is if you enable the examples in CMake, as I wrote in my first comment.

• mersmann added a comment.Feb 7 2013, 10:41 AM

Thanks Miklos for the data, I can reproduce the error now. Seems to be a problem that occurs exclusively at MR data, or did you made other experiences?

zombori added a comment.Feb 7 2013, 11:47 AM

more_data

FS.ZIP384 KBDownload

zombori added a comment.Feb 7 2013, 11:48 AM

Hi,
I have tested on a CT dataset which appeared to be OK, but when I rendered the attached set (output of freesurfer) it also fails.

• mersmann added a comment.Feb 13 2013, 5:36 PM

The problem is solved. The normals are now calculated upon generation of the surface in the mitkImageToSurfaceFilter - IO should work now. After adding the unit test for this class the solution will be committed.

• mersmann added a comment.Feb 13 2013, 5:59 PM

New remote branch pushed: bug-12815-NormalCalculationForSurfaces

espak added a comment.Feb 13 2013, 6:33 PM

Great!
Thank you, Sven!

• mersmann added a comment.Feb 20 2013, 4:45 PM

[d74532]: Merge branch 'bug-12815-NormalCalculationForSurfaces'

Merged commits:

2013-02-20 16:44:15 Sven Mersmann [4ca673]
Added some exception handling in the class and wrote unit test for mitkImageToSurfaceFilter.

2013-02-13 17:59:43 Sven Mersmann [28fc56]
Added unit test for mitkImageToSurfaceFilter class to test the made changes.

2013-02-13 16:56:42 Sven Mersmann [651456]
Normals of the surface points are calculated directly after generation of the surface. This is important for saving surfaces as .vtk and .vtp files.

• mersmann added a comment.Feb 27 2013, 12:52 PM

The bug fix is committed and should work now, set this bug on resolved fixed.

kislinsk edited projects, added MITK (2013-03); removed MITK.Aug 1 2016, 10:48 PM
MITK · MIC · IMSY · DKFZ