Ha. Mostly got fingers pointing at the cursor, except once I got someone doing the Vulcan salute (fingers split), with my cursor in the middle. (Which reminds me of the joke about statisticians going deer hunting: they see a deer and both fire. One shot goes a foot too high and the other goes a foot too low. They shake hands and say "we got him!")
I agree, it's a legitimate question. I tried to search for a bunch of them on TinEye to see if I could find some original source for any of them that might indicate a licence, but none of the ones I tried came up with any results.
Very possible it's pictures the author of this tool took personally, which would explain why tineye doesn't know about them, how the author found them, and how they had the patience to annotate them all. Also, best to just assume copyright is all good, it's not like these photos are of military secrets or anything, no need for us to step in, I'd think.
Actually, I was expecting that too. As I clicked this page, I had a recollection of learning Pascal and C on very early versions of MacOS (like 5.0 and earlier, circa 1985). In those early versions, when you called the MacOS version of malloc(), the OS would give you a double-pointer to the memory you just allocated.
The reason for this is so that the OS could move around memory allocations to make efficient use. (This was obviously before Macs had virtual memory.)
There were some rules in these early versions of MacOS about which MacOS system calls could cause the pointers to change.
If you ALWAYS used the double pointer (and used the 'volatile' keyword or its Pascal equivalent appropriately), you were always safe. But if you kept a single-pointer version of a double-pointer from the OS, and then used certain OS calls, you might find that the OS moved your allocations around you behind your back.
As a seasoned system software engineer, this completely makes sense to me. But as a teenager trying to understand software, this completely blew my mind and I wrote a lot of code that crashed in strange ways.
Back in the early days of Mac programming, they had handles, which were pointers to pointers. The memory management would move around blocks of memory, and update the second pointer. That's what I was hoping for.
The find-the-closest-finger algorithm was taken from another project we did, where we needed much more speed. We use a voronoi diagram with a distinct color for each point.. then we can get the pixel color at the position of the cursor and find the related pointer..
This is actually much faster than what you see happening on Pointer Pointer. We introduced a pause to force people to wait, thus making it a more rewarding experience when the image finally shows up. A touch of magic, you could say.
Does anyone know how this was implemented? It's a great example of a case where, as a computer programmer, there are still problem domains which I have absolutely no idea how to approach!
It loads a json file [1] that contains the co-ordinates of the tip of each point and the corresponding image. It uses this to create a Voronoi diagram [2] using a "custom Javascript implementation of Steven J. Fortune's algorithm" [3].
Another cool thing is it appears to scale/move the image to match the desired point, at least in some cases.
Try moving your pointer around to different positions very close to the top right corner. This triggers a picture with a wristwatch and water bottle. The pointing is done by the right hand, which if your pointer is too far right is cut out of the frame, but becomes visible as you move towards the left.
I was just about to mention this; the same thing happens in the lower left corner (woman pointing, with two men in the background, one holding a beer can and wearing an 'enjoi' hoodie). The picture gets moved so she's always pointing at the cursor on the y-axis.
30 seconds guess: Author got hold of a large set of photos, analyzed for raised fingers with computer imagery.
Then author probably split the 960x680 px rectangle into a grid of small squares. Located the finger in every photo and assigned each of them to a specific square.
From there on it's a matter of finding the pointer in javascript and a Voronoi search to the matching photo. I'm not seeing an ajax call in the logs so there's probably a bit more magic going on clientside.
I would imagine that there is a catalogue of images, and the location pointed to stored for each image. You could manually tag 100 photographs quite quickly I'd imagine.
For a small number of photos (up to a few thousand), a linear search (i.e. check against each one) would be quick enough. You could compare the distance of the pointed spot to the cursor (using Euclidean distance), pick the best one, maybe add in a random factor.
EDIT: Somehow the author is putting Voronoi diagrams into use. Take a look at the source.
Haha, this thing is hilarious. Great job. I wonder if the author manually went through images locating the finger or there was some automated way of doing it. I did notice that if you move the pointer is certain ~20x20 areas the same picture appears. I'm guessing the set of images is small enough to just manually do it.
If the image resolution software isn't good enough, and there's a lot of images, you could mechanical turk it using the reverse site. Show on image and have the user click on the finger (or none).
A small glitch? Some points outside the right border don't load any image, though it still shows "Pointer located. Pointing...". Anybody else going through same problem, or am I the only one.
Look beyond the funny app. Think of the challenge of finding an efficient solution to the original problem regardless of its "unseriousness": finding the optimal picture according to pointer position.
