(In reply to comment #1)

I know nothing that would be against that idea, just conversion into
appropriate ITK images gets a little harder for 2D images.

(In reply to comment #6)
see also T8509

Could not find anything yet. Since a whole plane is missing, it seems like the geometry for that plane is broken. We assume it might be connected with Marcos Clone function of the geometries, since the bug appeared some time after it. Things to check:

Apparently only occurs under windows

We found the error. The class SliceGeometry3D has a member m_DirectionVector which was not properly initialzied in the constructor and copy constructor.

[2ef50b]: Merge branch 'bug-8925-4DImages'

only occurs on WINDOWS and in RELEASE mode

There is a need for a IndexToWorld transform, that accepts mitk::index3d as input

see also T8350

We decided to declare the following behaviour as desired behaviour:

Possible connections:
T6507
T8092

After exceeding the upper bound of the window while changing the level-window with pressed mouse and move the interaction isn't working.

What's the status, alfred?

"GetPixel" method is already available.

Planes rotated and translated, so that they do not have a common intersection point inside the image anymore.

We discussed this issue in the MITK meeting. The current behaviour is the most sensible solution! When you happen to translate and rotate the planes, so their intersection is outside, the current behavior would be the most expected.

• another feature request: indicate direction of planes/axisvector with an arrow at one end

[375035]: Merge branch 'bug-8509-NewCast'

[38d851]: Merge branch 'bug-8509-CastChangesGeometry'

[444013]: Merge branch 'bug-8509-NewCast2'

We fixed it now partly.

I will create a test for it and then push it

Test implemented for Casting 3D ITK to MITK...

possible connection
T4583

I was wrong! Can be solved without T8477!

Changed the code as described. But the warning is coming to the output a few times, when loading an rotated image, which should actually be allright.

Handling of Rotation in Image Geometries is not functionable.. need to fix that first: See T8477

I am planning to implement the following behaviour:

Work in Progress: Currently we are changing the geometry class in a branch on
my computer.

CastToItk apparently does not alter m_Direction, so no rotation considered here

(Need to check if that still applies if a Translation was applied to the given
Transformationmatrix)

Only 1 MB attachment allowed, so i put the Image to T:\Temp\Extracted2DMitralValve.nrrd

After some discussion with Jan und Caspar, we found out, that it IS possible, to determine the Scaling and Rotation Matrix out of a composed TransformMatrix.
So, when the user sets the IndexToWorld Transformation Matrix directly, we can read out Spacing and Rotation Matrix out of that.
That means, for the new Geometry we could offer a SetTransformationMatrix Method, which sets up a nice and clean geometry!
(Need to check if that still applies if a Translation was applied to the given Transformationmatrix)

We began to change some stuff in the Geometry3D class.
Need to discuss a couple of things in the MITK meeting

I am not working on that one atm.
But really needs to be done, since Histogram is a must-have.

The problem is most probably inside the widget!
In QmitImageStatisticsView.cpp line 642
"m_Controls->m_HistogramWidget->UpdateItemModelFromHistogram();"

the messed up logo might be somehow connected with T8188

Problem does NOT appear under Linux

new image

tested on my and alex's computer in the current MITK_extApp. Does not crash there. Assigning back to Sven.

new image

Tested with the attached image and several other images on current master clone. Works for me!

Duplicate

e.g. when i click "save image" onto an image in the datamanager, in the dialog i can choose formats which are totally unsuitable, like:
pvtu
lsm
dwi / hdwi (only works with diffusion images)
pf
hqbi / qbi (qball)

apparently it is saved as multiple indentical 4D images... same problem goes for ".nii" format

The code is basically finished.
But we still have to implement a test for this issue.
We plan to push a 2D_rgb, 3D and 4D image into the test-data repository and use these for saving tests for all available image file formats.

Work in progress:

Need to check other constraints as well. e.g. is Pixeltype possible? What about dimension? time? geometry?

The bug was discussed in the MITK meeting. The result:

• No XML file! Better put in somewhere in the code.
• Maybe use an abstract FileWriterInterface (???)

GIPL (Guys Image Processing Lab) is a image file format, developed at the Guy's Hospital (in London), which is related to the King's College London School of Medicine and Dentistry.

Since the property behavior is going to be changed soon. We should reconsider this bug later, after the change.

We give it a try

Found out a dependent bug: 7998
Have to solve that first

An email has been sent to the mitk-users list:

(In reply to comment #4)

[bfac38]: Merge branch 'bug-7619-replace-world-to-index-calls'

Merged commits:

2011-04-06 17:00:34 Andreas Fetzer [7494fd]
In the classes

• Geometry3D
• PlaneGeometry3D
• AbstractTransformGeometry

the functions "indexToWorld" and "worldToIndex" had an unused parameter. We
declared them as deprecated and created a new version of these functions
without the unused parameter.
Deprecated function calls "indexToWorld" and "worldToIndex" with the respective
non-deprecated function call.

The problem is located in the mitk::ExtractImageFilter.
The filter takes a 3D image as input and produces a 2D image output.
The geometry of the 2D output image is wrong.

Current Status:

if you revert the changes in mitkPaintbrushTool.cpp and adapt line 311 like this:

Since your latest changes from 2011-02-01 the Paint Tool Feedback Contour does not work properly. I try to find out why ..

[SVN revision 29801]
FIX (#6552): Reverted some of the changes to make it work properly again.

Is this still a problem?

Ok, somehow it works now..
Maybe it was caused by a change in the geometries which i reverted recently

[9d626c]: Merge branch 'bug-6397-PhilipsDicom'

Spacing is not quite right. Apparently milimeters are used, where centimeters
should have been used

Works fine now

In the Philips3D Dicom files, the spacing values are usually measured in centimeters.

To support Philips3D DCM files 3

I found a small bug, causing different behaviour in release and debug mode. Fixed it and created Patch Number 3

[SVN revision 28684]
FIX (#6397): Philips3D Ultrasound DCM files are now supported.

To support Philips3D DCM files 3

yes, still works with windows. The UCHAR typedef came from a windows file WinDef.h, so it is better how u changed it.

a little bit more information about the tags:

To support Philips3D DCM files 2

To support Philips3D DCM files

(In reply to comment #4)

I still need to fix: When u open a Philips3D DCM file, do not try to open all
other DCM files in the same directory

Solution looks good for me. You could do the next author a favor and split up
the long if-else block in mitkDicomSeriesReader.txx into multiple methods.

To support Philips3D DCM files 2

Philips3D US DCM files can now be read with the patch.

An example file can be found under

I have to handle 4D ultrasound images. They come from a Philips Ultrasound station. These stations usually generate files in a philips-proprietary format, that can be opened and analysed in Philips QLab Software.

To support Philips3D DCM files

I wrote to the GDCM Mailing list about that problem and wait for response.

[SVN revision 28266]
FIX (#6332): Saving files in different formats works under Linux again!

Tested On Windows!
Works fine! :)

Bug cannot be reproduced with the given data.
Seems to be solved.

Was diskussed in the MITK meeting: