We could compare all 64 pixels. But what if we're going to compare it to two different c64 blocks?
To find the closest block would require 64 comparisons each time. But why work so hard?
After comparing A, we already did most of the work to compare B. Look at how many pixels they have in common:
Common between:
and:
are 53 pixels:
So to save time, we could compute this common part:
then, the two parts necessary to finish making A or B:
plus
equals:
plus
equals:
The two extra parts only have 11 pixels each.
Now, instead of computing 64 pixels for A, and 64 for B, we only have to
compute 53 for the common one, 11 more to make the A, and 11 more to make the B.
for a total of 75.
This is significantly less then 128!
Our partials so far are:
, 
and
We could compare all 64 pixels...Or maybe it has something in common with the other letters?
Which partial does it resemble most?
Let's look at all the partials we have so far:
Common between:
and:
are 45 pixels:
Common between:
and:
are 1 pixels:
Common between:
and:
are 10 pixels:
It has the most in common with partial 0:
It has these 45 pixels in common, which we'll call partial 3:
We can add partial 3
and partial 4
to make
Since partial 3 is part of partial 0, we won't compute partial 0 anymore.
Instead, we'll use partial 3
and partial 5
to create partial 0.
partial 3
plus partial 5
equals partial 0
partial 0
plus partial 1
equals
partial 0
plus partial 2
equals
partial 3
plus partial 4
equals
They are partials 3, 5, 1, 2 and 4.
We don't need to compute partial 0, because it's simply made out of 3 and 5 and is virtually free.
The costs of these partials are 45, 8, 11, 11 and 19, for a total of 86.
This is faster than computing 64+64+64 = 192 pixels.
If you look closely at partial 2
and partial 4
You'll notice they have 10 pixels in common:
