I was able to edit the face analyzer sketch into a working camera sketch...

Hi Jesse,

Hmm... what kind of console messages are you getting ?

Not a lot of message....only this:

Oh. 

:-/ my code is your code :)

I haven't encountered the same issues as you in your other topic though... all the examples - besides the basicCamera - work for me.

@jesse:

OS X 10.6.6

On an old  post, I have seen that there is problems using processing android 0192 with SDK 9... and it's my configuration.
So I have updated my SDK to 10, but without success.
...and processing 0194 doesn't work on ubuntu lucid...

OOOk !
THE solution to use 0194 under linux is :

              

               

                For the time being, just copy the modes/android/android-core.zip from another 
                
Processing download (i.e. the Windows w/o Java version) and it'll work fine. 
                
The file is just missing from release 0194.
               
              
 


:-/
Thanks !!!

ok, this code work for me. Except that on my phone I have video from my camera in gray values and 4 little video from my cam too, green and pink, spilt the screen in 4 equals parts...

I think, from ak_erik's original blog post on accessing the camera, that it is in YUV color... 

Hi Jesse,

On the ak_erik code, decodeYUV420SP() convert from YUV to RGB.
I've find this formula a little bit different from ketai formula:

1. B = 1.164(Y - 16)                   + 2.018(U - 128)
   
   G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128)
   
   R = 1.164(Y - 16) + 1.596(V - 128)

but it doesn't change anything.
Now i'm looking for another part of this hardcore method :)

It's possible they've changed their code since I snatched that part. What's interesting is that the visual artifacts people are describing above are the same things I ran into when I was trying to write my own decoder.  Grabbing the ketai decoder solved all that pretty quick.  I'm wondering if different phones are returning the color data in different ways?  If the format being returned isn't yuv (or one of its derivatives) then the decoder wouldn't work.  Check out these docs for adding some debug prints to your code:

hey all,

i help out on the Ketai development so here are some thoughts.  The way the pixel buffer is returned from the android camera service varies, unfortunately.  The Ketai conversion method is the one that works best across all the mobiles we've tested here.  The issue is that this conversion, in theory, should be unnecessary as there is an option to request the pixels in the right format from the camera service.  unfortunately most android mobiles in the wild have not implemented this option and we get, be default, the NV21 format which must be converted for use as a PImage pixel buffer.  This all happens in the java vm and slows the process somewhat.  Ketai is working on some native code to see if this yields any performance benefits so that at the very least 640x480 resolutions may be used.  The Ketai references to opencv were an initial attempt to port opencv for use on android as there is hope that native image processing yields performance improvements across the board.  The proof of concept proved successful but not very useful, yet.  This is an ongoing process and is stuck until some of the other issues are flushed out.

The face analyzer in Ketai is just a wrapper for the android face analyzer which is not the best but functions well enough to play with.  The OpenCV face detection is more configurable and we hope to eventually port it over.

Hopefully moving forward the platform&vendors will handle the conversion of the pixel buffer natively so that all performance benefits and optimizations can be realized.  We also had limited success with front facing cameras but they were proprietary and hardware specific.  We hope android rolls this eventually although i havent looked at 3.0 yet so maybe its already there....

Hope this helps clear up a few things. 

There are some updates in the pipeline that we hope we can complete soon, we'll keep everyone posted.

thanks!

Thanks for your answer coder.guy!

I'm using a samsung spica i5700, and it have the NV21 format, so I don't understand clearly the origin of the problem.
Nevertheless I've changed a little bit the code from ketai, in an ugly way i suppose, but for now my phone displays the camera view, without the 4 smalls images. But i have some trouble about color's conversion...this is my cheapest version:

1. void decodeYUV420SP(int[] rgb, byte[] yuv420sp, int width, int height) {
2.     // Pulled directly from:
3.     // http://ketai.googlecode.com/svn/trunk/ketai/src/edu/uic/ketai/inputService/KetaiCamera.java
4.     final int frameSize = width * height;
5.     int u=0, v=0;
6.     for (int j = 0, yp = 0; j < height; j++) {
7.       for (int i = 0; i < width; i++, yp++) {
8.         int y = (0xff & ((int) yuv420sp[yp]));// - 16;
9.         v = (0xff & yuv420sp[yp]);// - 128;
10.         u = (0xff & yuv420sp[yp]);// - 128;
11.         if (y < 0) y = 0;
12.         int y1000 = 1000*y;
13.         int r = y1000 + 1139*v;
14.         int g = y1000 - 394*u - 580*v;
15.         int b = y1000 + 2032 *u;
16.         //calibration
17.         if (r < 0)
18.           r = 0;
19.         else if (r > 262143)
20.           r = 262143;
21.         if (g < 0)
22.           g = 0;
23.         else if (g > 262143)
24.           g = 262143;
25.         if (b < 0)
26.           b = 0;
27.         else if (b > 262143)
28.           b = 262143;
29.         //definition des couleurs avec les operateur shift (acces binaire)
30.         rgb[yp] = 0xff000000 | ((r << 6) & 0xff0000) | ((g >> 2) & 0xff00) | ((b >> 10) & 0xff);
31.       }
32.     }
33.   }

It's true, that :

This all happens in the java vm and slows the process somewhat.

I think i'm around 1fps. :)

Opencv is using a different way to access the camera, with opengl I think, it is not a better  way?

many thanks !

Hi,

I just want to know if someone has tested the KetaiCamera example on a Galaxy Spica, with the new Ketai.jar ...
For me it's always the same 4 littles pink & green videos screens into one grey video screen :-/
I'm searching for the video format send by the spica's camera, but I have only find this :

- supported format when I call getSupportFormat()  : YCrCb ( ok for the YUV converter normally :-/ )
- camera definition : 240*160 or 352x288 (CIF) (15 fps)

CIF is acronym for Common Intermediate Format
CIF was designed to be easy to convert to PAL or NTSC standards. CIF defines a video sequence with a resolution of 352 × 288 like PAL Source Input Format, a framerate of 30000/1001 (roughly 29.97) frames like NTSC, with colour encoded using YCbCr 4:2:0.
a bit further :
The CIF "image sizes" were specifically chosen to be multiples of macroblocks (i.e. 16 × 16 pixels) due to the way that discrete cosine transform based video compression/decompression is handled. So, by example, a CIF-size image (352 × 288) corresponds to 22 × 18 macroblocks.

So Spica camera is YCrCb color but I' not sure about the important aspect of this  : the macroblocks story. But I'm not an expert...
If someone can shed some light on this, I would be glad :)


Thanks

Ok, I have modified the KetaiCamera class for my spica and it's working.
It's only Black & White because I have some problem with color conversion, and the camera size is small but it's good engouh for now :)

if somebody is interesting in acquire this  class I can share !

to be continued...