Displaying ARGBType images with SCIFIO

Hi all,

what could be done to display ARGBType images via SCIFIO?

ImageJ ij = new ImageJ();
Img<ARGBType> argb = ij.op().create().img(new FinalInterval(10, 10), new ARGBType());
ij.ui().show(argb);

Currently returns java.lang.ClassCastException: net.imglib2.type.numeric.ARGBType cannot be cast to net.imglib2.type.numeric.RealType.

This works:

ImageJFunctions.show(argb);
3 Likes

AFAIK: ImageJ2 expects a channel img, not an image of type ARGBType. If that is true, the following should work: Try converting RandomAccessibleInterval<ARGBType> into individual RAI per channel with the ARGBChannelSamplerConverter and then Views.stack the indivdiual channels into a channel RAI.

Sorry for no code example, on the run.

2 Likes

Thanks for the pointers! :slightly_smiling_face: Let me rephrase my question: would it be desired to support this in scifio directly and if yes what needs to be done?

1 Like

I would think so but I am probably not the right person to answer that question. cc’ing @ctrueden and @imagejan to comment or ping other people as appropriate.

In particular, I am not familiar with the code base and ij.ui().show seems to be very generic and accepts Object as parameter.

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 RealType!).

If SCIFIO returned images using ARGBType, what about other orderings? What about RGBType? BGRType? 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 ARGBChannelSamplerConverter plus 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!

1 Like