Talk:High Capacity Color Barcode

Software Reading/Writing HCCB?

It would be nice to have a list of software or web services that read or write HCCBs, for example, what software was used to generate the code in the top right corner? — Preceding unsigned comment added by 97.125.0.180 (talk) 00:51, 30 July 2011 (UTC)

Article should be seperated

There should be an independant article on Microsoft Tag. It should not redirect to this article. —Preceding unsigned comment added by 12.107.188.5 (talk) 00:00, 27 October 2009 (UTC)

I agree, or at the very least there needs to be more information on this general topic. Having an article called "High capacity color barcode" that talks almost exclusively about Microsoft Tag makes as much sense as if Video game console talked mostly about the Xbox. --LarryGilbert (talk) 01:14, 12 December 2009 (UTC)

Actually, the more I read about this, the more it really does look like it's a Microsoft thing. Whether or not the general concept was invented by them, they seem to have been the ones to coin the term "High Capacity Color Barcode." Furthermore, Microsoft Tag appears to be just one of several applications of this. So I think it may be appropriate to keep Microsoft Tag here, but the article should expound on the other applications like ISAC some more. --LarryGilbert (talk) 20:21, 12 December 2009 (UTC)

The entire article should be renamed "Microsoft Tag" and the HCCB section should be moved into "technology" or somesuch. —Preceding unsigned comment added by 12.107.188.5 (talk) 05:39, 26 January 2010 (UTC)

This article should be "Microsoft Tag" or simply "Tag" and "High Capacity Color Barcode" should redirect to "Microsoft Tag" or "Tag". — Preceding unsigned comment added by 12.107.188.5 (talk) 12:44, 20 July 2011 (UTC)

Can a verified account-holder please make the move?

How to accomplish this is detailed here: http://en.wikipedia.org/wiki/How_to_rename_a_page#How_to_move_a_page — Preceding unsigned comment added by 12.107.188.5 (talk) 12:46, 20 July 2011 (UTC)

Chromocode comparison

Removed the Chromocode for a couple reasons:

Firstly: Infinitely High Density is complete hyperbole and vastly misleading. he idea of encoding a reference to a document in a barcode does not suggest anything about the density of the information storage in the bar code symbol itself. When someone talks about "density" in regards to barcodes, they generally are referring to data stored in the barcode symbol itself. Even with a reference to a document, depending on the storage backing it, it may be quite large but it cannot be without bound until a limitless supply of energy is tapped.

The other thing is that this Chromocode is a horrible idea and just because it has a patent does not make it a workable technology. The chromocode specification/patent uses a relatively "huge" number of colors which makes distinguishing colors with typical optical technology quite difficult. The problems with even tri-color barcode when not printed with spot color has been demonstrated many times which is the very reason that color barcodes have not caught on in the industry. It is also clear that the "inventor" of the technology doesn't have a clue about basic robust data encoding principles as they have simply mapped colors to ASCII values. There is no thought to forward error correcting code or other integrity checking mechanisms that are a necessity in any modern 2D barcode and become even more important when color is brought into the mix. —The preceding unsigned comment was added by 72.90.74.160 (talk • contribs) 07:58, 30 May 2007 (UTC)

---

Just some points of clarification:

The Chromocode reference shows one embodiment that uses many colors, another that uses only four colors plus black. Four colors is not a "huge" number of colors, and is actually less than the number of colors used in the Microsoft barcode.

Chromocode also shows a self-calibration mechanism to handle errors. Meanwhile, conventional error-checking mechanisms (i.e., check digit) are not supposed to be repeated in patents; patents are to show new things, not old things.

Finally, the Chromocode reference says "virtually unlimited", not literally unlimited, and there is nothing misleading about the statement because it is true that the code is virtually unlimited.

Basically, the anonymous writer below does not seem to have read the Chromocode document before deleting it from the article. —The preceding unsigned comment was added by Wikiwikibangbang (talk • contribs) 23:49, 30 May 2007 (UTC)

---

Ok, fellow anonymous writer, you are wrong. I did read the document and the patent.

Firstly, four colors plus black? I see: "blue", "red", "green", and "yellow" and then also black and white.

Then there is this from the page:

Encompassing all 26 letters in the English alphabet and all 10 Arabic numerals, the VHD Chromocode high-capacity barcode symbology standard relies upon 5 colors (including black) and a background color (e.g., white).

I don't understand your method of counting. Is this five colors including black and white, or just including black. If I include black and white then it looks like there are *6* colors. In case you're not getting this I'll spell it out: 1. Black, 2. White, 3. Red, 4. Yellow, 5. Green, 6. Blue.

Regardless, from the standpoint of any machine sensor, that is *6* state, regardless of what you call them: shades, tone, bullshit, etc.

There are 6 states that have to be discriminated for a successful decode.

Now, this must be new math you're using, because I don't see how this is less than the HCCB symbology, which uses a very carefully chosen set of colors that help prevent the use of dithering on cheap printers. Regardless, there are only *4* colors/states for the symbol itself: a "Red", a "Yellow", a "Green", and "Black". And, OK, I'll give you white too, because in most applications a distinct (preferably light) border, or quitezone, is required around the border to facilitate easier searching.

You might learn something here: Notice that the border on the HCCB symbol is NOT uniform, this is to facilitate searching and orientation. Even with this, HCCB is not an ideal symbology in the search and orientation department. Look at the design of Data Matrix or Maxicode, QR code, or Aztec code to see how this is done for maximum decodability.

HCCB has an 8 color "version." But I have never seen this symbology used in practice and there is a great challenge in getting a cheap color camera with poor color resolution to read one of these. However the 4 color HCCB is used in actual practice.

You say:

"Finally, the Chromocode reference says "virtually unlimited", not literally unlimited."

Well, I admit I do not remember every last confusing thing said on your pages and patents, but I'll just quote this from the patent:

"The first of two alternative embodiments provides an ultra-high-density (UHD) barcode, symbology, method, device and system, thereby providing maximum information density--and in some cases, infinitely high density--but enjoying less tolerance for imperfection than the second alternative embodiment. "

For you dolts, it says: "...in some cases, infinitely high density..."

Not only is this hyperbole; unless you have broken the laws of physics, it is also completely misleading to those "knowledgeable in the art", or whatever you stupid lawyers call it. When I produce a "high density" barcode, I am speaking to the amount of information, in bits, actually encoded and readable from the actual symbol itself. I can encode a URL in a low density Code 39. Referencing an external entity stored on a completely external piece of media says nothing of the information density of the object making the reference. By your reasoning we should have stopped at floppy disks for data transfer because they are "infinitely high density" or at least "virtually." Hell I can put millions of URL on a floppy with a little compression. Amazing!

You say:

"Chromocode also shows a self-calibration mechanism to handle errors. Meanwhile, conventional error-checking mechanisms (i.e., check digit) are not supposed to be repeated in patents; patents are to show new things, not old things."

I said something about "error correcting" and "integrity checking" you dipshit. The self-calibration is NOT an error correction mechanism NOR is it even an error detection method. There is nothing mentioned about this at all in the patent or any other documents I can find. The "calibration" might help you somewhat in mapping sensor values to states but it will not tell you that the data you decoded is what was intended to be conveyed, printed or otherwise. If I whiteout or tear or otherwise "corrupt" one of the "blots" as you call them, how am I going to know this has happened? What is the integrity check? Also, what if the calibration square is corrupted? Then the entire symbol is unreadable. Also, this raises the question of how you bootstrap the calibration process in the first place. Because of the lack of any error correction or error detection not only are you prone to corruption of data (misreads) you are also prone to decoding patterns that aren't actually encoded symbols.

Also, we don't use a "check digit" in modern high density barcodes (or matrix codes...or stacked symbols), kid, we use some form of error correcting code. And error correction and error detection are not the same things, nor is either an absolute. However it is ABSOLUTELY the case that your demonstrate "invention" has neither.

I am not a lawyer, but I have been involved in a few patents and your claim that "conventional" or old things are not to be mentioned in patents is bullshit. Did I invent the CMOS or CCD image sensors, did I invent Reed-Solomon FEC, did I invent DMA or EPROMs? No. Does this mean that these items are not mentioned in patents? No. In fact, I doubt there is a single patent that doesn't reference something "conventional" or old in its disclosure. It's impossible. Unless you're going to technology that predates the wheel and rubbing two sticks together, any modern invention requires some use of existing technology. If your invention uses wheels (or "rolling devices", whatever), does that mean you don't mention them and remove them from the drawings because it wouldn't be showing a "new thing."

You say "virtually unlimited." But this is not true. Again, I, and I think many others will refuse to accept your redefinition of information density to include information that isn't actually there (that is, in the symbol, but is simply referenced by it.) In fact, if it's an external reference, then you can't even say anything about the density because that could be a reference to anything, high or low density.

There is clearly one thing here that is of "Ultra High Density," and that is your head.

Speaking of conventional and old things, why does your disclosure go to such great lengths about "Pantone" color matching. By your reasoning you should have invented color matching from scratch, not used someone else's system.

The color matching thing is a laugh. What difference does it make? If this is technology that will be usable by the average Jow with their cheap ass, possibly poorly maintained printer and monitor from hell, exactly what good does spot color and offset printing do them? Process color? What relevance does that have/

You can use the old lawyer shit trick of "well this is just one embodiment." but in this case it doesn't fly, because it seems like the technology is completely unworkable in any embodiment that would be practical for the everyday computer user to implement or use effectively.

The talk about color and CMYK is somewhat misinformed, along with the mention of conversion of RGB to CMYK and the mention of monitors. For one thing, it would seem to me that there is really little use in describing monitors in regards to this "invention." Who cares how the monitor displays it... What I'm saying is, isn't even more important how the camera or image sensor interprets it. I guess you can also talk about monitors and display, but if you can't *read* the damn thing correctly, who cares. RGB is not an absolute color space, and even a complete non-techie that has dicked around in Photoshop knows this. Moreover, the optics in modern inexpensive cameras that would typically be used in reading devices produce a number of issues regarding color resolution and acuity, that were clearly not considered in the disclosure.

If what I just mentioned isn't relevant to the patent, then why is the "equally" irrelevant mention of offset printing and process color mentioned. Or is it assumed that everyone that wants to use this will purchase spot colors for maximum density benefit??

And the claims:

"4. The method in claim 1 wherein said barcode is a sequence of blots, said sequence of blots being sufficient to symbolize, without any ambiguity, a sequence of ASCII characters that comprises more ASCII characters than there are blots in said sequence of blots."

How is this claim supported? What method do you use to prevent ambiguity? I'll guess that you don't. The color detection process by its very nature can lead to ambiguities. You obviously don't know how machines work, so I'll give you an example of a human. What if the human is color blind? Then the blots might not be unambiguous. The word ambiguous here is too vague, you give no context or environment that supports an unambiguous symbolization of ASCII characters.

Oh and again, you refuse to mention the use of "check digits" because that is "old" or conventional, but ASCII, that is "ASCII" is mentioned numerous times in the CLAIMS. Is ASCII new to you or something? Geez you're a moron. The only reason I am so nasty to you is because you accused me of "not reading the Chromocode documents," when obviously I made at least a mild effort. Dumbass. Now I wonder if you actually bothered to read the damn documents. The reason I ridicule the whole ASCII part is because the idea of encoding those 4 block symbols to 26 letters and "Arabic" numerals, or mentioning ASCII is a complete joke. Barcodes are bits, nothing more. A barcode itself does not suggest a particular encoding. And ASCII of all choices. You do realize that ASCII is not used in most Internet applications. At the very least ISO-8859-1 or UTF-8 or something a little richer than ASCII is used.

What was that again about not mentioning "conventional" or "old" technology?

You'll mention in the claims a specific character encoding, but the "check digit" or ANY error detection mechanism is off limits? Pfft.

The reason I mentioned the encoding thing was actually this: I said that a "barcode itself does not suggest a particular encoding." Well actually I lied. Most symbologies are based on some method of data compaction. For example, they contain different "shift states" and a particular element in a state can be encoded in 4 or 5 bits, as well as an octet state (called BASE256 is Data Matrix). That is why most matrix symbologies can store more numbers than letters in a given area.

Which brings me to this. You are deluding yourself if you think the data density of the invention comes even close to that of the well established codes (the monochrome ones). Your stupid color code can't match them.

As an example, using an unpatented, public domain, monochrome symbology I can encode my version of the Gettysburg Address, which comes to 1440 characters (the majority of it is lowercase and spaces so the bulk majority is 5 bits per character). This fits in a 10.3 cm^2 area with a comfortable mil size (~6.7 mil) (6.7 mil is a whole number of 600dpi print dots) (with high density readers and better printers you can go much smaller) -- It's 190x190 black/white elements. Additionally the Error Correction level is 28%, which means that roughly 290 erroneous (due to image sensor noise, specular reflection, poor exposure, print quality issues, physical damage to the symbol, etc). characters can be corrected. Also the statistical likelihood of any erroneous read is extremely tiny, since there is no singled check digit: essentially 28% of the symbol both allows for the correction of errors and verification or error detection. When the reader scans, if the bitstream doesn't compute properly, then it discards the symbol as garbage and does not waste your time with incorrect data. You can verify this experiment with any of the open symbologies: QR, Data Matrix, or Aztec all have similar density capabilities for this example.

Additionally in this 190x190 symbol is a number of topological features that make the discrimination and location of this symbol in a busy image and the orientation of this symbol within the image very straightforward and reliable. Your disclosure has no such provisions. There seems to be no thought given to how an actual implementation of a machine would read these things. Given the cluelessness of the disclosure I have little faith that a viable method has been found and is kept as a trade secrets. I'll believe it when I see high performance chromocode readers that can read symbols at 6-8 mil per element.

The calibration square from a topological standpoint is not distinct enough to allow easy orientation or location. If you disagree, at least I'll argue that you are making it too difficult.

Your scheme doesn't look like it can reach this density. SO even if we ignore your idiot computations of density from linked material you are still lying when you say: "[0146] While the information density of the UHD-IHD code is unrivaled,..." (* actually I don't believe you are a malicious liar, you're probably just an idiot). Please give me details of how you would do this exercise I mentioned above. Obviously you would need to use a matrix of these "blots" and now you have to explain to me how I can reliably orient this thing and read it in the prescense of skew, mirroring, damage, etc. All problems that have been solved by prior art and give excellent results. If you just for a minute were not convinced of your own genius and actually bothered to pay the $100 fee to buy some AIM specs, you might actually learn how a successful, highly effective symbology is constructed.

One thing you have to ask yourself sometimes, when you think you have innovated something, is this: "Why has no one thought of this before?" You must know that high density error corrected Matrix codes have existed for years (have you never received a UPS package?). Wouldn't you think one of the most obvious things to do would be to print these things in color for a density boost? And of course it was. Color Data Matrix has existed for years. Color anything has poor adoption because: The density gains are usually not as staggering as better encodation and compression methods of monochrome barcodes and the hassles in printing make it more trouble than it is worth in most cases. Although the problems and risks of color printing can be managed, it is a much greater headache than using cheap shit monochrome printers (cheap in terms of both equipment, consumables, and maintenance). Most warehouses, tickets, etc don't need to encode a lot of data in the symbol.. because (surprise!) they usually are keys to some external database. You can store 2000 letters or 3000 digits with plenty of error correction with a small monochrome code, and this is generally plenty. See the back of your Driver's License? Everything on the front is on the back, and error corrected too. The possibility of a reader corrupting the data is very slim, if the symbol is beyond repair it is vastly more likely that the reader will detect this and signal an error (or simply refuse to read and "beep"). It is more likely that a random memory error will occur. Would you please demonstrate how your stupid idea with calibration or not can achieve these features we have taken for granted for over 15 years?

Just looking at your table assigning punctuation equal "weight" with letters and numbers seems silly. Also, there is some suggestion of storing XML. Only an idiot would store XML in a symbol. XML is not an efficient means for data storage. If you have a given area for a "barcode" (matrix) symbol you are better off compacting the data as much as possible and using the rest for as much redundancy (in the form of FEC) as you can.

So that raises the all important question.... What in the hell is innovative in the claims of this patent? The idea of much higher density error correcting, secure (that is the term for low likelihood of misreads... has nothing to do with encryption in this context), encoding that works very well can be read in all orientations and with a number of distortions and graphical corruptions (and most likely a hell of a lot better than this nonsense) has existed for years, and the use of color for these things has too. None of this is new stuff. The various methods for data compaction have existed and are published. YOU MAY HAVE SOMETHING. I'm sure that your published claims for encoding are previously unpublished because they suck so bad that no one would bother with them.

Also, URLs in a symbol.. If you can't turn up a successful google search on this you are really in trouble.

Go read a book and learn something...

And finally... If you still disagree with me, which is fine, then please keep your hype filled advertising bullshit off of the HCCB page, or any other specific barcode symbology page. If you like, create a Wiki page for your damn invention and let it stand up on its own merits. I don't even think a specific link in the See Also belongs here, but I'll let that slide, however some bullshit about: "Even HCCB can't compete with XYZ which was mentioned in the InventNOW Morons!..." or whatever that was about.

Find another forum for your stupidity.

I have good friends that are lawyers so I don't personally stereotype, but if you wonder why lawyers get a bad name (unfairly or otherwise) then please look in the mirror. —The preceding unsigned comment was added by 63.240.121.145 (talk • contribs) 21:56, 31 May 2007 (UTC)

---

I don't think the profanity and ad hominem attacks add anything to the discussion, and it does not comply with the [talk_page_guidelines]. The Chromocode IDS cites about forty patents or other documents re: barcode functionalities you discuss and would therefore not need to be repeated. —The preceding unsigned comment was added by Wikiwikibangbang (talk • contribs) 17:47, 1 June 2007 (UTC)

---

While the profanity and personal attacks were not appropriate, I agree with the anonymous contributor(s?) that the Chromocode comparison does not belong in this article, per policy against original research: "An article or section of an article that relies on a primary source should (1) only make descriptive claims, the accuracy of which is easily verifiable by any reasonable, educated person without specialist knowledge, and (2) make no analytic, synthetic, interpretive, explanatory, or evaluative claims." I also feel that it violates neutral point of view: "All Wikipedia articles and other encyclopedic content must be written from a neutral point of view (NPOV), representing fairly and without bias all significant views (that have been published by reliable sources)." The inclusion of the comparison implied a recognized inferiority that is not supported through the given sources, and which was not helped by peacock terms such as "far behind" and "virtually infinite". Chromocode also does not seem to be a very well-publicized technology, and patent application document does not in itself establish its viability. I think you should also note Wikipedia:Conflict of interest, as you seem personally invested in the work of Shelton Harrison, adding content without much regard for establishing notability or saliency. Dancter 19:58, 1 June 2007 (UTC)

---

If the Microsoft code is notable and salient for its high capacity, then a competing code that offers higher capacity would also probably be notable and salient. Generally, reference to a competing point-of-view increases rather than decreases the neutrality of an article.

If the MS code is, however, notable and salient simply because it is Microsoft's or for some other external reason, then the article needs no reference to other codes.

Also, please note that NPOV is a criterion pertaining to articles, not individuals, and the discussion would move forward more effectively if it pertained to the article supposedly being discussed. —The preceding unsigned comment was added by Wikiwikibangbang (talk • contribs) 21:52, 1 June 2007 (UTC)

---

Presumably, HCCB is notable due to the nature of coverage for it (see the notability guideline I linked to in my previous post). Note that the guideline makes a distinction from "importance". High-profile companies such as Microsoft do have advantages in attracting notice for their products and technologies, but the same standard is to be applied to all such subjects, regardless of who is involved.

Whether the content in question meets the criterion of "significant views (that have been published by reliable sources)" has not been established; as I can find no evidence anywhere that HCCB and Chromocode have been mentioned together in a reliable publication, let alone compared. From what I can tell, the whole question of HCCB's storage capacity in comparison to other technologies does not seem to have been deemed salient by the sources that have covered it.

My mention of WP:COI was more of a general advisory comment, rather than an argument pertaining to this issue. I thought I had laid out the arguments pretty clearly before that. Dancter 02:32, 2 June 2007 (UTC)

---

Since posting the above comment, I have learned that a number of my other contributions, dating back to 2006, have been deleted from Wikipedia by the above participants. I think this kind of vindictive behavior is contrary to the Wikipedia mission.

In particular, the vigilantes participating in this discussion should take a look at Crimes Against Logic by Jamie Whyte. This book discusses at length the nature of ad hominem attacks.

For instance, Whyte uses the example of Hitler to prove a point: Hitler may have been a horrible person, but if you asked him if Berlin was in Germany, he would have said yes. Which is a true statement. Berlin is in Germany, and even Hitler would have known that much.

Meanwhile, if I am the horrible person that the other commenters think I am (and I haven't murdered a few million people, mind you!!), I am still capable of making a true statement.

That's why ad hominem attacks are invalid. And ad hominem attacks appear to make up the bulk of this discussion, as well as serving as the basis for vandalism of my other contributions to Wikipedia.

The whole discussion has called into question for me the validity of Wikipedia as a source. There are probably a number of other contributors who have been subjected to profanity and other vigilante behavior whose contributions were nonetheless true and relevant statements. These people have probably left Wikipedia altogether, which diminishes the validity of the information remaining without them. —The preceding unsigned comment was added by Wikiwikibangbang (talk • contribs) 01:37, 2 June 2007 (UTC)

I apologize if my removals had been perceived as vindictive and unfairly prejudicial. I do risk opening myself to such arguments when I do such bulk reversions, but I did review each edit individually, and judged each one for the most part on its own merits. This can be discussed on either your or my talk page, as it this is somewhat peripheral to this discussion. Dancter 02:32, 2 June 2007 (UTC)

---

Ok, I am one of the above participants. I am not signed in, so don't bother looking at my contribs to determine what I have written. There is a contrib under this IP address made in Jan 2007 in the West Genesee High School article that is quite inappropriate, and I had nothing at all to do with it.

I am not a vigilante, and I don't need to be told what an ad hominem attack is. I did not produce an ad hominem argument. I even admitted to why I was particularly offensive toward you. However this was simply scattered in between pieces of the argument. While not directly, it seems you are using the term vigilantes to make an ad hominem attack by trying to discredit the entirety of my post, and others' comments. The accusation of ad hominem on my part is a red herring because there were simply some personal attacks but they were not there to support the points of the technical argument. I simply don't like you, because it is obvious that you are Shelton Harrison and it is obvious that you are a spammer.

Most of my post did actually bother to point out why your claims were inappropriate, unsupported, dubious, or fabricated. For one example, I dismissed your claim that the calibration was a form of "error correction" or "error detection." I called you a dipshit after that, but that was not meant to signify anything more than derision. I asked how your system would handle corruption and orientation issues. There's no point in ignoring the technical points.

You said:

If the Microsoft code is notable and salient for its high capacity, then a competing code that offers higher capacity would also probably be notable and salient. Generally, reference to a competing point-of-view increases rather than decreases the neutrality of an article.

Well I read the HCCB article again, and I will FULLY agree that it sucks rocks. It is short on details and makes generalizations, and I will fix it when I have the time to do the necessary research. However it does bother to give a figure of 3500 chars/sq in. Granted this is at a mil size not mentioned in the article. I have samples at work and will have to measure them. The mil size is typically fixed, so this is the case of missing information on the Wiki, not an outright fabrication.

I will agree that if there is a competing code that offers higher capacity it MAY (only MAY) be notable and salient here. However, the code has to be: Competing, and: Higher capacity. When you know of one, you can put it here. Competing means that there is actually a means (proprietary or otherwise) to produce specimens of the symbol with data stored within it and preferably some actual exposure in the marketplace. You provide one specimen of VHD, it seems. The word "EPOET" in all caps, which is clearly not demonstrating any higher capacity at the mil size used by HCCB. You have demonstrated that you are either misleading or knowingly trying to lie by playing semantic games with the word "capacity."

HCCB is not notable and salient due only to its capacity. Don't let the name: HCCB fool you, that just happens to be its name. HCCB is notable due to its industry acceptance and licensing agreement. The fact that it does store some more data (about double) is notable but not so much.

From this article it is not even clear what the true capacity in the general case of HCCB is! Unless you somehow know what it is, then how in the hell can you conclude that yours is higher??? Your specification does not give any practical density figures (like chars/sq in). Also understand that chars/sq in is not a good measure. When comparing one symbol to another it is better to use bits/sq in. Characters are ambiguous.

I will agree that HCCB needs some work, but your spam doesn't help, it just hurts.

On a side note, I have had contact with HCCB designers because of the symbols obvious limitations, and we have pretty much confirmed that they have little interest in extending outside of the media marking domain. HCCB is actually not a great symbology for general purpose use, but not as bad as yours. And if you restrict yourself to media marking, like HCCB, I don't see the competitive advantage your method has. You will have to elaborate.

I am actually going to try to help you out here, and if you bother to listen you might be able to be a positive contributor to the Wiki. For one thing, you totally ignored my final suggestion, that you create an article describing the symbology in more detail rather than putting unsubstantiated claims on the HCCB, or any other page (or maybe you did, but continuing to bitch here about the merits of the Wiki isn't productive to that goal).

For the amount of money you might spend on patents you can: buy every single AIM spec for: PDF417, Data Matrix, Aztec, and QR code, and a reader from Symbol, Omniplanar, Intermec, or any number of other vendors to prove how well these things work, along with an encoder to see the actual information density available to you in these symbologies. You can also look up some information on Color Data Matrix, even though it is not an AIM standard.

Information Density: Information can be measured in bits (or related measures in other bases), a precise information theoretical measure of data storage or capacity. When specifying symbologies this information is directly provided in the spec, or can unambiguously be derived from the details of the specification. Additionally, most people interested in symbologies are interested solely in the information density of the symbol itself which does not include documents that may be referenced through data encoded in the symbology. For example, if you develop a symbology specification that is a single square with 4 possible states and specify that those states refer to a particular URL, the data at that URL does not have anything to do with the density of storage of the symbol. In the case of one square with 4 states the capacity is exactly 2 bits.

A 151x151 (22801) module Aztec symbol stores 19968 bits. Within that, there are roughly 2800 modules simply there for structural integrity and orientation including the "bullseye", orientation marks, and a "reference grid" that is used to successfully map any skew or rotation while tracing the entire dimensions of the symbol. If we use 23% of the symbol for redundancy (382 12-bit codewords), then we have 15384 bits for data storage. With this redundancy, 2292 of the elements in the symbol data can be destroyed and the data can still be recovered error free. The amount of redundancy in adjustable. The symbol at a comfortable mil (15 mil) size would be 6 in^2. Please demonstrate how your symbology can match this with bit capacity and element size specified and includes suitable orientation and geometric structures to make: 1) finding the symbol in an image possible 2) mapping the dimensions of the symbol to account for reasonable affine transforms and curvature. At the very least give a specimen that clearly illustrates features that manifest themselves when storing more than just "EPOET".

In your VHD on the page you use 36 combinations, which does help to allow maximum likelihood estimation of codeword. But what is the effective # of bits per element with this system?? Just over double the number in a black and white system. Not too impressive. Add to that, that on any given imaging sensor system, the minimum mil size I can use versus a B/W symbol is greater because the color resolution is typically lower. Your sample word: EPOET, requires a HUGE thing it looks like. I can encode EPOET in Code 39 13-mil (a simple LINEAR symbology and match your demo and it could be much shorter too and would have a check digit!) Just for kicks, encode some English Text around 1000-1400 characters with your system and put it somewhere. Explain how it stores that information allowing for: 1) error correction, 2) methods for finding the symbol and mapping its boundary and staying straight on the modules. I think if you do this, you will simply reinvent what already exists.

Your method only uses 36 points in a 1296 point space, so you have only doubled the density over B/W. We can do this today with current 2D symbols. People have encoded QR, Data Matrix, and Aztec with a few color combinations to get a little bit more density, and these symbols actually work. You have developed NOTHING new.

You show an example with 68 states "colors." That is just a tiny bit over 6 bits per state. This is not a practical or demonstrable "exponential" progressive increase over a monochrome symbol. It is just 3 times the information capacity of a single B/W element. Exponential would mean that you would have to triple this... that is you would need over 262000 colors per element for more density. I hope you understand what is required for "exponential" increases in data capacity. Saying "exponential" increases of course needs to show a progression with more than 2 points, which you haven't provided.

Now, I personally am not interested in 68 color systems, since they would only work with a high-res flatbed scanner or a good shot from a decent digital camera. Also, how many calibration patches are you going to provide? Using the primary colors of the printing device probably will not work because the way the reading device responds requires many more points for interpolation. You will find you will need quite a few patches to provide reliable sampling performance. Also, a calibration patch isn't going to help you read across the symbol if the light isn't very uniform or there is any dispersion or metamerism. The spectrum of the illumination is a severe limiting factor on the number of colors across the spectrum that you can use. Tungsten light, for example, will cause a lot of colors to "cluster" to one end of the spectrum.

Your whole idea of "calibration" is flawed since it can't cope in the face of non-linear transfer functions of color and it still can't make distinct "colors" appear when the illumination does not provide the necessary contrast between colors. And don't get me started about low light performance with color, contrast for one, and then imager noise and hand motion as exposure and gain increases for another.

The standard symbologies are suited for use in a wide range of applications, not just a flat bed scanner. And if you are comparing to HCCB you had better show me how it works with the resolutions typical of a color cell phone camera.

Color Resolution: The color resolution of virtually every inexpensive camera is relatively low. In a standard Bayer camera, only 1/4 of the pixels are red and 1/4 blue. In order to extract a wide range of colors from a cell phone camera requires a pretty good size image in the FOV, but this is counter to the fixed focus optics present in those cameras.

You will have a hard time convincing anyone that your "UHD" embodiment is workable outside of scanning from a mid end digital camera with focusable optics, a specialized camera specifically for the purpose (which of course precludes use for consumers), or a flat bed scanner.

Another thing, is that I dismissed your UHB for using a "huge" number of colors, and you simply said that was only one embodiment. Well, if you are going to make a claim for the UHB case, you have to acknowledge the huge number of colors, you can't try to redirect me. If you are trying to convey that the symbology using fewer colors can compete with a monochrome symbology then please address that.

What about the definition of colors? It is a fact of life that you will have to provide a "standard" set of reference colors in your spec. Letting "anyone" choose colors from anywhere will break down greatly if you actually want to print these things on consumer printing devices and image them on typical imaging devices. Let's use your table. So those colors look like "Web" colors to me, and I haven't the time to scrutinize them, but they are typically specified as RGB triples. Now then, which RGB space are you going to use? Do you even know if those colors will map nicely into the gamut of typical consumer grade printers? How do you control the profiling applied when these things are printed? That transform may be nonlinear and will vary. Then you have to scan those colors with yet another RGB (camera/sensor) space that is typically conveyed in some YUV space.

Are you starting to see why color coding has had slow adoption?

I have been working with decoders for matrix symbologies for a number of years now. So far I have had no trouble producing a decoder for a standard symbology (AIM is not the only standards body for these things, but it so happens that virtually all symbologies in current are available through AIM, at least). It is unclear to me how to encode a symbol with your documented scheme that would rival the information density in any of the well established methods.

Lastly: Even though I don't like you, and probably never will, that makes no difference. If you actually do successfully develop a symbology that improves the art, or seems to live up to the claim that it greatly increases information density, I will be among the first to support it. This is my field; I want nothing more than to embrace emerging technology with substantiative value. In fact, if you, or anyone manages to produce a well-designed code that shows promise for wide acceptance, I will probably be one of the people implementing a decoder for it. My personal hatred for you really has no bearing on how I interpret any technical or factual statements you make.

Rather than bitch about my vitriol, why don't you spend time cultivating your technical expertise in this area? Like I said, that will probably first start with you going off and reading for a while and come back when you learn something. I hope you understand that even though I am an asshole, it does not affect my ability for logical thought, nor does it affect my ability to listen to what others have to say.

It IS true that not all symbologies mentioned on Wikipedia have available specs, but in no case should those proprietary codes be allowed to make unfounded claims on another symbology page.

Your symbology is no more unlimited than any other, and in the case of the 2D symbologies THEY actually have graphical mechanisms to support growth that still allows them to identified and processed.

You say:

There are probably a number of other contributors who have been subjected to profanity and other vigilante behavior whose contributions were nonetheless true and relevant statements.

I don't think this is that common. What benefit do you think I get if I encourage someone with something worthwhile to go away? I may be a jerk to you, but I am not going to let that diminish the value of the Wikipedia content. I encourage you to improve the quality of the Wiki. Only a small percentage of my writing is insults. Instead of addressing the actual technical questions and criticisms you attempt to throw up a red herring. You probably have made a few true and relevant statements somewhere, but none on the HCCB page itself.

Your reference to Hitler is admittedly not a manifestation of Godwin's Law, but you are getting on thin ice. —The preceding unsigned comment was added by 72.90.74.160 (talk • contribs) 2007-06-02T19:04:04 (UTC)

---

I actually agree with many of your criticisms of the code.

One question that you haven't directly addressed: which of the systems to which you refer is self-defining in that one part of the code specifies a URL and the remainder of the code is decoded according to custom instructions found at the specified URL? That would be an interesting point of comparison. —The preceding unsigned comment was added by Wikiwikibangbang (talk • contribs) 2007-06-04T16:48:21 (UTC)

---

I'm actually not sure about access to a URI and then further interpretation based on remaining local data. The use of this would apparently be to prevent the URI from knowing what the remaining data was, otherwise you would just send all the data in the request. Anyway, this actually has nothing to do with barcodes. At the lowest level, a barcode is nothing more than a sequence of bits. Barcodes are defined as storage for arbitrary binary data with optional error correction. The actual way that barcode data is interpreted is not defined by a symbology standard, no more than NTFS or FAT define what kind of data you store in a file. You can implement a system with a URI and further processing instructions in a disk file, so it is not unique to barcodes.

The data you store in the barcode is completely arbitrary. You can implement any system involving data with any symbology. Typically, the best way to encode application specific "files" would be to use a magic number in the header of the symbol. There is an additional feature that the 2D codes have that is called ECI (Extended Channel Interpretation). This is simply an "escape" sequence to encode arbitrary numerical identifiers (with certain values defined by AIM). These were originally defined to specify the intended character set interpretation of the data, but for numerous technical reasons they are almost never used in practice. ECIs are typically expensive to encode in most symbologies because they usually can only be encoded one way, so if you use a lot of them, then you will get a lot of shift words. I wouldn't use them to delimit data. However, it is generally okay to use it as the first character in the code. ECI-compliant barcode readers will prefix ECI number sequences with a 5Ch (ISO 10646 backslash) and all literal 5Ch characters within the symbol will be doubled (escaped). In order to detect this, the reader sets a special value in the AIM Symbology Modifier value. These are just implementation details. ECIs are really just a standardized way to encode side channel information (inefficiently).

As far as IP is concerned in this area, with regards to Auto-ID, I am actually not too sure. There is a company called NeoMedia (NEOM.OB) that has a large patent portfolio they acquired from various sources. They are currently undergoing lawsuits and dealing with the EFF.

I am not an expert on what I've heard being called "convergence" technologies, but at their core, they are not a barcode symbology issue. You can put anything in any barcode (given space constraints obviously). And my point was primarily about information density (bits/area). Current symbologies provide well known density and are designed with efficient image-processing in mind, making surprisingly high density possible. Adding color can boost density a little, as long as the implementor is aware of the additional complexities involved. Multi-color barcodes are rare because most users do not feel the benefits outweigh the costs.

---

The 3500 chars/sq in is from Microsoft promo material for the 8 color version at a certain mil size (that I don't know) with "typical" English text (which influences the avg. bits/char). It really all comes down to element size and application. It is obvious that the "raw" bit density of a matrix code is simply (elements*element states)/area. So for 3 mil B/W, that is over 110000 bits/sq in. A certain percentage of these are overhead for graphical elements that make locating and orienting the code possible. Data Matrix uses all 4 sides for this at the very least, and uses more as the symbol grows. These structures are not there to waste space. They need to be there, or you will find that reading will not be very robust. Additionally, in general purpose applications, robustness will generally be very poor if there is not some amount of error-correction (efficient redundancy) to account for both imaging and printing. While a smart individual can find ways to reduce this overhead over current "state of the art", it can never be eliminated completely. In some cases, more clever compression methods might give higher returns with no risk (from a robustness standpoint).

more unsigned commentary from --72.90.74.160

---

It is clear that you are a logically talented person, which is rare and which really leaves me primarily wondering: why would you engage in debate techniques which you yourself do not consider legitimate?

—The preceding unsigned comment was added by Wikiwikibangbang (talk • contribs) 2007-06-06T19:00:03 (UTC)

105 bit?

Why is the capacity of a Microsoft Tag 105 bit? If I'm not mistaken, 4 colors represent 2 bit per element, and 5x10 elements are 50 elements per barcode. Resulting in 100 bit, but considering the last 4 elements are always the same (the palette), we only have 82 bit available. So why 105? Is there a source or explanation for that? —Preceding unsigned comment added by 77.2.43.231 (talk) 11:08, 14 May 2009 (UTC)

(I think you meant 92 bits available (100-8), not 82. Still that's only 11.5 bytes of data) —Preceding unsigned comment added by 192.156.110.31 (talk) 20:52, 22 April 2010 (UTC)

That stood for way too long. Removed. EBusiness (talk) 17:07, 30 May 2010 (UTC)

Comic strip Mister Boffo now using Microsoft Tag?

The comic strip Mister Boffo has recently started including scannable tags in its daily strips. I believe from the appearance, and from the source of the mobile app that reads it, that the tags are in Microsoft Tag format. If verified, this might be a nice piece of information to add to the article. --Dan Griscom (talk) 21:06, 29 June 2010 (UTC)

Improved tag SVG image

I made an improved version of the Tag sample SVG image in this article. My account is not trusted so i cannot upload it myself. If someone else would like to I'd appreciate it. The new SVG can be found here and may be considered public domain:

http://brianhoary.info/High_Capacity_Color_Barcode.svg — Preceding unsigned comment added by Myutwo33 (talk • contribs) 14:09, 20 July 2011 (UTC)

Looks good, Brian, thanks! I can work on that for you. --LarryGilbert (talk) 16:01, 20 July 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on High Capacity Color Barcode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070928092958/http://digital50.com/news/items/PR/2007/04/16/SFM039/international-organization-licenses-microsofts-new-multicolor-bar-code-technology-fo.html to http://digital50.com/news/items/PR/2007/04/16/SFM039/international-organization-licenses-microsofts-new-multicolor-bar-code-technology-fo.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 04:11, 2 April 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on High Capacity Color Barcode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100114082351/http://gettag.mobi/ to http://gettag.mobi/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:57, 3 November 2017 (UTC)