[cefe0c]: Merge branch 'bug-11130-crash-if-dicomTag-missing'

Merged commits:

2012-03-07 14:59:27 Markus Fangerau [15d965]
Checking the case when no valid images are found within a series

I've fixed the bug by checking if the volume has valid images before trying to load it. I've commited it in branch bug-11130-crash-if-dicomTag-missing.

There is a unit test. I need the core modification to push it.

[f5d8ce]: Merge branch 'bug-11130-MITK-Data-Conflict'

Merged commits:

2012-03-23 17:05:32 Thiago dos Santos [708183]
MITK-Data file was wrongly merged.

Patch for itkLandmarkBasedTransformInitializer.h

I've tested it on linux as well, and can confirm that it really works. I will look for an windows machine.

Hi Miklos,

[3abd4a]: Merge branch 'bug-9076-ImageCropper-outside-value'

Shifted bounding box

What is the status?

@Sasha: What is the status?

Clearly an IGT issue!

What is the status? Is someone going to fix it?

Do you have some secondary captures so I can reproduce the bug?

I do not have a solution for the bug. I only checked the dashboard and saw that the tests were passing, so I closed the bug.

All DICOM tests are working correctly now.
If the issue appears again, please reopen the bug.

@Markus: What is the status here?

Patch with Marco's changes

What is the status?

Whats the status here?
@Marco: did you post the patch to tiny xml?

In order to load 4D datasets, both "sort" and "check_4d" parameters must be enabled.

Sorting with Image Poistion priority instead of acquisition time.

Fix for the bug.

Fix for the bug.

According to David Clunie (http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/4568635e083a3fba/e2a8ceec23032601?lnk=gst&q=sort+slices), the best way to sort is NOT the one I mentioned before, but to "sort along a vector normal to the plane of the image (determined from Image Orientation (Patient)) by the value of Image Position (Patient) projected onto that vector".

This is because the option "all" shows all extensions that can be loaded with MITK. I agree that this is a bit confusing. Maybe we should change "all" to really show everything, and create another entry "known extensions" to show what "all"is currently showing.

[SVN revision 28011]
FIX (#6273): The entry "all" in the extensions menu is now showing all files, instead only the known extensions. A new entry "known extensions" was added.

Yes.

@Caspar: What's the status?

What is the status?

[SVN revision 26833]
FIX (#5739): Instead of using time stamps to identify images belonging to the same time step in 3D+t data, it is now assumed that all time steps have the same initial slice position.

The problem of moving this method to .cpp is that a different implementation of this method would be required for each different pixel type.
I think the better solution would be to have an interface class (DicomSeriesReader) and an implementation class (GDCMDicomSeriesReader).
However, this is also a bit tricky, as the implementation is not purely GDCM based.

Sorry, didn't see that it is a diffusion DICOM images problem.
It does work only for regular DICOM data.

It is actually supposed to work if the volumes have different series UIDs.
I've tested it here and it worked fine. Can you send me some images that are not working correctly?

What is the status?

There are no 4D Polygon model classes in VTK / ITK. A Solution would be: Store single 3D polygon models for each timestep.

[SVN revision 24574]
FIX (#4648): Instead of hard-setting the number dimensions to 4 in the itk image, it is checked if there are more then one time step. If there is only one, dimensions is set to 3.

Recognition and loading of 4D data is working. More specific problems regarding this matter should discussed in more specific bugs. I am closing this one.

[SVN revision 24215]
COMP (#4565): The solution for 4D volumes only works with GDCM>=2. It is now checked during compilation.

[SVN revision 24210]
FIX (#4565): Image sorting according to acquisition time and position for the identification of 4D Dicom volumes. After sorting, the images with equal acquisition time are grouped together and loaded as separate volume. Each volume is put as a separate time step in the mitk::Image.

Modifications to DicomSeriesReader in order to make it 4D compatible.

Modifications to DicomSeriesReader in order to make it 4D compatible.

[SVN revision 24111]
ENH (#4525): Modification of the MITK DICOM series reader to look the at the MITK_USE_GDCMIO variable and to select the appropriate itk IO class accordingly.

MITK loads the image correctly, if using GDCM 2.0, and having MITK_USE_GDCMIO variable enabled in CMake.

What is the status?

Works for me.

Could not test it because of T8905.

What is the status?

What is the status?

[SVN revision 22555]
FIX (#3722): Same solution used for the Dicom browser was brought to the DataNodeFactory. A common class for loading Dicom files was created.

[SVN revision 22384]
FIX (#3722): Used itk::DICOMImageIO2 to find out the pixel type before loading the whole image.

[SVN revision 22385]
ENH (#3722): Added a default caso in order to cover the unknown pixel warnings and to get rid of the compiler warning.

We should port this changes to mitkDataNodeFactory and adapt the DicomBrowser to use the load mechanism direct from there.

[SVN revision 22291]
FIX (#3698): Dependencies to wrong module (DicomIndex) modified to the correct module (DicomIndexer).

[SVN revision 22363]
FIX (#3698): Dependencie is really DicomIndex. DicomIndexer does not exist.

Clearly a core issue!

Chili found out that the image headers provided wrong information in the "Number of Frames" section of some series.

Apparently does ITK have more DICOM IO classes, than the GDCM-based one. Using the DICOMImageIO2, some of these images could be loaded correctly. However, some have wrong header information (image dimensions) and can not be loaded.

Some images could be opened after changing the ImageIO class. By others I think the headers are wrong in some series. For example, the images have different sizes within the same series.

[SVN revision 21987]
ENH (#3447): GDCMImageIO replaced by DICOMImageIO2.

Chili is also unable to load these images. It freezes.

Please look at the comments on bugs #3250 and #3146. There is not much I can do.

Modification in the DicomSeriesReader in order to allow progress callbacks.

Modification in the DicomBrowser in order to update the progress bar in every progress callback from DicomSeriesReader.

Modification in the DicomBrowser in order to update the progress bar in every progress callback from DicomSeriesReader.

Modification in the DicomSeriesReader in order to allow progress callbacks.

I added a patch that reverts all changes I made to the Image Cropper. Please apply it and try cropping your images.
It would be nice if you make the images you used available for tests. It may be a geometry problem.

Patch that reverts all my changes.

We have tested the cropping with and without the changes we made, and in both cases the same result was achieved.
In order to evaluate if the cropped region is correct, we used synthetic images, such as wall (/lpic/synthetic), where we could easily check if the cropping region was correct.
The selected regions were successfully cropped. However, after cropping, the selected image always moves to the center of the original image. This effect can explain what happened in Jochen's screenshots. After cropping, and having the cropped region moved to the center, the red marker lies outside the cropped region. In summary, the marker set by Jochen is given in world coordinates, which before cropping lies inside the image, and does not lie inside the cropped image because its origin is moved to another world coordinate, so the image lies in the center.
I don't know if this a geometry problem, or if there is a problem at all. The behavior of the cropping tools was never specified before, and I don't know who implemented it that way.

Patch that reverts all my changes.

Some errors were suppressed. The errors that are still there can be fixed by the author. Valgrind gives very specific information about the location of the errors and what it is all about.

There are no memory leaks. Valgrind is only pointing that there are operations with uninitialized variables.

Fixed in Commit: 25856. I used the wrong bug message in my history. Unfortunately it was commited as COMP.
The epsilons were added and are initialized with 0.0, in order to maintain the previous behavior.

No, it is not a duplicate.

(In reply to comment #9)

Probably the cleanest solution would be to check in another way if the current
(reference?) geometry is not yet set, and therefore the extents cannot be
computed properly. The check for an index coordinate extent of <= 2 seems to be
a bit arbitrary to me (could it not be that the extent in some rare cases
suddenly becomes greate than 3.0, e.g.? At least then rounding would also not
work...)

The extents in the first run of GenerateData are computed through the norm of the axis vectors in index coordinate (lines 403-406). There are many operation involved:

• Transformation of the vectors in world coordinates to index coordinates, which involves a few matrix transformations;
• Computation of the norm from the transformed vectors.

In order to solve this warning problem, one can check if the world geometry was already initialized with a reference geometry. If not, it means the the planes are not there yet, and the method should return.

[SVN revision 22210]
FIX (#3250): Checking if the worldGeometry2D was correctly initialized before continuing.

I've checked the mitkImageMapper2D.

I think this bug is very similar to T3205. Since MITK relies on ITK (more specifically on gdcm) in order to load DICOM images, there is not much I can do about it.

[SVN revision 27934]
ENH (#3205): Warning fixed.

[SVN revision 27924]
ENH (#3205): Warning fixed.

[SVN revision 27922]
ENH (#3205): Status shows now "DB Ready" instead of "Connected". Update and Stop buttons are set visible or invisible, depending if they are needed.

The extensions are shown depending on the configuration of the linux environment (gnome, kde, etc.)

[SVN revision 21134]
FIX (#3193): Deleted unnecessary QT filter separation characters (;;), which were generating the empty line in the extension list of the load dialog.

What is the status?