LiveCode Forums.

here's what i see.
The exported snapshot is on the right.
That is what is analyzed.

Jimi.

Ah, OK.

Now I see what is going on. The handler finds the robot on the grayish field. It is a demo of the "byteOffset" method, not finding a green pixel in a gray background. I assumed that latter, erroneously, when I first ran the thing.

Craig

But it seems odd to me that the stack works as well as it does, in that the robot is green, and I see no such green, nothing even close,

Perhaps?
https://www.colourblindawareness.org/co ... blindness/

jiml wrote: Fri Nov 11, 2022 11:30 pm here's what i see.
The exported snapshot is on the right.
That is what is analyzed.
myrobot2.jpg

Nicely done, Jim. Ajperks will find this very helpful. Thanks for putting that together.

@ Jimi.

I jumped to that assumption because the original intent of the OP was to set a robot moving around some sort of image. It occurs to me that not just any image will do; there must be pixels with the proper backColor sprinkled within the extent of that image, or the robot will never stop moving. It will never match any image pixel's backColor.

@ajperks.

Do I have that right?

Craig

The exported snapshot is on the right.
That is what is analyzed.

OK, now I think I am missing this entirely.

If the exported snapshot is "analysed", as Jim says, then matching pixels have to be sprinkled liberally throughout the target area of that image. Or at least one such pixel has to be. Otherwise, how does the "green" robot match the RGB value of a pixel in a field that contains no such green? However compact and clever the byteOffset method is, where is the match?

Craig

Sometimes I astonish myself at my inability to see the trees.

I woke up in the middle of the night... "You idiot!"!

The green thing on the left is the (missing) green thing that the fabulous new method locates, setting that loc for the green thing on the right.

I did not delete all my later posts here as a lesson, and warning, to to others: Now and then, stop and thnk.

Idiot.

Craig

the original intent of the OP was to set a robot moving around some sort of image

Has this thread gone OT, or is it just me?

Why does the OP's original posting make me think of some books I saw in the United States called "Where's Wally?"

Which, oddly enough, turn out to be English!

If that is what the OP was getting at, the problem is NOT one of pixel detection, it is one of detecting
an image embedded inside another image.

https://www.geeksforgeeks.org/wheres-wa ... g-mahotas/

Possibly the title should be changed to 'How can an image be searched for?'

Here's my understanding of what the OP is looking for:
- -
and a script should locate the orange blob, which is, by the way, 24 x 24 pixels of a uniform colour.

Obviously to do this should be exponentially easier than finding 'Wally'.

Why does pixelColor NOT show up in the LC Dictionary, and shows up as an error in the scriptEditor?

https://www.cnet.com/home/kitchen-and-h ... t-vacuums/
- -
"Here's a coverage photo of the iRobot Roomba S9 Plus as it moved through our test room. You can see the Roomba S9 covered the floor well, except for one slight section in the center (left, bottom)."

@ Richmond

I invented "pixelColor" earlier in this thread. I think that is why it is not in the dictionary.

Otherwise, you make a point, in that if the robot is a control of any type, or contains within it a control of any type, one could detect when the robot control intersected the "background" control. In other words, why use the backColor of pixels at all? One reason is that a single pixel, if that is the designated "target", can be very precisely located. But controls can be pretty small themselves, in fact, one pixel in size.

@ ajperks,

What exactly is this robot guy made out of? Why can't the robot contain a control of some kind, as snmall as you like, and the target be another control, again, as small as you like?

All the color stuff and ByteOffset method, however lovely, goes away.

Craig

-

One would hope "all this" is 100% unnecessary as any robot half worth its salt
should:

1. Calibrate itself (or be calibrated) against whatever space it is working within.

2. Broadcast some sort of wireless/bluetooth signal of its relative position.

https://www.researchgate.net/publicatio ... ning_Robot

https://patents.google.com/patent/US9038233B2/en

ajperks wrote: Sun Nov 06, 2022 6:06 pm I need to search an arbitrary image, let's say the screen or a JPG for the specific occurrence of a coloured pixel or mousepointer or simple shape and report it's x,y position.

I'm sure he means to track a color or shape captured in an image, because that's what he said.