Page MenuHomePhabricator

Unsupported pixel types
Open, NormalPublic

Assigned To
Authored By
Sep 9 2022, 2:57 PM
Referenced Files
Restricted File
Sep 9 2022, 2:57 PM
Restricted File
Sep 9 2022, 2:57 PM


Hi, there are some pixel types that are not supported by MITK. This is a bit frustrating because SImpleITK in python and thus probably ITK support them. Is there a specific reason these are not supported?
One example is int64, see this file:


Is there a good reason for some pixel types not being supported? I don't see
int64, uint32, uint64, float16 in the list.

Edit: 2022-07-11 snapshot on Ubuntu 18.04

Event Timeline

isensee updated the task description. (Show Details)
kislinsk triaged this task as Normal priority.Sep 10 2022, 5:07 PM
kislinsk added a subscriber: kislinsk.

We cannot see the files. Their view policy is too restricted.

Pixel types are configurable with CMake when building MITK. By default, regarding integral types, only 8, 16, and 32 bits are enabled both signed and unsigned (which makes me wonder why you listed uint32 and if there is another issue). Regarding floating point pixel types, 32 and 64 bits are enabled by default. And then there are a few vector pixel types. We do not go full force with pixel types as they will remarkably increase compile time and binary size due to all the templates that have to compiled for all pixel types and the ones enabled do the job in nearly all cases that we saw in the past 10 years or so.

I sent the file to you via slack.
Not supporting some pixel types can be very frustrating for users, so it might make sense to extend this list (I would certainly appreciate it and a 200MB standalone is really not large by 2022 standards so there is some headroom imo ;-) ). This is not the first time I ran into this issue :-/

I wouldn't care for the extra size (if it stays reasonable), if users need the pixel type.

The major show stopper could be that itk currently does not support 64 bit integer on all plattforms ( *sigh*

We would need to check (and patch mitkPixelTraits, as the mentioned types are not defined there.

Stefan is right that, from the medical perspective, there is no need for these pixel types. And urgently needed not they are. We can easily convert all the files with strange pixel types to files with 'normal' ones. The issue here is simply from a usability/user experience perspective. It is uncommon to me (and probably other as well) to load an image and then get told the pixel type is not supported