i think it is!
if you place a timer everytime the event triggers, you can check it! i did!
it triggers once every 130-140 milliseconds so it is indeed 7fps approximately
maybe you are seeing the processing actual framerate that can be really fast!
could you check with a timer and print everytime a capture event triggers to see if you really have 15fps? if that is the case then for sure it is a software (library) bug
but after all that shows to me that is a software issue (in ketai’s library where it calculates fps), not hardware!
just selects the first available previewRate the camera supports. Unfortunatelly as i mentioned to @akenaton , i am not into java to dig in ketai’s library it’ll take me ages!
even the push, popMatrix, make the framerate significantly lower, so i use code to even mirror a Pimage - for example video! it boosts 4-5 times the framerate, with a bit of code!
I also always single loop the image pixel array and if i need i calculate the coords, for y = i/width; and x =i%width;
mr Chung is a great help to the community of processing, with extremely good articles in hiw blog! respect!
I think it does. See the code here. It takes the camera hardware values.
(You can also take this whole class directly into your code, instead of importing it as a library, and make some changes.)
i’ll try later to set nearestFPS to 30 manually to check if it works.
Also i’ll check if i can find a more efficient way to decode YUV420SP
there must be a solution.
@noel did you check with a timer evet to see if it is actually 15 your prevew fps? it’ll be nice if we had that feedback from you or @paulgoux that get 15! so every 65-66milliseconds
Not when I choose a bigger cam-frame. Then it drops to the mentioned 7 f/s The draw()-frame is not updated until it finishes it’s for loops. So I still argue that the slowness of the sketch is in it’s draw()-frame calculations. If you use for instance: if (frameCount % 5 == 0) { } around the for-loops you get a much better result. You haven’t posted a code yet, but I assume you are tracking motion by color comparing, like in my sketch But if you are going to use a powerful red led, for instance, you only need to search a for real red pixel in the pixels array, which will be a lot faster.
the code is identical to your’s and based to Shiffmans blob detection.
I just create a frame differencing before that, so to search for the color only in the area that differs from previous frame. I calculate min and max x,y in the area that changed. if you want i can post it of course but i do not see any significant differences from yours, that worth mentioning.
The problem is with 7fps it does not worth trying with the phone, 15fps maybe ok.
the main issue is the framerate, since captore event triggers @7fps it is not usable.
Even when i use nothing regarding image processing, just show the frame unfortunatelly i get that poor fps.
I also saw that in ketai’s github as issue’s posted
If you take the cam-frame small enough you get that.
I experimented a bit with the suggestion I made above, and the frameRate stays at the normal 30 f/s with a 600/480 resolution. I used a small reflective red object. A led is too bright.
If you want the cam-image displayed as well, just draw the lines on a transparent PGraphics.
import ketai.camera.*;
KetaiCamera cam;
int dx, dy, pdx, pdy;
void setup() {
size(640, 480);
background(255);
textSize(40);
strokeWeight(4);
stroke(0, 0, 80);
cam = new KetaiCamera(this, 640, 480, 30);
cam.setCameraID(0);
cam.start();
}
void onCameraPreviewEvent() {
cam.read();
}
void draw() {
cam.loadPixels();
for (int x = 0; x < cam.width; x++ ) {
for (int y = 0; y < cam.height; y++ ) {
color current = cam.pixels[x+y*cam.width];
float r = red(current);
float g = green(current);
float b = blue(current);
if (r > 220 && g < 40 && b < 40) {
dx = x;
dy = y;
}
}
}
line(dx, dy, pdx, pdy);
pdx = dx;
pdy = dy;
fill(255);
rect(0, 0, 280, 60);
fill(0);
text(str(frameRate), 40, 40);
}
i am using a plain sketch not even showing preview image.
import ketai.camera.*;
KetaiCamera cam;
int time;
void setup() {
orientation(LANDSCAPE);
imageMode(CENTER);
cam = new KetaiCamera(this, 176, 144, 30);
time = millis();
}
void draw() {
//image(cam, width/2, height/2);
}
void onCameraPreviewEvent()
{
println(millis()-time);
time=millis();
cam.read();
}
// start/stop camera preview by tapping the screen
void mousePressed()
{
if (cam.isStarted())
{
cam.stop();
}
else
cam.start();
}
void keyPressed() {
if (key == CODED) {
if (keyCode == MENU) {
if (cam.isFlashEnabled())
cam.disableFlash();
else
cam.enableFlash();
}
}
}
the time for every frame capture is
so 7 fps approximately (this is on another phone.)
It doesn;t matter how efficient and elegant the tracking / drawing code is. If you preview 7fps you cannot work as you should. You would be processing the same frame many times.