Member Avatar for squinx22

Hello all,

I am having a problem in creating an image by using createImage() method when trying to load large files.

FileConnection fc = (FileConnection) Connector.open("file:///" + path + "/",Connector.READ);
InputStream fis = (InputStream) fc.openInputStream();
image = Image.createImage(fis); // I got the out of memory exception here.

Are there any ways to resize the image from the stream first before using createImage()?

Thanks!

  • 5 Contributors
  • 10 Replies
  • 126 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by articlemaster9

Dani AI

Generated

Short summary and context: is hitting an OutOfMemoryError when calling the image loader for large pictures on a handset. The emulator often gives misleading results (see ), and changing the JVM heap on a real phone is usually not possible. As and hinted, the practical choices are to avoid decoding the full large image on-device or to use a decoder that can produce a smaller image while reading the stream.

Practical, ordered options to try now:

  • Serve resized images: the simplest, most robust fix is to generate device-sized images before the MIDlet requests them. Detect screen constraints at runtime and request an appropriately scaled file from your server. This avoids device decode entirely.
  • Inspect image headers to decide: read only the file header to get intrinsic width/height (JPEG: locate the SOF marker; PNG: read the IHDR chunk). Compute requiredBytes = width * height * bytesPerPixel (use 4 as a conservative estimate for int/ARGB buffers). If that exceeds a safe budget, fetch a smaller image instead of decoding.
  • Use a streaming/downsampling decoder or vendor API: some device vendor APIs and a few J2ME decoders can decode MCU-by-MCU or return scaled images without allocating the full-resolution bitmap. Search for lightweight J2ME JPEG/PNG decoders or check handset-specific classes (many manufacturers expose EncodedImage-like helpers).

Troubleshooting checklist:

  • Always test on the target handset and not only on the emulator.
  • Log the reported original dimensions before attempting to decode.
  • If implementing in-device scaling, decode directly into the final smaller buffer (avoid creating a full-size int[] first).
  • Provide a graceful fallback (placeholder thumbnail or “request low-res” path) when memory limits are exceeded.

Reference points: follow up on ’s linked thread for implementation examples and search for “J2ME streaming JPEG decoder” or vendor “EncodedImage” docs for device-specific helpers.

Recommended Answers

All 10 Replies

Member Avatar for BestJewSinceJC

I don't see the createImage method in any docs for the Image class. Post a link to the doc for me please? Also, why would it be able to construct an Image from an InputStream? What you want to do is read the data from the InputStream, then construct an Image from the data... right? So do that instead...

Also, you might want to look into the ImageProducer class. I didn't look into it much, got to get to sleep, but see if it has anything useful...

Member Avatar for squinx22

here is the link to the doc


Thanks for the reply...

I cant seem to have the idea to get out of the memory exception.

Member Avatar for squinx22

Thank for the reply, I am going to implement this on real mobile device which I could not modify the heap size. :)

Member Avatar for masijade

Then the image is simply too big. You need to modify the image before attempting to load it into your app.

Member Avatar for squinx22

Is there any other way to do that? Anyway, I appreciate your response about this.... Thank you! :)

Member Avatar for kvprajapati

masijade>Then the image is simply too big. You need to modify the image before attempting to load it into your app.

squinx22>Is there any other way to do that?

Are you game with us?

Member Avatar for masijade

Well, to "scale" the image, you would first have to have it loaded.

The only other way is to know the structure of the image file, and the original size and density parameters of the image (which can also, usually, be obtained somewhere in the file), so that you can read the file, a part at a time, restructuring/scaling as you go and write that, a part at a time, into a new file, which you could then load as an image.

This, of course, takes intimate knowledge of the storage structure of the image format in question, of course.

Member Avatar for articlemaster9

Thank for the reply, I am going to implement this on real mobile device which I could not modify the heap size. :)

If you are creating mobile device application then first you try them in sample devices.You are working on J2ME and which is slightly different from normal java.

Remember one thing the memory size of mobile phone is limited.The screen resolution,width and height is not same for all handsets. So everytime you need to test your application on sample device and then when its ready upload them to mobile phones.

When creating image in J2ME, you should use doublebuffer for creating them.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.