Today in the MITK meeting we discussed whether MITK should generally support 3D(+t) images only. When loading a 2D(+t) image, it would be converted to a corresponding 3D(+t) image.
+ Simplify coding of filters
+ E.g. the segmentation bundle already require 3D(+t) images
+ MITK is already able to save a (stack of) 2D image file(s) based on a 3D image
The question is whether there is a major problem with this idea and what is the impact on our code?
I know nothing that would be against that idea, just conversion into appropriate ITK images gets a little harder for 2D images. The backdraw of storing "real" 2D images is that e.g. 2D ITK images how no idea of a 3D space, so both their origin and orientation is 2D and not 3D, which makes it rather hard to e.g. represent a CT slice in such an object (which IS oriented in space).
Has anybody built a pro-con table yet? Would be helpful to decide.
(In reply to comment #0)
+ Simplify coding of filters
+ E.g. the segmentation bundle already require 3D(+t) images
+ MITK is already able to save a (stack of) 2D image file(s) based on a 3D
image
Just from this list and not taking part in the discussion I could not derive a good reason to drop the concept of 2d+t. So I also vote for a pro/con table.
We (or at least I) have a lot of problems with converting images from 2D to 3D and from 3D to 2D, because most parts in MBI are not consistent. If I knew that all images in MITK are 3D (or 3D+t) my work would be a lot easier.
Some examples:
The segmentation bundle does not support 2D images. Some old ToF images, however, are stored as 2D images. Therefore, I have to convert those images to 3D. Some other ToF algorithms are implemented for 2D images, and as a consequence I have to convert my segmented images back to 2D.
A problem which kept me busy today:
The mitkImageWriter seems not to support saving of 2D images in all formats. I tried to save a 2D image in .png which did not work properly. I figured out that saving a 3D image as .png works well. I think most of our functions and algorithms are tested and implemented for the 3D case only.
I would be really glad if I could implement everything just for 3D and don't worry about the 2D case.
Most of the things Thomas reported are bugs I think. But fixing them without having a clear definition how things should work it probably doesn't make sense to fix them.
(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 MITK currently 2D and 3D images have both 3x3 Matrixes for the geometry. So it would be no problem here.
Yet, as Daniel said, 2D ITK images and respectivly most file formats we support (nrrd, pic, ..) only support 2x2 Matrixes for 2D images. This leads to known problems: e.g. MITK supports 3D rotation of 2D images, but when you save such a 2D image (for which we use ITK), the rotation is lost.
If we convert 2D automatically to 3D and ALSO store it as 3D (with just one plane), we could also save this rotation information!
MY CONCLUSION: If we automatically convert 2D images to 3D when loading them, we should also store them in 3D by standard! We could also provide an extra option for saving them as 2D, BUT in that case we cannot support rotation.