My solution to the problem, I don't need barcodes, I just take a photo for each item when it is sold. Then I can apply AI technics to recognize and classify the photos. Then I would be able to know, say, how many pants, tops or skirts I sold each day.

As an example of an image recognition system: this link describes a traffic-sign recognition system. Note that traffic signs are designed to be easily differentiated. This thing will recognize 3 signs a second and has 98% "recognition rate" (which in my estimates is much worse than the usual barcode scanner at the super market)

I can just see the hours it took to trace down the bug, "why you bought 500 bikini bottoms instead of jogging shorts" , due to the sunlight angle at 3PM on cash register #3.

every day we will renew hundrads sold items

how many hundreds? 200, 300, 400 or 500? at what photo quality? 640x480, 24bit makes roughly 100kB. That's a lot of data to pass around, when 256 Bytes for each item would be enough to provide a unique identifier to each item you sell in the entire lifetime of your shop.

Sum up the time for taking and postprocessing the photos: you'll miss that at some point.

If you delay processing, you have ~200MB of raw photo data per week, selling 400 items a day, 5 days a week - your hardware shop will thank you for your approach...

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Hi zli034,

Using AI techniques to recognize and classify the items of your store is a bad idea. There are so many challenges to be solved in your particular application that the computational cost and the training required of your personnel will be many times higher than using an alternative as putting bar codes on the items. Just to give you an idea of the challenges, lets focus only on the shape matching part (even though, you already mentioned that you also need to match for color). Here you will have a number of challenges: your system has to be good enough to be robust against changes in orientation, occlusions, and deformations. To minimize the problem, you have at least two options:

1. train your cashiers to place the item in the same position every time, to adjust it to have a certain shape that will be easily recognized, and to avoid getting in the way of the camera. This will involved a lot of training. You could check the challenges associated with image guided surgery applications (for that, you would need to do a Google seacrh) to have an idea of all the problems of solving this type of problems in real time (you will need real time unless your customers are willing to spend a lot of time at the cashier)
2. develop a state of the art algorithm that can do the shape matching in real time (for the sake of your customers), has a 100% of accuracy (for your own sake) and is robust against occlusions, changes in light conditions, deformations, and changes in orientation. If you succeed in making such an algorithm, you better patent it because you cannot imagine how valuable it would be.

In short, you better go with the bar code solution or with any solution that involves identifying a small identifier that you put on every item.

Please, let us know if you have another question.

Cheers,

Heh - well, if nothing else, your intended approach embraces the 3 virtues of a perl programmer...

Beyond what others have said, it's worth mentioning that you are not required to bar code every item - a catalog of items with their bar codes at each till might be a better approach - particularly if your 2000 items are actually 100 items in 20 different colours (i.e. maintain bar codes for the 100 items with separate bar codes for the colours).

map{$a=1-$_/10;map{$d=$a;$e=$b=$_/20-2;map{($d,$e)=(2*$d*$e+$a,$e**2
-$d**2+$b);$c=$d**2+$e**2>4?$d=8:_}1..50;print$c}0..59;print$/}0..20
[download]

I studied Pattern Recognition under Ed Jernigan at the University of Waterloo, and I gotta tell you, it's tough slogging -- quite the fascinating subject -- but tough math.

To me, this sounds like a solution looking for a problem -- I think you need to stop and think about what problem you're trying to solve. If the problem is inventory control, it's probably a piece of cake to make up a dozen or so types of tags, one type for each piece of clothing, a sort of apparel taxonomy. You don't care what colour the sweater is, but you care if it's a sweater or a parka. So just go from there.

Or maybe it's some other problem you're trying to solve ..

I applaud your effort, and actually the fact that you've gotten as far with it as you have. I'm impressed.

But your strategy is flawed. Point of Sale has to go as smoothly as possible. Any slowdown at POS will cost you sales. There is no way that you can take a controlled picture of sufficient quality to guarantee image recognition accuracy faster than you could jot down a six digit number, and even worse, your salespeople or clerks aren't going to be even half as careful as you. This is especially true when they've got a line of frustrated customers at the counter, impatient over the notion that everything they buy has to be photographed carefully first. POS slow-downs are one of the biggest No No's in the retail environment.

If barcoding is too expensive to implement, at least just generate sku's. Printing sku labels isn't terribly difficult, and that will make inventory tracking simple, efficient, and in keeping with what clients and clerks are accustomed to.

That doesn't mean the project doesn't interest me. It really does. But the purpose for which you're applying the project is not ideal, imho.

First, I agree with the many others who have said that this is the wrong approach to the problem (and I have to wonder if this is what you were posting about last week).

Second, it might have been helpful to link to the code you're cribbing, since there's a better description there of how this technique works.

Third, I wonder about the utility of looking at the mean or standard deviation of an image's resulting vector. Imagine an image that is half black and half white and another that has the halves reversed. They're as different as night and day, but they have the same mean and standard deviation. If you had so many images that doing all the comparisons becomes a chore, narrowing your search using these values might be useful (or it might not), but you don't seem to have that many.

Finally, you might want to look at earlier nodes dealing with image recognition, such as Comparing images.

barcodes - I know the initial time expenditure does not look good to your immediate needs, in as much as the training and potential equipment additions to your business. But the long term benefits should far outweigh any time spent upfront in the process, while digital photos will more than likely continually create new and unique opportunities to have to work on process modifications as products change in any number of unanticipated ways down the road.

If you take a week or so now for development / training, you can cut your handling time over the long haul immeasurably, saving you time and money. And besides, I have never bought something and had to hold it up for a photograph! I don't think you want that kind of marketing word of mouth, do you?

Good luck

If you'd used Perl6 though this would be a snap, isn't that right monks?

fine. i can't help but think when i write. here's something useful: I bet all the labels or the tags on your merchandise have more intricate patterns that maybe you'll be able to more reliably "parse". Say, a shirt, snap a picture of just the label up on the back of the neck, grab a little background of the shirt too (in case you have a few shirts with the same labels). That image should result in some "hash", which you'd be more likely to get back when you snapped the shirt's label again later, since there's less "complications" in that picture. In other words, the label changes less as you fling the shirt around in real life (shirts get wrinkled and have different colored tables or objects underneath them, etc). I think the "value" in this idea boils down to: don't snap a picture of the whole object when just it's most unique tiny patch of the object will do. I'd imagine that from picture to picture, there are fewer differences when you deal with smaller areas. Of course that's almost exactly what barcodes are.. a whole bunch of unique 'areas' to affix to your, otherwise identical, crap.

And let us know how this turns out, you crazy merchant