DICOM also supports CT/MR images from animals (there is an tag for it) so if i want to develop a CT for a blue whale then we are in meters^^
no, sorry for that small joke. It is not an urgend issue but in my opinion it should be quite easy to implement the crosshair size in reference to the whole extent of the scene. Its true that MITK is focused on medical terms but the basic core functionality like the multiwidget should work for all kind of data. If i buy a kinect and use it for image processing purposes instead of gaming it is also a lame excuse that no support exist... So please let MITK not beeing so closed-minded like Micros*...

Also another bug:

i also have an same problem on an RGB image:

Mail from Karthik Krishnan (from kitware) on 16.2.2011

i dont't think that vtk solved that problem, a long time ago they told me that vtk dos not define/allow polygons of that degenerated type (i also found it in the VTK doku that VTK only support "valid" polygons which always have a volume, no spikes, no crossing lines etc). They told me that i can pay them if i need this behaviour but this is nothing i want:

2D polygons in 3D space

The sinlge polygon of the four which cannot be cutted

I "think" I debugged it to the EarCutTriangulation () of vtkPolygon in line 1277 success = this->EarCutTriangulation(); (returns false on such peaky polys) but i am not 100% sure. My triangulation vodoo is not quite good so i cannot exactly say where the error is ... But i already made a vtk bug report 0011504 see http://public.kitware.com/Bug/view.php?id=11504. But the response of the vtk community is quite low^^^

Please rename it to .vtk, i am not allowed to upload .vtk files so i renamed it to .vtk.txt

Sorry, but there IS a bug in MITK:

i figured out in which case the cutter does not work, and it is a bug (but not in MITK, i think it is a bug of VTK):

The sinlge polygon of the four which cannot be cutted

The "Paint" module is also very slow, maybe you could make some improvements?

Now the color of binary images is different between 2d and 3d paintings:

Here the absolute difference between two images is calculated and visualized, again opacity=1

then i do not really understand why this happens in my case:

The difference image with a second image in the background

Here the difference image is at top layer with opacity = 1 and a background image is set to visible. Nothing should change since opacity = 1

Both images visulaized, for sure opacity of both is 1

Second example where only one image is displayed

Only image which greater layer visualized

Both images visulaized, for sure opacity of both is 1

Only image which greater layer visualized

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....

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.

is there no further development on this bug?

is it solved in last release?

sorry i missinterpreted the previous comment...

i think this line is missing in GetVtkImageData:

no that is not T4734:

i think this line is missing in GetVtkImageData:

i would add a new property, maybe levelwindow.show or something like that. Then it is also possible to add more properties in future like levelwindow.orientation, levelwindow.viewmode, levelwindow.histogrammode etc.

There should be a boolean property for that level window appeareance, maybe it can be useful to display helper objects in level window

i know what you mean but when you set the levelwindow.view to false at default (for sure only for helper objects) it should prevent forgetting it :-)

thanks, i will test it next weeks

(In reply to comment #8)

Instanciation of a pointsetinteractor, that is only allowed to add 0 (!) points
does't make sense. Thus I define the min. number of points to be 1. Adding a
check in constructor of PointSetInteractor with a warning in case a 0 is
defined for m_N.

(In reply to comment #14)

I will add a new pattern for the interaction with loaded points without adding
or deleting points called "onlymovepointsetinteractor" to statemachine.xml.
@Gerald: use this for the 0 point interaction

You must take a point set which already has one point in it. Then you must initialte the PointSetInteractor with 1: mitk::PointSetInteractor::New("pointsetinteractor", m_poPointNode,1);

(In reply to comment #3)

PointSetInteractor is not meant to be used with PointSets already containing
points.

My already programmed algorithms (before i used MITK) returns their results in vtkPolyDatas. And as i know the only data object which takes vtkPolyData as input is the surface.

I have a question to the last part of your comment:

yes, that works.

The red transversal line of the cut planes is not centered in the pixels

This is missing to compute the correct origin: