Android Question move camera position x y change

True. But what if that pixel is a anomaly?

I suppose one could do a 2D binary search for the dot.
A count of # red pixels as the criteria for deciding which halves have the dot.

Although counting red pixels requires looking at each pixel, just like finding the centroid.
The centroid calculations will sum the locations (much the same as counting).
At the end of the loop the locations are averaged to yield the centroid.

11 milliseconds is pretty fast for 600x600, don't you think?

I can see that once a red pixel is found, one could do a small sub search, say 10x10 to make sure its not an anomaly.

Another approach might be to capitalize on the size of the dot.
Say it has radius 10 pixels, then we can search the image looking at every 10th pixel first.
If is red, do the mini-search, if it is an anomaly proceed with the same main search.

I will do some testing. It looks like the algorithm can be improved.

In practice, since the goal is to see if the dot moved, we could start at the last known location.
In that case I would do a radial search (around the clock in angle steps from last known - distance stepping at delta = dot radius.
If not found, then narrow angle step size. Just some ideas.

Motion estimation could help.
I tested your code and found that if we change sumx, y and N to int type and remove ceil funtion it can speed up, stange.

If the radius of the dot is 10, I can reduce the time to by taking 5-pixel steps through the image.
And combining this with using integer arithmetic, the time per search is now 1.5 msec. This is probably satisfactory.

The radial search has a lot of overhead (Sine and Cosine) calculations, so it is too slow.

I could not get the time down easily until I removed the bc.CopyPixels line out of whereIsDot. That brings it down to .088 msec
So there is where the computational burden is.

It would be better to get the pixels directly from the Camera2 bitmap, rather than using BitmapCreator.


So I'll await the results from an example using the camera.

William Lancee said:

The radial search has a lot of overhead (Sine and Cosine) calculations, so it is too slow.

Click to expand...

Can we use rectangle search? a little bit more pixels than radial but save sine and cosine.

Yeah I think copypixels and getArgb could be the bottleneck. Use real camera usually the camera sdk allows to access image pixels in memory directly so save lots of time.