Nokia 3500, capture://video, etc.

[srowen]

Starting a thread to continue Romin's thread on wiki comments:

So Romin you have found that some JSR-135 devices don't actually
support getSnapshot() with "capture://video", and it further sounds
like you got it to basically work on these devices with a little more
tweaking. First let me follow up on some of your comments.

That is good to know that the issue on some devices is just that they
don't support getSnapshot(), thanks for chasing that down. The call to
player.stop() is useful when using capture://video, I believe, to
freeze on the frame that is captured. It may or may not cause problems
with capture://image

So you are saying that just by using capture://image, and not calling
stop(), it seems to work? Do you still get a video stream from the
camera showing on the screen?

I must say I am a bit surprised that this works, since you are working
with a VideoControl! From reading the API I thought using capture://image
would involve a significantly different use of the API.

But if this leads to a fairly easy workaround for some devices, great.

Now it sounds like you are just running into the fact that it is hard
to read blurry images -- with this code at least. Try taking a picture
from farther away, or take a picture of a large QR Code on your
computer screen? these should work reliably. If nothing works, maybe
there is some issue with the format of the capture you actually get.

[Romin Irani]

Hello Sean,

Let me present my findings more clearly:

1. I changed the statement from capture://video to capture://image and
also passed the parameter encoding=jpeg to getSnapshot(...) method. If
I leave the rest of the code as is - I get a null pointer exception
since the raw image bytes returned is null by the getSnapshot(..)
method. Passing null to the getSnapshot(...) as parameter is also
resulting in null since several Nokia phones seem to assume that null
means encoding=png and since the Nokia 3500c does not have png as a
supported encoding format - it fails.

2. I have a feeling that if we use the locator as capture://image for
the MediaPlayer and then get the Video Control - then the
player.stop() is resulting in a certain behaviour that makes the raw
image bytes returned by getSnapshot as null. I got a hint from the
thread over here: http://discussion.forum.nokia.com/forum/showthread.php?t=78634

3. So I rearranged the player.stop() method by calling it after the
getSnapshot(...) and then the raw image bytes are not null.

4. During all this time - I DO GET a Video Stream from the camera
showing on the screen. So based on this - it looks like the app is
working as expected - except when I run into those decoding errors
(which I will try with some larger QR Codes, etc). I have generated
the QR Code from the kaywa site and am capturing it from the screen.

Moving on next :
1. I am going to try changing the encoding=jpeg and try out all the
encoding options one after the other. I will do this a little later in
the day and report my findings.

2. If some of this finally makes sense - we might just have to add
methods for getLocator() and getImageEncoding() in the code base. And
you could determine which one is supported and only then initialize
the player.

3. (Optional) - I think what could help you moving on is some kind of
a J2ME utility (packaged separately) that all of us first run on their
mobiles and report our system (phone) capabilities. So everytime we
report a problem - we could also mention some of our phone
capabilities which could help point the obvious problems straight
away.

4. Here are some threads from the Nokia forum around this issue
including reorganizing some directions of reorganizing the code to
determine whether to use capture://video or capture://image.
http://discussion.forum.nokia.com/forum/showthread.php?t=82903

5. On some other related forum topic - I found this piece of text
which might be interesting to note:

"Re: hey nokia please return to capture://video for the rest of the
S40 devices

I got some answers from Series40 organization
There is a good reason for having separate locators for video and
images. As the camera hw is modal (you have to initialize the hw
either in video mode or in still image mode) and if you want to take a
picture in video mode, the hw have to be changed to still image mode
first and hence serious shutter lag is experienced. With separate
locators the hw can be initialized to the correct mode and the user
experience is much smoother."

6. Several other threads discussing this workaround (or problem :-))
http://discussion.forum.nokia.com/forum/showthread.php?t=103158

Cheers
Romin.

[Romin Irani]

SUCCESS!!!!

1. I used the following encoding :
zXingMIDlet.getVideoControl().getSnapshot("encoding=jpeg");
2. Generated a QRCode at the Kaywa site with a simple text i.e. my
name "Romin Irani".
3. Took a printout. Several valid QRCodes on the screens just seem to
be failing for me.
4. Tried several times on the printout - 2 out of around 10 times - it
decoded the text correctly. Rest of the time - It said could find find
roots, etc. If I am quite far away - it doesnt decode. Too close - the
image gets blurred. At some distance - it seems to be hitting the
magic spot and is able to decode.

So - assuming that the decoding aspect will improve - I can
confidently state that with the changes done like capture://image
instead of capture://video and not using null as parameter to the
getSnapshot method - there has been success for simple text on a
device (3500c Nokia). This device DOES NOT support JSR-234 - so its
just the basic version that I am using :-)

I am confident of things getting better from here on. Thanks for the
hard work Sean. I will continue with more tests and tweaks.

Cheers
Romin.

[srowen]

OK, that's very interesting. I am not sure the API *should* work that
way but if it does, that's cool. I imagine I can hack this into a
workaround in the main version. Thanks very much.

That is pretty poor decoding performance. Yeah captures will be a
little challenging if the code is small and the camera has no auto-
focus or macro mode (does it? sometimes you will see a small switch
under the lens that controls this). Try blowing up the image on-screen
and I bet you will have more success.

Also sometimes it's hard dto know exactly when the camera is capturing
a photo, and if it's after you think you may be moving the camera when
the picture takes. Not sure if that is the issue, but the more you can
hold still the better of course.

I think you tried the reader at reader.kaywa.com right? It would be
interesting to compare and you may get better decoding now from that
application.

[Romin Irani]

Yes - I tried the reader at kaywa.com - there are instances where it
is failing too. For e.g. if I had a printout of the QRCode and its
slightly bent or even if the printout is old - it seems to sometimes
give up. But on a general note - its success rate at decoding is
pretty high - maybe 1 out of 100 times - it fails.

I am definitely going to try and see what makes me get better results
with ZXING - because I would rather use this application than the
Kaywa one since I want to extend and create little example
applications around it.

The Camera on this phone is pretty basic - it supports zoom but not
JSR-234 - so not sure how to make this all work via zoom. I can pretty
much put the limitation currently on the kind of phone that I have.

Any other tips on what can be done ?