| neher | |
| Nov 17 2022, 9:42 AM |
| F2607698: growcut_test.mitk | |
| Nov 17 2022, 9:42 AM |
| F2607696: image.png | |
| Nov 17 2022, 9:42 AM |
| F2607694: image.png | |
| Nov 17 2022, 9:42 AM |
Ubuntu 22.04
MITK git commit hash: 51ababc09f671a5739406bce2810ea8d4290f13b
MITK branch name: develop
Added 3 labels to image, painted a bit in each and started growcut.
Image type:
Image (0x55b46e73cc00) Dimension: 3 Dimensions: 145 174 145 Channel: Unnamed [] PixelType: BytesPerElement: 130 ComponentType: short NumberOfComponents: 65 BitsPerComponent: 16
I looked into this and can verify the behavior.
I debugged and the crash happens inside ``
I tested other 3D tools, e.g. "Threshold" or "UL Threshold" (and even Otsu) and the following error message is shown:
Pixel type vector is not in (int)( unsigned int)( short)( unsigned short)( char)( unsigned char)(double)( float)
@floca The error seems to be inside AccessFixedTypeByItk_n, which produces a _accessByItkPixelTypeException (from inside Modules/Core/include/mitkImageAccessByItk.h
Inside mitkConfig.h there is the following definition:
#define MITK_ACCESSBYITK_PIXEL_TYPES_SEQ (int)( unsigned int)( short)( unsigned short)( char)( unsigned char)(double)( float)
The problem is that Peter used a vector image. and now the mask is a vector image too, this is why the accessors do complain. I guess we have to fix the function that generates the plain segmentation image based on the image as template.
And we should add this case to our checklist in order to test seg not also with 3D and 3D+t, but also vector images.
Yes that's what I found out too. I wanted to test something by changing the threshold tool to accept a vector image and work with AccessVectorPixelTypeByItk_n and itk::VectorImage<TPixel, VImageDimension> VectorImageType; but let's discuss how we want to prioritize this.
But that is an other task. We should seperate it. this task is for ensuring that segs don't get vector images.
The other (new) task is how to support vector/multi channel images (like RGB) with out AutoSeg tools if they only expect one image. That I would implement directly in the tool base class: Offer the possibility to select the channel/component that should be used and it will be extracted and passed on, so that the specific seg code (like thresholding) does not have to care about this. If we realize it in the Base(GIU)class it can be then also automatically covered in the UI. Like we do for 4D data, where some options only apeare if the input is 4D, but it is battery included for all tools that want/need it.