Does gluScaleImage() does lot of Buffering?

hi,

i m having trouble handling images of about 72M.
I m using the gluscaleImage() method to scale down the 4928*4928 (3) image to 512512 (3).
As the parameters say we need two buffers and they do get allocate ,though only for half the image(2464
2464).
A call to freeMemory() after this returns a lot of free memory.
But when the call reaches to the gluScaleImage() it throws OutOfMemoryError?
Does this method do some extra buffering for its own sake?
Is there any other way to sort this out?

Regards,
Shefali

Yes, there’s quite a bit of internal allocation that goes on in this routine currently. You may need to increase -Xmx as well as set -XX:MaxDirectMemorySize= some larger value. Try -Xmx=256m or similar first, then if that doesn’t help -XX:MaxDirectMemorySize=256m as well. I’m not sure whether the latter flag is required.

The -X options are not working with the entire image in one shot, even when im using -Xmx800M.
So i have divided the image into quarters,scale it to 256 and then create a texture for it.

However i m getting variety of Exceptions with the gluScaleImage().
THe OutOFMemory problem was sorted by these quarters though i still have to use the options and free the memory explicitly.
Then i got BufferedUnderfFlow but was solved when i flipped the buffer.
Now i m getting Runtime Exception suggessting “should not reach here.”
Surprisingly the quarter 1 got displayed but i cant really understand whether it is scaled?
Am i missing something?
Regards.

Then you’re probably out of native ram, where the direct buffers are allocated.

I forgot how to expand that… google a bit, or somebody else here might tell you.

i have been busy 4 some time…
HOwever i googled it but in vain…
i m not sure whether it is really a native ram prob as i have 4g ram…
Please gimme a solution as my rendering is pathetic because of this.
Regards.

Can you please provide a test case showing the problems you’re running into? It’s impossible to figure out what could be going wrong based on your description.

Thanks a lot for the patience.
I divided my entire 4k*4k image into 4 parts and then scaling each to 256 and then using DrawPixels.
I do realize that scaling function is slow and currently it is throwing should not reach here runtimeexception
Here is the code for dat:

   for(int i=0;i<4;i++)
{
    File red=new File("/usr3/shefali/project/images/s1.geo");
        File green=new File("/usr3/shefali/project/images/s2.geo");	
    File blue=new File("/usr3/shefali/project/images/s3.geo");
    ImageFile file=new ImageFile(red,green,blue); //This is a class reading data from the file

    file.setFileSize(new Dimension(width,height),3);
    file.setSkip();

    ByteBuffer originalImage=file.generateBuffer(i);
    scaledImage[i]=ByteBuffer.allocate(sx*sy*3);
    originalImage.flip();
  	    	 
    System.out.println("\nScaling Quarter of an Image............");

    int error=0;
    try{
	error=glu.gluScaleImage(GL.GL_RGB,height/2,width/2,GL.GL_UNSIGNED_BYTE,originalImage,sx,sy,GL.GL_UNSIGNED_BYTE,scaledImage[i]);
	System.out.println("Image Scaled Successfully.");
    }catch(Exception e){

System.out.println("Error occured while scaling image. Error Code: "+error);
e.printStackTrace();
}
originalImage=null;
freeResources();
}
stopTime=Calendar.getInstance().getTimeInMillis();
long timeDiff=stopTime-startTime;
System.out.println(“Successfully Created Quarters in: “+timeDiff+” ms…”);
setStatus(“Image Loaded”);

}

The image gets loaded successfully , with the exception thrown,but only after 30-35 seconds.
i m using a 4 processor machine wid 4g ram.

Regards,
Shefali

Sorry, but this really doesn’t help. You’ll need to provide a test case including all of the related image files and complete source code if we are to investigate possible problems in gluScaleImage in particular.

My recommendation would be to load your data into a BufferedImage and use Java2D to scale your image down rather than using gluScaleImage. You can then use the new TextureIO APIs to easily create a texture from the scaled-down BufferedImage.

[quote] You can then use the new TextureIO APIs to easily create a texture from the scaled-down BufferedImage.
[/quote]
i did that earlier and then changed to drawpixels:

  1. if i change the scaling factor to say 514, the image gets distorted.
  2. it streches whenever i increase the window size. yes that is fixable and i did dat. requires a bit of extra coding
  3. Creating textures requires me to put data in BufferedImage that requies jai stuff which i dont want to use.
  4. This takes up more memory space and so occasionally runs into outofmemoryerror.
    whereas wid drawpixels, i need to create only ByteBuffer. so i changed to DrawPixels.
    Also wid textures rendering took upto a bit more time.
    i havent really tried scaling using java as i currently want to stick to jogl.

[quote]Sorry, but this really doesn’t help. You’ll need to provide a test case including all of the related image files and complete source code if we are to investigate possible problems in gluScaleImage in particular.
[/quote]
Well, i will post the coding that reads the files and generates the originalmage[] that is passed into scaling function. Just gimme some time.
I cant really post the images as they are as big as 72m & also wont be allowed to bring them outside the office premises.

just wondering, where does the memory for the ByteBuffer gets allocated? in the vm heap or native mem?I think the first so
if i scale the image outside jogl,ie using an opengl gluScalImage() call and bring back the image to java using jni, will it make any difference?but b4 dat i need to sort out the first problem!!

I’m not sure exactly what you mean here but if you repeatedly downsample the image by a factor of two using bilinear filtering then Java2D will produce excellent results. See the source code for com.sun.opengl.util.ImageUtil.createThumbnail().

No it doesn’t. You can allocate a BufferedImage yourself, get the Raster and DataBuffer and fill it in. No JAI necessary.

You should be able to increase -Xmx to work around this problem. Given the relatively inefficient implementation of gluScaleImage (to the best of my recollection) you will probably get better efficiency using the BufferedImage approach to do your initial downsampling.

I don’t want to put you to a lot of trouble and don’t want to ask you to do something which will get you in trouble with your employer. I’m honestly not sure whether I can help you even if you post this source code. The source code alone without an image to read is not helpful. If you can produce a test pattern image or something then we could perhaps work with that. In this case you should probably file an issue on the JOGL home page and attach the test case. Again I don’t want to get your hopes up so you are probably better off trying to work with the BufferedImage-based strategy I mentioned above.

The Java-based gluScaleImage implementation currently in JOGL allocates the temporary ByteBuffers in the C heap, not the JVM’s object heap.

You can fall back to the C-based gluScaleImage implementation by passing -Djogl.glu.nojava on the command line. If that helps then maybe that’s the best answer.

[quote][You can fall back to the C-based gluScaleImage implementation by passing -Djogl.glu.nojava on the command line. If that helps then maybe that’s the best answer.
[/quote]
i think the weekend off and this option worked!!!
My rendering improved drastically to 5 secs from worst of 40 !

Thanks a lot !!
Does it mean dat gluScaleImageJava() is problematic?

I think the Java version of the GLU image scaling routines could use some more work, but they seem to work for most reasonably-sized images.