[thijsman86]

Hi all,

I'm currently developing a mobile application for my thesis. My application has to have the possibility to capture photos and videos. Each time the user captures a photo or video, he/she gets the possibility of saving the file and uploading the file to a social networking site (Netlog).

I could use some help with the next issue. When a user takes a photo, the application asks to save yes or no and to upload yes or no. After confirming to save, the file is saved using the FileConnection API. When the user confirms to upload, some handling must be done. In order to keep the size of the file as little as possible (to send efficiently), I want to crop and/or compress the photo (crop due to maximum resolution size at Netlog). With getSnapshot() is use "encoding=jpeg" without width and height to achieve maximum compatibility.

What I tried is to crop the image with this code:

http://miniim.blogspot.com/2008/05/image-thumbnail-in-optimized-way-for.html

afterwards, I compress the image using this J2ME JPEG encoder:

http://ce.sharif.edu/~p_amini/j2me/JPEG_Encoder

Problem is: for an image with size 640x480 pixels, it takes the encoder +/- 25 seconds to compress.

In short: capture (using getSnapshot()), save bytes, createImage(bytes, 0, bytes.length), crop, compress

My question is: Is there a way to create an array of bytes after I crop the Image object? These bytes have to represent a JPEG photo.
Other suggestions are mostly welcome (e.g. better/faster encoder, other compression techniques, ...). Writing my own encoder is not one of them because I don't have the time to do that.

Thanks in advance! Help is muchly appreciated!

[grahamhughes]

If you have a process for cropping and encoding the image as a JPEG, and it works, I'd stick with it. Getting other people's implementations to work can sometimes be as big a job as writing your own.

That JPEG encode relies on quite a bit of floating-point math... this will be slow on phones, as most don't have any floating-point hardware. Possibly it could be re-written to use integer-only math.

On what (emulator/model of handset) does it take 25 seconds? Is this just the encoder, or the whole process?

One option is to pull some slight-of-hand. Start the encoding process immediately, in a separate thread. Ask the user if they want to upload first... they'll expect this to be slow, so it will cover the time taken to complete the encoding. If they say no, but they want to save, then you'll already be some way into the encoding process, so it will seem a little faster.

Cheers,
Graham.

[thijsman86]

Thanks for the reply!

On Sun's WTK emulator (2.5.2) a small photo (160x120 pixels) takes only a second or so. With the device I'm using (Nokia N95 8GB) it also takes a second or so with that resolution, but for bigger photo resolutions it seems the time increases 'exponentially' (with little exagaration). The 25 seconds consist of:
- about 40% to construct the JpegInfo object (99% converting from RGB to Y, Cr and Cb)
- about 60% to do the compression
so this does not include the uploading.

My promotor told me I should test this with different types of connection (wifi, GPRS, ...) and check whether the application benefits of the crop/compression or if I should just skip this and upload immediately without crop/compression.

Originally Posted by grahamhughes

Start the encoding process immediately, in a separate thread. Ask the user if they want to upload first... they'll expect this to be slow, so it will cover the time taken to complete the encoding. If they say no, but they want to save, then you'll already be some way into the encoding process, so it will seem a little faster.

I think I'm not really getting this. Did you meant: start the encoding immediately after the photo was taken; ask the user for confirmations (upload - save; in that order).
If the user only wants to save, there is no compression or cropping. What I forgot to mention is that the user can browse afterwards for photos and videos and upload them to their account.

[grahamhughes]

As a rough guide to upload speeds (in kilobytes per second):

GPRS: 2k/s
EDGE: 10k/s
3G: 12k/s
HSPA: 100k/s
WiFi: 100k/s+

Hope that helps.

Cheers,
Graham.

[thijsman86]

Originally Posted by grahamhughes

As a rough guide to upload speeds (in kilobytes per second):

GPRS: 2k/s
EDGE: 10k/s
3G: 12k/s
HSPA: 100k/s
WiFi: 100k/s+

Hope that helps.

Cheers,
Graham.

Thanks a lot. I'll try to test it anyway, but this is a good indicator.
By the way, I have changed the float calculations in JpegInfo to Integer calculations and the process now takes +/- eight seconds less!

Thanks for the help!