i think this line is missing in GetVtkImageData:

volume->GetVtkImageData()->SetOrigin(GetSlicedGeometry(t)->GetOrigin()[0], GetSlicedGeometry(t)->GetOrigin()[1],GetSlicedGeometry(t)->GetOrigin()[2]);

Related to T4734. Approriate test code should be added to mitkImageTest.cpp, similar to that added when fixing T4734.

i think this line is missing in GetVtkImageData:

volume->GetVtkImageData()->SetOrigin(GetSlicedGeometry(t)->GetOrigin()[0], GetSlicedGeometry(t)->GetOrigin()[1],GetSlicedGeometry(t)->GetOrigin()[2]);

no that is not T4734:

T4734: Origin in Initialize is wrong (this bug was found by me)
this Bug: Origin in GetVtkImage is wrong

(In reply to comment #4)

no that is not T4734:

T4734: Origin in Initialize is wrong (this bug was found by me)
this Bug: Origin in GetVtkImage is wrong

Yes, but both bugs are somehow related and therefore it seems to be reasonable to test the issue in the same unit test.

sorry i missinterpreted the previous comment...

May potentially affect mitk::SurfaceToImageFilter when used on images with non-zero origin (of course, this would be a bug of mitk::SurfaceToImageFilter).

(In reply to comment #7)

May potentially affect mitk::SurfaceToImageFilter when used on images with
non-zero origin (of course, this would be a bug of mitk::SurfaceToImageFilter).

Sorry, I meant mitk::ImageToSurfaceFilter (and NOT mitk::SurfaceToImageFilter).

Is a Bug in mitkImageDataItem.
Thx for reporting.
Will add unit test to mitkImageTest.

Patch

Patch not a solution (only does the same, wrong thing that is done as in 2D). Correct origin needs still to be set.

is there no further development on this bug?

This bug is 2 years old. Can we close this?

is it solved in last release?

Ok this bug has a core modification flag major severity and high priority. But nothing has been done for two years. I will mark it as incomplete.

is this bug not important for MITK? I am not familar with detailed implementation in MITK and needed changes but this behaviour is very strange and is truly inintuitive....

Only an opinion from an extternal MITK user...

Sorry, I don't think this is incomplete. As far as I understand all the comments the next step is to write/enhance our tests to clearly show the wrong behaviour:

1. Create a mitk::Image with a non-zero origin
2. Convert to VTK and back
3. Compare

See commit aa8387b8 for an example.

This could be done by anyone at bug squashing party.

@Gerald: since we're preparing the release I'm not sure when this will happen. Could you extend the test and show the misbehaviour? That would make it easier to fix.

sorry, the project where i used MITK is currently finished since over 1 year, currently i am not using MITK any more (but i maybe will if i need a good 3D GUI again) so I am currently very busy with other stuff.

But the test should be very simple, something like (pseudocode):

mitk::Image::Pointer oMITKImage;
//initialize stuff
OriginType oOrigin;
oOrigin[0] = 50;
oOrigin[1] = 50;
oOrigin[2] = 50;
oMITKImage->SetOrigin( oOrigin )

if( oMITKImage->GetVtkImageData()->GetOrigin()[0] != oOrigin[0] )
{
return FAILURE;
}

sorry for my bad syntax but its one year ago i porgrammed ITK/VTK/MITK the last time.... In my case i used a VTK image filter onto a MITK image and converted it back, then the origin was wrong.

Updating target_milestone

This bug could not be fixed within the 2013-06 release and has medium severity. Setting target milestone to unspecified.

This bug is currently worked on in the SCRUM program of Bugsquashing. Time to solve it.

New remote branch pushed: bug-5050-FixWrongOriginFromMitkImage_GetVtkImageData

Added a test into MITK Image. This problem obviously persists. Test is pushed to branch and currently fails.

in mitkImageDataItem where the vtkImageData is constructed, the origin was set wrong. In the branch, we set the origin to the data in the mitkImage. The new tests are Passing.

(In reply to Ivo Wolf from comment #8)

(In reply to comment #7)

May potentially affect mitk::SurfaceToImageFilter when used on images with
non-zero origin (of course, this would be a bug of mitk::SurfaceToImageFilter).

Sorry, I meant mitk::ImageToSurfaceFilter (and NOT
mitk::SurfaceToImageFilter).

line 51 of mitkImageToSurfaceFilter

indexCoordinatesImageFilter->SetOutputOrigin(0.0,0.0,0.0);

must be removed when this bug is fixed, because by default the filter takes the origin of the vtkImage.
But there is currently no test to confirm this.

What is the status of this bug? This bug was not fixed within in the release 2013.12 but should be fixed within the next release

I merged the branch above into an integration branch based on the current master to check the status of this bug.

It is NOT fixed. While the image tests pass, opening an image with an origin other than [0, 0, 0] results in wrong image rendering, i.e., the image is rendered with an offset onto the image planes.

Other than the ImageToSurfaceFilter, also mitkExtractSliceFilter (which is needed for the imageVtkMapper2D) is assuming the origin of the vtkImage to be 0/0/0.

The fix in bug-5050-FixWrongOriginFromMitkImage_GetVtkImageData can only be merged if all affected classes are found and accordingly fixed. I would suspect most of the classes which are calling mitk::Image::GetVtkImageData to be affected.

This will probably not include into the upcoming release. The changes may have to many side effects.

Is there any update regarding the status of this bug?

User eisenman has pushed new remote branch:

bug-5050-FixWrongOriginFromMitkImage_GetVtkImageData-Integration-2015-07

Together with Guido, we first made a new integration branch based on the current master. As Stefan already mentioned, tests comparing the origins are passing, but the image rendering is still wrong.

We had a deeper look at mitk::ExtractSliceFilter and mitk::ImageVtkMapper2D. We varied parameters influencing the origin in order to get an understanding of geometries and their behavior.

We figured out that there are two conversion of an origin in the mitk::ExtractSliceFilter::GenerateData() method:

• Origin of plane geometry to VTK origin
• Reslice result back to mitk::Image

Varying these origins (in different combinations) directly influences the rendering result. So maybe the mitk::ExtractSliceFilter is worth for further investigations since we did not find the 'correct' combination yet ;)

In mitk::ExtractSliceFilter::GenerateData() method, the line:

m_Reslicer->SetOutputOrigin( 0.0, 0.0, 0.0 );

has to be removed maybe. If the output origin is not set manually, the default output origin is the input origin permuted through the ResliceAxes.

User eisenman has pushed new remote branch:

bug-5050-FixWrongOriginFromMitkImage_GetVtkImageData-Integration-2015-07

Matthias and I were once again looking for stages responsible for incorrect image rendering when the vtkImage origin equals the mitkImage origin.

1. In mitkImageDataItem::ConstructVtkImageData() we first changed (as suggested before):

vtkImage origin is set euqal to mitkImage origin
inData->SetOrigin(origin[0], origin[1], origin[2])
m_VtkImageData Holds the vtkImageData internally

2. mitkImageDataItem::GetVtkImageAccessor() Returns an accessor to the internally stored m_VtkImageData

3. mitkImage::GetVtkImageData() Returns Pointer to vtkImageData by calling GetVtkImageAccesor of internally handled volume

4. mitkExtractSliceFilter::GenerateData() Gets VtkImageData from input mitk::Image Uses it for as input for UnitSpacingImageFilter

5. mitkExtractSliceFilter::GenerateData() Here the output origin of m_Reslicer (vtkImageReslice) is explicit set to (0,0,0) m_Reslicer->SetOutputOrigin(0.0, 0.0, 0.0)

6. mitkExtractSliceFilter::GenerateData() The reslicedImage is converted back to mitkImage named resultImage /*================ #BEGIN Get the slice from vtkImageReslice and convert it to mit::Image================*/ mitk::Image::Pointer resultImage = this->GetOutput();

7. mitkExtracSliceFilter:GenerateData()
   • unitSpacingImageFilter may do some unwanted stuff? Doesnt seem to be so
   • itk2vtk(origin, originInVtk) could also be harmful? Doesnt seem to be so, only copies values to a double[3] array
   • Origin shift is performed (Maybe only pixel-center shift?!): origin += right * ( m_OutPutSpacing[0] * 0.5 ); origin += bottom * ( m_OutPutSpacing[1] * 0.5 )
     
     m_Reslider->SetOutputOrigin(0, 0, 0) could be wrong or hack?! --> Does not change anything, default origin in m_Reslicer is derived from input (ref. Documentation)

User schmidgu has pushed new remote branch:

bug-5050-FixWrongOriginFromMitkImage_GetVtkImageData-Integration-2015-09

Please desribe what you have done. You can use the following template and copy the text as comment here.

http://moinmoin.mitk.org/ChangeRequests/5050

Summary of problem description
Origin of vtkImage data is always {0,0,0}

Actual behavior
Origin of vtkImage data is always {0,0,0} when using GetVtkImageData() from mitkImage. Currently setting vtkImage origin equal to mitkImage origin results in wrong rendering behavior.

Expected behavior
Origin should be the one of the Vtk image.

Cause of the bug
Origin is hard coded to {0,0,0}. Due to the complexness of this issue, the current behavior is defined as vtkImage origin always being {0,0,0}.

Proposed solution
Use origin of PicDescriptor when constructing Vtk image in mitkImageDataItem.

Affected classes
mitkImageDataItem mitkImageTest

How will the bugfix get tested?
Testing for vtkImage origin being {0,0,0} in mitkImageTest

Already merged to master branch.