I decided at the beginning of ImageJ2 not to support packed RGB/ARGB, in favor of treating channel as a proper dimension. But there has been a lot of pushback over this limitation over the years, and the fact is that ImgLib2 does have the
ARGBType, so I think now we should support it.
I would rather not. It would complicate matters. It is very convenient if callers can assume they’ll always get channel as a dimension (and in the case of interleaved RGBRGBRGB… values, channel will simply be the first dimension before X and Y). We did not want callers to need to special-case handling of
ARGBType, which is a very weird type breaking otherwise consistent typing rules (unlike every other bit depth, it does not implement
If SCIFIO returned images using
ARGBType, what about other orderings? What about
RGBAType? I’d much rather not create these. Treating channel as a dimension, with some metadata somewhere about which channel index goes with each color, is more general.
This is true. We should support display of
ARGBType images. Adapting the
ARGBType image internally as @hanslovsky suggested using an
Views.stack should certainly be doable.
@frauzufall If you need further guidance or have questions, I’d be willing to dig deeper and make more concrete suggestions about how to proceed. (Off the top of my head, without reading the code again, I am not sure.)
Edit: A related topic here which is its own can of worms is alpha. This channel should really be treated differently somehow, but I am not sure how. It is quite unfortunate that ImageJ (both 1 and 2) currently do not support alpha in a useful way. Future design work to be done there!