16 bit grayscale BufferedImage

[Patrick Pirrotte]

Hi all,

I've run into trouble trying to convert a 16 bit grayscale BufferedImage to
an ImagePlus entity. Digging through the mailing list, I found out that
several other people had the same trouble:

using FileOpener on 16-bit grayscale in java app ? (06/04/10)
BufferedImage (05/09/15)
loading 16 bit images from other java code, ImageJ 1.28 (05/08/12)
...

It seems that the mechanism underlying setImage(BufferedImage image) does
not interprete the ColorModel correctly. I'm not quite sure about this,
maybe my code is buggy:

DataBuffer dataBuffer = new DataBufferUShort ((short[])data,1);
ImageTypeSpecifier it = ImageTypeSpecifier.createGrayscale(16,
DataBuffer.TYPE_USHORT, false);
ColorModel cm = it.getColorModel();
SampleModel sm = it.getSampleModel(256,256);
WritableRaster wr = Raster.createWritableRaster(sm,dataBuffer,new
Point(0,0));
BufferedImage image = new BufferedImage(cm,wr,true,new Hashtable());

When I create an ImagePlus from this BufferedImage I get an 24 bit RGB...
(ImagePlus im = new ImagePlus("my image",image))

I'd prefer to read my pixel data directly from ImageJ through the getPixel
method but unfortunately I have to rely on a BufferedImage. I've quickly
browsed through Jarek's ImagePlusCreator (IJ-ImageIO adapter plugin), and as
far as I understand it works around this problem by getting the Raster, the
ColorModel,... from the BufferedImage resulting from ImageIO. Using those it
recreates a valid 16 bit ImagePlus.

Maybe I'm not seeing the big picture here, but my question is: wouldn't it
be nicer to adapt ImagePlus.setImage and it's submethods to understand a
signed and unsigned short ColorModel from BufferedImage? Or am absolutely
out of line and my code is just plain wrong (which happens far too often to
be pleasant).

Thanks,

Patrick

[Wayne Rasband]

You will be able to construct ImagePlus and ShortProcessor objects from
a 16-bit BufferedImage in ImageJ 1.37d.

-wayne

On Apr 12, 2006, at 7:25 AM, Patrick Pirrotte wrote:

> Hi all,
>
> I've run into trouble trying to convert a 16 bit grayscale
> BufferedImage to an ImagePlus entity. Digging through the
>  mailing list, I found out that several other people had the same
> trouble:
>
> using FileOpener on 16-bit grayscale in java app ? (06/04/10)
> BufferedImage (05/09/15)
> loading 16 bit images from other java code, ImageJ 1.28 (05/08/12)
> ...
>
> It seems that the mechanism underlying setImage(BufferedImage
> image) does not interprete the ColorModel correctly. I'm not
> quite sure about this, maybe my code is buggy:
>
> DataBuffer dataBuffer = new DataBufferUShort ((short[])data,1);
> ImageTypeSpecifier it = ImageTypeSpecifier.createGrayscale(16,
> DataBuffer.TYPE_USHORT, false);
> ColorModel cm = it.getColorModel();
> SampleModel sm = it.getSampleModel(256,256);
> WritableRaster wr = Raster.createWritableRaster(sm,dataBuffer,new
> Point(0,0));
> BufferedImage image = new BufferedImage(cm,wr,true,new Hashtable());
>
> When I create an ImagePlus from this BufferedImage I get an 24 bit
> RGB...
> (ImagePlus im = new ImagePlus("my image",image))
>
> I'd prefer to read my pixel data directly from ImageJ
> through the getPixel method but unfortunately I have to rely
> on a BufferedImage. I've quickly browsed through Jarek's
> ImagePlusCreator (IJ-ImageIO adapter plugin), and as far as
> I understand it works around this problem by getting the
> Raster, the ColorModel,... from the BufferedImage resulting
> from ImageIO. Using those it recreates a valid 16 bit
> ImagePlus.
>
> Maybe I'm not seeing the big picture here, but my question
> is: wouldn't it be nicer to adapt ImagePlus.setImage and
> it's submethods to understand a signed and unsigned short
> ColorModel from BufferedImage? Or am absolutely out of line
> and my code is just plain wrong (which happens far too often
> to be pleasant).
>
> Thanks,
>
> Patrick
>

[Patrick Pirrotte]

It works nicely. Thank you very much Wayne.

Patrick


-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Wayne
Rasband
Sent: 12 April 2006 20:03
To: [hidden email]
Subject: Re: 16 bit grayscale BufferedImage


You will be able to construct ImagePlus and ShortProcessor objects from
a 16-bit BufferedImage in ImageJ 1.37d.

-wayne

On Apr 12, 2006, at 7:25 AM, Patrick Pirrotte wrote:

> Hi all,
>
> I've run into trouble trying to convert a 16 bit grayscale
> BufferedImage to an ImagePlus entity. Digging through the  mailing
> list, I found out that several other people had the same
> trouble:
>
> using FileOpener on 16-bit grayscale in java app ? (06/04/10)
> BufferedImage (05/09/15) loading 16 bit images from other java code,
> ImageJ 1.28 (05/08/12) ...
>
> It seems that the mechanism underlying setImage(BufferedImage
> image) does not interprete the ColorModel correctly. I'm not quite
> sure about this, maybe my code is buggy:
>
> DataBuffer dataBuffer = new DataBufferUShort ((short[])data,1);
> ImageTypeSpecifier it = ImageTypeSpecifier.createGrayscale(16,
> DataBuffer.TYPE_USHORT, false);
> ColorModel cm = it.getColorModel();
> SampleModel sm = it.getSampleModel(256,256);
> WritableRaster wr = Raster.createWritableRaster(sm,dataBuffer,new
> Point(0,0));
> BufferedImage image = new BufferedImage(cm,wr,true,new Hashtable());
>
> When I create an ImagePlus from this BufferedImage I get an 24 bit
> RGB...
> (ImagePlus im = new ImagePlus("my image",image))
>
> I'd prefer to read my pixel data directly from ImageJ
> through the getPixel method but unfortunately I have to rely on a
> BufferedImage. I've quickly browsed through Jarek's ImagePlusCreator
> (IJ-ImageIO adapter plugin), and as far as I understand it works
> around this problem by getting the Raster, the ColorModel,... from the
> BufferedImage resulting from ImageIO. Using those it recreates a valid
> 16 bit ImagePlus.
>
> Maybe I'm not seeing the big picture here, but my question
> is: wouldn't it be nicer to adapt ImagePlus.setImage and
> it's submethods to understand a signed and unsigned short ColorModel
> from BufferedImage? Or am absolutely out of line and my code is just
> plain wrong (which happens far too often to be pleasant).
>
> Thanks,
>
> Patrick
>