[Printers] Re: More thoughts on Toshiba/Kyocera/HP code

[Michael Sleator]

>OK, RE my last post, it seems this was already discovered by Patrick
>Murphy (2005-September/000013.html). Although it looks to me more like
>an error correction technique than a way to spread the dots out.

I can think of a couple of reasons to want to disperse the dots in
this way.  One is to reduce visual impact.  The human visual system
is very sensitive to edges, and using alternate columns tends to
reduce the visibility of the pattern.  Diagonal lines do still arise,
but the dots in these are sqrt(2) farther apart, which helps.

The other is to aid in data recovery in the face of certain assumptions
about interfering marks, which is essentially error correction, as you
say.  I'm not sure this helps against randomly distributed interference
because, although, as you point out, you can tell if a mark is in the
wrong column, you've also doubled the area of the pattern and thus doubled
the probability of a collision.  Random noise is probably not the target
model, though.  I would guess that, if this was a consideration at all,
the interference model probably had some assumptions about the sort
of pattern likely to be printed on the page.  It could even have been
optimized for known characteristics of currency images, but that seems a
little overly specialized.  Still, I have to wonder if the size of the
pattern, for example, was chosen to ensure enough bits in the area of
a postage stamp.


BTW, has anyone looked to see if, in any of the codes, the dots are
ever XORed into the yellow channel, or always ORed?


>So if the columns simply alternate, it might be clearer to remove the
>redundancy and draw each pair of columns together as a single column.
>Then we can try a few different methods for interpreting the dots and
>see if any match the printer's serial number, etc.

Yes, you can see this form in David Carne's output
(http://www.carne.sys-techs.com/2600N_patterns/viewer/murphy_decode.php).
I preferred to keep the physical representation in my images both to
provide a template against which to view direct scans of printer output,
and because, given that we still don't know how to interpret the data,
looking at the physical layout may provide clues that would be missed
in the reduced form.  For example, see the discussion of the "Column
Swizzling" conjecture in my recent post.  This is not to discourage
anyone from looking at the data in a more abstract form.  I think the
evidence for collapsing the column pairs in the actual interpretation
of the bits is compelling.  That's why I shaded them as I did.


>How are you suggesting we connect things together? E.g.
>A0,A1,A2,A3,B0,B1,B2,B3 etc. or A0,B0,A1,B1, etc?

This is *the* question, isn't it?  (Well, one of *the* questions,
anyway.)  It seemed to me very attractive that each block should stand
on its own as an 8-bit byte with column parity, but even if we accept
that assumption, that still leaves the question of the sequence of the
blocks.  The invariance of the 2A and 2B blocks in the two HP 2600N
samples seems like reasonable grounds to consider pairing of the A and
B blocks in general.  I don't see any way to make much more headway on
this without more samples to work with, though.

A philosophical aside:  As I see it, the interesting challenge of this
is to try to put oneself in the frame of mind of the code designer(s)
and, making an educated guess at the constraints and parameters of
the problem, see if one can recreate their solution.  After all, if
we assume that each code uniquely represents an individual printer,
there's not a lot of practical reasons to want to actually decode it.
For defensive purposes it is enough just to know that it is there,
and to avoid it where necessary.  It seems unlikely that I would find
myself in need of actually tracking a page back to a particular printer,
and even if I did need to and knew the exact coding algorithm, I still
wouldn't have access to the database of printer IDs that I would need
to actually locate a particular printer.

Michael Sleator
sleat at sleator.com