(keitai-l) QR versus Semacode?

From: Jim Levinger <jlevinger_at_nextcodecorp.com>
Date: 07/22/05
Message-Id: <20050722174241.OOHK5784.imta02a2.registeredsite.com@IBMCF7602DB699>
An associate of mine just made me aware of the recent discussion thread
about Semacode and QR Code and asked me to add some perspective and insight.

I am with Nextcode Corporation, we develop state of the art barcode scanning
solutions specifically for camera phones and have extensive experience
working with the full range of 1D and 2D barcode formats. We sell encoding
and decoding software for both QR and Data Matrix as well as a much more
advanced 2D code format called mCode which is was specifically developed for
mobile applications.

Semacode is not a new barcode format. It appears to be a slight variation of
standard Data Matrix code. My understanding is that there are some special
ways that data has been encoded into the code structure to make the code
proprietary. As such, Semacode is subject to the inherent limitations of
Data Matrix, and I'm not sure I see that there's any value added by the
changes that have been made from the standard.

Both QR and Data Matrix were originally developed for industrial purposes.
When the codes were conceived, laser scanning was the primary code reading
technology, image sensors were costly and CPUs were slow, and no one was
expecting that these codes would (or even could) be decoded by battery
operated hand held mobile devices in uncontrolled conditions. Neither code
is well adapted to the problems of mobile cameras.  Neither is designed to
take advantage of the current know-how in machine vision.

1. Both codes types have square footprints with a rigid selection of data
sizes.  For example QR starts at a 21x21 matrix and then grows by four
modules a side (25x25, 29x29, etc.) Data Matrix starts smaller but still has
arbitrary square sizes.  (Data Matrix has a few rectangular sizes defined in
the standard, but these are rarely used in practice.)  

As we deal with consumer applications one needs more flexibility. A code
should be available in shapes that conform to advertising, not forcing
advertising and product packaging being forced to work around the code. 

2. QR and Data Matrix are also inherently ugly and industrial looking. They
do not integrate aesthetically with print advertising. We believe that codes
should be available in any number of branded shapes and be able to readily
incorporate graphics, color and unique designs. 

There is no reason today why we can't have codes that come in arbitrary
shapes and have any desired data density. 

3. The finder patterns and fixed pattern elements of both QR and Data Matrix
are consume large amounts of space relative to the remainder of the code.
Today, we can create and decode codes with the same module size that can
carry the same amount of data in as little as 1/3 the amount of space and
decode faster than QR or Data Matrix.

The extra space consumed by QR and Data Matrix is a problem.  With today's
optics in the typical US cell phone, these codes have to be bigger than you
would like them to be for most applications.  Macro lenses are available on
phones in Japan, but it will take years for them to get into the mainstream
in much of the rest of the world. Macro lenses do work, but it's easy to
forget which way they're set. Contact lens solutions also work, to some
degree, but aren't really going to cut it for steady consumer usage.

4. The finder patterns on QR and Data Matrix are not well designed for
handheld phones where defocus, perspective, motion blur, lighting, shadows
and other impairments are common. Notably the QR "Eye pattern" requires some
extra CPU time to cope with rotated patterns.  Further, The QR finder
pattern only yields three principle reference points, which are inadequate
by themselves to cope with perspective distortion beyond a few degrees.

With Data Matrix the finder pattern is the outline of the code, which makes
it a CPU hog to find in anything but the clearest correctly oriented images.
Perspective distortion on Data Matrix is a real problem in decoding.

5. Regarding applications for codes: I disagree with Simon Woodside's
contention that it is sufficient for everything to be based on
URL encoding will satisfy all the application needs. 

Of the two codes, I think QR is much better for mobile phone use.  Any
vendor supporting barcode decoding should be able to support either code, if
a customer requires it.  But I think that QR only goes a quarter of the way
toward what is possible and desirable for consumer applications with mobile
phones.  


Jim Levinger
Nextcode Corporation
www.nextcodecorp.com

-----Original Message-----
From: Mohit Sindhwani <mohits@onghu.com>
To: 
Subject: (keitai-l) QR versus Semacode?
Date: Sun, 10 Jul 2005 13:18:53 +0800

In the past few weeks, I have heard quite a bit on this list about QR Codes
and a bit about Semacode.  Now, I'm curious.  How do they stack up against
each other?

Are they complimentary or competitive?
Which stores more data?
Which works faster?
How is costing done for each?
User base?

Thanks,
mohit.
Received on Fri Jul 22 20:42:48 2005