Hi, thank you for filing this bug. Is it possible to provide an example image as attachment?

please open the link for the data

Thank you, we'll have a look at the bug at our weekly bug squashing party tomorrow.

First findings: Seems to be a loader problem, as both parameters inData and outData reference empty vtkImageDatas. Additionally lots of warnings are printed during opening the image regarding RLE-related issues + a message from the DicomSeriesReaderSrv like: "reader: unsupported".

This is a (complex) loader problem. In a nutshell: we do not currently support 2D+t RGB US images.

Note that this is *not* a RGBPixel<float> but a RGBPixel<unsigned short> image.

The ultimate crash occurs since the vtkImageData header seems to be partially uninitilailzed (dimensions 0 for example).

Eveen if commented out, the image is wrongly loaded as 3D image with t mapped to the third spatial dimension.

Since it is very time consuming to implement 2D+t RGB US image support, this bug/feature request is delayed after next release.

However, we are always happy for contributions.

Hi Stefan,

Thanks for your effort. But...

1. I don't think this bug simply caused by the reason "MITK doesn't support 2D+t RGB US image". Please refer to the attachment, i attached a image with name USRGBUsignedCharData which can be loaded without any problem using itk:RGBPixel<unsigned char> as pixel type. So I still believe this bug caused by limited feature support of itk:RGBPixel<float> rendering.

2. "MITK doesn't support 2D+t RGB US image" is partially right cause the t dimension mapped to the third spatial dimension. However this is not big dual for me. I only need to display slices one by one no matter the third dimension is T or Z coordinate.

3. If load the USRGBFloatData image into dicom reader software(am using Slicer), you can find the maximum value of each pixel is larger than 255(the range of unsigned char type RGB should be (0-255,0-255,0-255),right? ).PS: This kind of US is Doppler image from new version of Philips ie33 machine. So i think this bug will frequently occur in other user's case.

So in my case i just need to display the USRGBFloatData I uploaded in attachment in workbench no matter the third dimension having right or wrong mapping.

Thanks for your effort again!

Best，
Adrian

Unfortunately there is more to do to integrate these image types. I. e., by using the Workbench it even crashes with the unsigned char version of the image. If you are using MITK as an external toolkit you might circumvent this crash but then it is still partially supported "by accident" as RGB<unsigned char> is THE standard RGB format and just supported through other image types.

The (our) DICOM loaders have problems with your image types (even third-party libraries like GDCM or DCMTK) and there is no code path yet for this image type.

Please note that this bug was not declined, it was just delayed since we are currently at the end of a new release phase and there is only time left for a very few critical bugs with higher priority yet.

Also note that new image types must be supported the right way and not just in a way that would fit your specific need. This also includes the DICOM handling through File->Open as well as through the DICOM plugin in.

And since the readers print that this is not yet a supported format, we classify this bug as feature request which must be solved to circumvent other bugs like the crash.

If you are in a hurry, you're kindly invited to contribute to MITK, i. e. via github, but the contribution must be somewhat complete including extending the DICOMSeriesReader. It this is not an option for you, you can still fork MITK on github and implement your specific need while syncing with MITK over the time until we fixed it "completely". But this will definitely take some time, sorry.

Hi Stefan,

I will try to figure it out for the current need. Also I’m looking forward to the feature implementation.

Thanks!

Best,

Adrian

Dear,

It seems the bug is not solved till now.

Please do not change the severity of feature requests to other values than "feature request".

Until we don't have a PhD student who is in need of this image type too, I'm afraid we currently don't have the capacity to implement this feature short-term, sorry.

I add a few colleagues dedicated to US and DICOM to the Cc. They should be able to assess this feature request better.

Hello all,
I am a bit novice in medical image format, i'm working with other industry devices which produce 2D images (TEM, AFM, SEM).
So, I need the 2D tiff support and will do my best to provide a fix here.

Stefan, you talk about "US RGB 2D+t" images, could you be more precise about the format?

regards,