Additional information: http://bugs.mitk.org/show_bug.cgi?id=15457#c5

http://mitk.org/ChangeRequests/14807

From the discussion during the MITK meeting, I am not convinced that adding a property like "isVectorImage" is the right way to go.

Since the mitk::Image contains information about the pixel type of the underlying data, this should be used to determine the appropriate mapper (or "mapper configuration"). I see two possibilities without introducing yet another set of properties:

1. The current image mapper get the pixel type information from the mitk::Image and if it is "itk::Vector<T,int>" it switches to "vector mode"
2. We create a new image mapper for vector images, and check if the BaseData instance in CoreObjectFactory::CreateMapper is a mitk::Image with pixel type "itk::Vector<...>" and then instantiate the new mapper. This new mapper could then provide vector image specific data node properties, like selecting the active component.

As said in the meeting, this topic seems to need more discussions.

Automatic detection of vector images by pixel type is done of course and the properties are set accordingly in the mapper's SetDefaultProperties method.

Giving the user the ability to handle an image explictly as vector image is useful for multi-component images that are no itk::Vector images, e.g. if a user loads a color image and he wants to visualize a single component - he can simply do so by changing the two properties. I can dismiss this feature but having at least a property for the visible component is really important to be able to implement features like a slider where you can quickly investigate the vector components (which is commonly desired feature of internal and external MITK users).

Implementing a separate mapper is total overkill since adapting the image mapper is an easy task and needs only a very few lines of additional code (maybe even under ten).

Having both properties for vector images would be consistent with the concept of the "binary" property.

Actually all that was dicussed last week during the MITK meeting and it was commonly accepted with the remark to talk to the people having problems with their vector images - and they really like the current idea.

In a nutshell, it would be your idea (1) plus the ability to specify the visible component. Otherwise, a common vector image rendering would be quite useless.

New remote branch pushed: bug-14807-VectorImageRendering

I pushed a first working version were you can see how convenient, easy and transparent everything is. There is no overhead for non vector images. In case of vector images a vtkExtractImageComponents filter is attached in front of the vtkLevelWindowFilter. All Lookup table stuff and other render capabilities work as well this way.

The only thing that is really open to discussion (and was open at our last MITK meeting) is the capability to explicitly mark every image as vector image. When we drop that I would simply remove the "Vector Image" property and leave the "Visible Component" property as without it the complete sense of a vector image mapper is lost.

@ Jonas: The crashes are gone as well.

(In reply to Stefan Kislinskiy from comment #4)

Automatic detection of vector images by pixel type is done of course and the
properties are set accordingly in the mapper's SetDefaultProperties method.

Great. This wasn't clear from the bug description or change request.

Giving the user the ability to handle an image explictly as vector image is
useful for multi-component images that are no itk::Vector images, e.g. if a
user loads a color image and he wants to visualize a single component - he
can simply do so by changing the two properties. I can dismiss this feature
but having at least a property for the visible component is really important
to be able to implement features like a slider where you can quickly
investigate the vector components (which is commonly desired feature of
internal and external MITK users).

I agree that having a property to control the visible component/channel of an image is important and this has already been approved in the meeting.

I still cannot see the advantage of always adding a "isVector" property. Either the image is a vector image or not. In case of a color image, the mapper should also be aware of such pixel types (like itk::RGBPixel ?) and add the appropriate property for selecting the color channel.

If we had a "isVector" property what would happen if the user (or programmer) sets it to true for a scalar image?

Implementing a separate mapper is total overkill since adapting the image
mapper is an easy task and needs only a very few lines of additional code
(maybe even under ten).

I didn't talk about literally copying the whole image mapper code - there would certainly be ways to share common code. Adapting the image mapper is of course fine too.

Having both properties for vector images would be consistent with the
concept of the "binary" property.

The "binary" property always was a work-around. In the vector or rgb case, we can clearly infer the pixel type and act accordingly.

Actually all that was dicussed last week during the MITK meeting and it was
commonly accepted with the remark to talk to the people having problems with
their vector images - and they really like the current idea.

Yes, it was discussed. And we said that the "isVector" property needs also input from Jan who is familiar with the PixelType stuff.

In a nutshell, it would be your idea (1) plus the ability to specify the
visible component. Otherwise, a common vector image rendering would be quite
useless.

Without the "isVector" property - yes. I just think we should try to solve these problems without adding to many new properties - if we can.

(In reply to Stefan Kislinskiy from comment #6)

I pushed a first working version were you can see how convenient, easy and
transparent everything is. There is no overhead for non vector images. In
case of vector images a vtkExtractImageComponents filter is attached in
front of the vtkLevelWindowFilter. All Lookup table stuff and other render
capabilities work as well this way.

We just simultaneously added our comments ;-)

The only thing that is really open to discussion (and was open at our last
MITK meeting) is the capability to explicitly mark every image as vector
image. When we drop that I would simply remove the "Vector Image" property
and leave the "Visible Component" property as without it the complete sense
of a vector image mapper is lost.

Right. Core+ if we can do without the "Vector Image" property.

(In reply to Sascha Zelzer from comment #8)

I still cannot see the advantage of always adding a "isVector" property.
Either the image is a vector image or not. In case of a color image, the
mapper should also be aware of such pixel types (like itk::RGBPixel ?) and
add the appropriate property for selecting the color channel.

The advantage is that we are ot artificially constrained to vector and RGB images. There are more images with multiple components and having the OPTION of invastigating single components won't hurt in my opinion. Also, this means less code for more possibilities as we do not need case handling.

If we had a "isVector" property what would happen if the user (or
programmer) sets it to true for a scalar image?

In the current version nothing will change except for the execution of the vtkExtractImageComponents filter. We should have a look inside this filter if it is a "no-op" in that case or extend the condition for using this filter (vector image AND more than a single component).

The "binary" property always was a work-around. In the vector or rgb case,
we can clearly infer the pixel type and act accordingly.

I agree, the binary property sucks and AFAIK it will be dismissed in the near future when we have Sebastians segmentation enhancements.

Yes, it was discussed. And we said that the "isVector" property needs also
input from Jan who is familiar with the PixelType stuff.

I talked to him and we figured out a second bug in MakePixelType or similar. itk::FlexibleVectors are not recognized as "vector" images in certain cases. This will be fixed separately.

Without the "isVector" property - yes. I just think we should try to solve
these problems without adding to many new properties - if we can.

See the explanation of the advantages above in this post. I still vote for it. :-)

(In reply to Stefan Kislinskiy from comment #10)

(In reply to Sascha Zelzer from comment #8)

I still cannot see the advantage of always adding a "isVector" property.
Either the image is a vector image or not. In case of a color image, the
mapper should also be aware of such pixel types (like itk::RGBPixel ?) and
add the appropriate property for selecting the color channel.

The advantage is that we are ot artificially constrained to vector and RGB
images. There are more images with multiple components and having the OPTION
of invastigating single components won't hurt in my opinion. Also, this
means less code for more possibilities as we do not need case handling.

I can see your point of not having to deal with all the "vector" cases explicitly. If the VTK filter which is extracting individual components can handle all cases already, that would be nice. But I still fail to see how that relates to a "isVector" property :-)

If we can check if the pixel type is made up of multiple components (I believe we can), we could generically handle it in the image mapper (assuming the VTK extractor handles it) without testing explicitly for "vector" or "rgb" pixel types.

So I reformulate my original statement: Either the image pixel type is made up of multiple components (aka "vector image") or it isn't (aka "scalar image" or something more exotic, like a tensor pixel type).

Why would there be a need for externally setting that information via a "isVector" property, especially when there can be a mismatch?

Argh, we wrote in parallel again... Tada:

(In reply to Stefan Kislinskiy from comment #10)

If we had a "isVector" property what would happen if the user (or
programmer) sets it to true for a scalar image?

In the current version nothing will change except for the execution of the
vtkExtractImageComponents filter. We should have a look inside this filter
if it is a "no-op" in that case or extend the condition for using this
filter (vector image AND more than a single component).

I just had a look into this and I'll extend the condition as the filter still makes an unnecessary copy.

Furthermore I try to get rid of the "Vector Image" property. It should be possible to extend that condition in a way that we don't need it anymore.

Everyone should be happy now. Yay! :-)

[192abc]: Merge branch 'bug-14807-VectorImageRendering'

Merged commits:

2013-09-04 18:03:27 Stefan Kislinskiy [988809]
There is only one property left called "Image.Displayed Component".

It is automatically added for images with two components, images with more than four components, and vector images with more than one component.
You have to add this property manually to display single components of other image types.

2013-09-04 16:22:51 Stefan Kislinskiy [f864c1]
Added vtkImageExtractComponent filter before vtkLevelWindowFilter in case of vector image rendering.

2013-09-04 15:07:26 Stefan Kislinskiy [3cfcab]
"Image.Vector Image" property is automatically set according to image type.

2013-09-04 14:52:59 Stefan Kislinskiy [08e9dd]
Added "Image.Vector Image" and "Image.Vector Image.Visible Component" properties for non-binary images.

Tensor images and QBall images didn't work anymore with this feature. We fixed it today and want to merge.

New remote branch pushed: bug-14807-DiffusionFix

[10aff6]: Merge branch 'bug-14807-DiffusionFix'

Merged commits:

2013-09-11 16:33:12 Stefan Kislinskiy [1a9463]
Diffusion images are rendered as color images again.

[b9266f]: Merge branch 'bug-14807-DiffusionFix2'

Merged commits:

2013-09-11 16:42:16 Stefan Kislinskiy [2d12d7]
Made two certain variables as local as possible.