Resample image - drawImage exception

[karthikeyan.jambulingam]

Hi,

Am resampling the images to be displayed in my web page for different
height and width . This is the code i use for it whenever the height
and width changes:

ServletOutputStream sout = response.getOutputStream();
ImageIO.setUseCache(false);
BufferedImage bufImg = ImageIO.read(new File(src));
Image scaledImage = bufImg.getScaledInstance( width, height,
Image.SCALE_SMOOTH);
BufferedImage scaledBufImage = new BufferedImage(width, height ,
BufferedImage.TYPE_INT_RGB);
Graphics grphcs = scaledBufImage.createGraphics();
grphcs.drawImage(scaledImage, 0, 0, null);
grphcs.dispose()';
ImageIO.write(scaledBufImage , "jpg" , sout);

bufImg.flush();
scaleImage.flush();
scaledBufImage.flush();
sout.flush();
sout.close();

This code works fine . But take up to 100%CPU after some time , when
thread dump was taken a lot of threads remained in locked condition.
This was the dump for the locked thread:

at sun.awt.color.CMM.cmmColorConvert(Native Method)
at sun.awt.color.ICC_Transform.colorConvert(ICC_Transform.java:859)
at java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:160)
at
java.awt.image.ComponentColorModel.getRGB(ComponentColorModel.java:1127)
at java.awt.image.BufferedImage.getRGB(BufferedImage.java:870)
at
sun.awt.image.OffScreenImageSource.sendPixels(OffScreenImageSource.java:157)
at
sun.awt.image.OffScreenImageSource.produce(OffScreenImageSource.java:169)
at
sun.awt.image.OffScreenImageSource.addConsumer(OffScreenImageSource.java:48)
- locked <0x4f4e9a30> (a sun.awt.image.OffScreenImageSource)
at
sun.awt.image.OffScreenImageSource.startProduction(OffScreenImageSource.java:62)
at
java.awt.image.FilteredImageSource.startProduction(FilteredImageSource.java:166)
at
sun.awt.image.ImageRepresentation.startProduction(ImageRepresentation.java:647)
at
sun.awt.image.ImageRepresentation.drawToBufImage(ImageRepresentation.java:722)
at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:855)
at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java:168)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2833)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2818)

Am using java 1.5 in a linux box . Is there any issues with drawImage
method , if so is there any alternative ways to resample images.
Searched thru the web , but was not able to find useful messages.

Thanks for your help.

Regards
jkyaar
P.S : Has posted the same in GUI group , reposting it here , as i
thought this group is more appropriate.

 

[hiwa]

Hi,

Am resampling the images to be displayed in my web page for different
height and width . This is the code i use for it whenever the height
and width changes:

ServletOutputStream sout = response.getOutputStream();
ImageIO.setUseCache(false);
BufferedImage bufImg = ImageIO.read(new File(src));
Image scaledImage = bufImg.getScaledInstance( width, height,
Image.SCALE_SMOOTH);
BufferedImage scaledBufImage = new BufferedImage(width, height ,
BufferedImage.TYPE_INT_RGB);
Graphics grphcs = scaledBufImage.createGraphics();
grphcs.drawImage(scaledImage, 0, 0, null);
grphcs.dispose()';
ImageIO.write(scaledBufImage , "jpg" , sout);

bufImg.flush();
scaleImage.flush();
scaledBufImage.flush();
sout.flush();
sout.close();

This code works fine . But take up to 100%CPU after some time , when
thread dump was taken a lot of threads remained in locked condition.
This was the dump for the locked thread:

at sun.awt.color.CMM.cmmColorConvert(Native Method)
at sun.awt.color.ICC_Transform.colorConvert(ICC_Transform.java:859)
at java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:160)
at
java.awt.image.ComponentColorModel.getRGB(ComponentColorModel.java:1127)
at java.awt.image.BufferedImage.getRGB(BufferedImage.java:870)
at
sun.awt.image.OffScreenImageSource.sendPixels(OffScreenImageSource.java:157)
at
sun.awt.image.OffScreenImageSource.produce(OffScreenImageSource.java:169)
at
sun.awt.image.OffScreenImageSource.addConsumer(OffScreenImageSource.java:48)
- locked <0x4f4e9a30> (a sun.awt.image.OffScreenImageSource)
at
sun.awt.image.OffScreenImageSource.startProduction(OffScreenImageSource.java:62)
at
java.awt.image.FilteredImageSource.startProduction(FilteredImageSource.java:166)
at
sun.awt.image.ImageRepresentation.startProduction(ImageRepresentation.java:647)
at
sun.awt.image.ImageRepresentation.drawToBufImage(ImageRepresentation.java:722)
at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:855)
at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java:168)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2833)
at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2818)

Am using java 1.5 in a linux box . Is there any issues with drawImage
method , if so is there any alternative ways to resample images.
Searched thru the web , but was not able to find useful messages.

Thanks for your help.

Regards
jkyaar
P.S : Has posted the same in GUI group , reposting it here , as i
thought this group is more appropriate.

Your current code is redundant and inefficient.
For BufferedImage scaling, use AffineTransformOp or RescaleOp.
AffineTransformOp is simpler to use.

 

[Andrew Thompson]

P.S : Has posted the same in GUI group , reposting it here , as i
thought this group is more appropriate.

Thanks for having the sense to mention.
Did you go the 'extra mile' and report the same
as a conclusion to the c.l.j.gui thread?

Andrew T.

 

[karthikeyan.jambulingam]

Hi,

Thanks for ur suggestions . The resampled image does not look good as
it was with the previous one. Am posting the code , that i have changed
:

ImageIO.setUseCache(false);
BufferedImage bufImg = ImageIO.read(bis);
BufferedImage scaledBufImage = new BufferedImage(width, height ,
BufferedImage.TYPE_INT_RGB);
double scaleX = (double)width / (double)bufImg.getWidth();
double scaleY = (double)height / (double)bufImg.getHeight();
double scale = Math.min(scaleX, scaleY);

AffineTransformOp op = new
AffineTransformOp(AffineTransform.getScaleInstance(scale , scale) ,

AffineTransformOp.TYPE_NEAREST_NEIGHBOR);
scaledBufImage = op.filter(bufImg , null);
ImageIO.write( scaledBufImage , "jpg" , sout);

Is there any way that i can improve the quality of the rescaled image
?.
why was the previous code so inefficient ? , please provide ur
suggestions.
Am not sure why there is difference between the two rescaled images ?

Thanks for ur help.

Regards
JK

 

[hiwa]

Hi,

Thanks for ur suggestions . The resampled image does not look good as
it was with the previous one. Am posting the code , that i have changed
:

ImageIO.setUseCache(false);
BufferedImage bufImg = ImageIO.read(bis);
BufferedImage scaledBufImage = new BufferedImage(width, height ,
BufferedImage.TYPE_INT_RGB);
double scaleX = (double)width / (double)bufImg.getWidth();
double scaleY = (double)height / (double)bufImg.getHeight();
double scale = Math.min(scaleX, scaleY);

AffineTransformOp op = new
AffineTransformOp(AffineTransform.getScaleInstance(scale , scale) ,

AffineTransformOp.TYPE_NEAREST_NEIGHBOR);
scaledBufImage = op.filter(bufImg , null);
ImageIO.write( scaledBufImage , "jpg" , sout);

Is there any way that i can improve the quality of the rescaled image
?.
why was the previous code so inefficient ? , please provide ur
suggestions.
Am not sure why there is difference between the two rescaled images ?

Thanks for ur help.

Regards
JK

Try TYPE_BICUBIC or use RenderingHints version.

BufferedImage scaledBufImage = new BufferedImage(width, height ,
BufferedImage.TYPE_INT_RGB);

You don't need this line.

 

[karthikeyan.jambulingam]

Hi,

Tried out different interpolation types but none seems to give a
quality image. With TYPE_BICUBIC and TYPE_BILINEAR was not able to get
any output and at times get an exception saying , software caused to
abort the connection. While searching about TYPE_BILINEAR , ended up in
this page :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4503132 but that was
of no help.

Can anyone point out the issue with drawImage(locking the thread)
method ?
my requirement is to resample images into different sizes , is there
any thing which i should look into ?

Thanks

Regards
JK

 

[Andrew Thompson]

Tried out different interpolation types but none seems to give a
quality image. ...

I resisted cutting into your original message on
the memory leaks. But I will now..

If you use your original code, but only create
objects as necessary, and use the scaling
algorithm that was originally used, does the
memory problem still occur?

Have the changes you are now running, *solved* the
memory leak (at the expense of image quality).

The reason I ask is that I had a very hard time
getting the JVM to *not* cache images, but came
up with a 'rock solid reliable' way to ensure memory
leaks did not occur.

Basically, it involved getting the images as a byte[]
array, then simply 'stamping out' an image when
necessary, using a static toolkit method.

( I realise your code called 'no cache' or whatever,
I was not aware it existed - but I am sceptical of
its effectiveness.. )

Andrew T.

 

[karthikeyan.jambulingam]

Hi,

Go thru the below link to know the reason for setUseCache method.
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4513817

I have not solidly looked into Memory leaks . I have run my test code
for few days and did not notice considerable memory leak.

My main issue here is with the CPU shooting up to 100% and thread dump
indicating the locked threads. Is there any way that i could bring the
CPU usage down.? However i will look into Memory leaks later.

BTW , could u point me to the static toolkit method , u have used.

In my case , there are chances for the client to close the connection
while the server is drawing the image. Just thinking , will this be the
reason for the lock.

Quite struck with the problem and am not sure what next ....

Regards
JK

 

[Andrew Thompson]

Go thru the below link to know the reason for setUseCache method.
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4513817

I have not solidly looked into Memory leaks .

That line surprised me, till I reread your original
post and noted there was actually no mention
of mem. leaks whatsoever, I thought I recalled
something to that effect.

My bad.

Andrew T.