Page MenuHomePhabricator

MPR displays pixel brightness mismatch
Closed, DuplicatePublic

Assigned To
None
Authored By
neuhaus
Aug 14 2009, 1:36 PM
Referenced Files
F293: Geometry3D.patch
Nov 4 2009, 3:59 PM
F292: Geometry3D.patch
Oct 23 2009, 5:15 PM
F291: Geometry3D.patch
Oct 16 2009, 3:01 PM
F290: Patch.txt
Aug 26 2009, 4:37 PM

Description

looking at the attached screenshot, the red window shows a dark pixel under the cross while the green and blue windows show a bright pixel. This is apparently a mismatch that should not exist.

The statusbar pixelvalue display claims that the pixelvalue is -1023, which should be rendered as dark.

The test dataset is located at /home/jochen/temp/mpr pixel mismatch bug testdataset.pic.gz

coordinates of the test position can be seen in the statusbar in the screenshot

pixel display difference in MPR - red = dark, green and blue = bright, pixelvalue = -1023.png (1×1 px, 145 KB)

Event Timeline

The StatusBar pixel value display seems to use real mouse click coordinates, not cross positions. Clicking in the green window slightly left/right of the blue line but inside the same visible pixel changes the pixel value display dramatically. Maybe the 2D rendering is just slightly misaligned?

a reinit on the dataset seems to have solved the visualization issue, but the discrepancy between the status bar pixel value display and the rendering still remains. I believe, the rendering has half a pixel offset.

Here are two (fixed) bugs which seem to be related to this one: T312 and T621. It may help to have a look at these.

Furthermore, T1119 (apparent shift between images and marching-cubes-generated surfaces) was NOT fixed since we assumed the marching-cubes algorithm to be responsible for this.

The problem is that WorldToIndex seems to have an offset of half a pixel.

Ivo, where is the center of a voxel in MITK? In the middle?

In this case, IsInside() and picking would be incorrect.

"New Patch" does not solve the problem.
Also, only adding half a pixel to WorldToIndex return value does only solve the malposition effect, but still leaves the IsInside false calculation problem.
Ivo, could you take a look at it again with me?

By then, I would commit the quick fix (at least correct display in SliderNavigationController), shown in "Patch".

Again: Requesting Core Modification...

Maybe it helps to add the Core guys to the Cc list?
Waiting for Core Change permission since a week now.

Ignore the previous patches; this one is the only working

Fixed bug with Ivo; Updated ChangeRequest;
-> Requesting Core Modification for Final patch.

Test will be updated wednesday.

(In reply to comment #15)

Fixed bug with Ivo; Updated ChangeRequest;
-> Requesting Core Modification for Final patch.

Test will be updated wednesday.

Nice. Two minor things:

  1. Why is the assert removed (http://bugs.mitk.org/attachment.cgi?id=342&action=diff#mitkGeometry3D.cpp_sec3) ? Return NULL for a mitk::Point3D does not look nice.
  2. Please mention the unit test change in the wiki page.

Oh, the assertion removal does not belong to the fix, sorry.
But it is stupid there, anyway. If an int is >= 0 and not 0-7, is is surely >=8.
Will exchange it with an itk::ExceptionMacro.

Updated Files to change: added mitkGeometry3DTest.cpp, and mentioned it in Test description.
Marco, did you mean that or a more detailed test description?

[SVN revision 19701]
FIX (#2401): Respect the half pixel shift of center in WorldToIndex and IndexToWorld transforms when it is a ImageGeometry.
Also replaced a useless assertion with an ExceptionMacro.

[SVN revision 19702]
FIX (#2401): Display correct units again (Pixel in Index). Display world coordinates again.

There has been quite a discussion about this in ITK bug tracker (http://www.itk.org/Bug/view.php?id=6558).

This even lead to a Wiki page on this topic (http://www.itk.org/Wiki/Proposals:Refactoring_Index_Point_Coordinate_System).

It seems Kitware is still working on this. Some (or all?) of the filed patches are already included in ITK 3.16, but the bug is still open.

[SVN revision 19796]
FIX (#2401): Severe execution speed increase by Ivo.

Obsolete because already committed (in a even faster version).

Closing this bug now. Create a new one if still problems occur. This one's comment history is long enough.

Reopened. Still problems inside mitkGeometry3D.
See T2885.

Also forgot to think of Geometry2D and it's childs, esp. PlaneGeometry.

[SVN revision 20007]
FIX (#2401): Adapt convenience method for WorldToIndex with Itk Index to corrected MITK coordinate system, and therefore rounding

[SVN revision 20225]
FIX (#2401): Use vnl has_nans() method, should be faster (inline)

Hopefully everything fixed now. Closing

Reopened for adding (simple) test.

[SVN revision 21198]
ADD (#2401): Simple test for coordinate system consistency

Reopened for adding (simple) test.