Subject: incompatible versions of compface

From: Alan Skea <[email-masked]>
Date: Thu, 9 May 91 15:53:49 +1000

Oh dear, something very bad seems to have happened somewhere.  Sometime
between versions 1.4.9 and 1.5.1, some change to compface/uncompface has
made it produce different output.  Here's some evidence.  Start with the
following 48x48x1 image data:

0x0000,0x0000,0x0000,
0x0000,0x0000,0xE000,
0x0000,0x0005,0x0100,
0x0000,0x000C,0x1F00,
0x0000,0x000B,0xE000,
0x0000,0x0006,0x0000,
0x0000,0x0044,0x0220,
0x0000,0x01C2,0xABC0,
0x0000,0x0164,0x0000,
0x0000,0x0220,0x0000,
0x0000,0x0430,0x0000,
0x0000,0x0420,0x0000,
0x0000,0x07E0,0x0000,
0x0000,0x0340,0x0000,
0x0000,0x03C0,0x0000,
0x0000,0x0240,0x0000,
0x0000,0x0240,0x0000,
0x0000,0x3E7E,0x0000,
0x0007,0xC241,0xF000,
0x0078,0x4240,0x0F00,
0x0180,0xE24E,0x00C0,
0x0E24,0xA66A,0xEA38,
0x303C,0xE42E,0xAE06,
0x4024,0xA428,0xE401,
0x8024,0x0420,0x8401,
0x8000,0x0420,0x0001,
0x8005,0x03C0,0xA003,
0xE005,0x201C,0xE00D,
0x9C07,0x5394,0x4071,
0x8305,0x729C,0x4181,
0xE0F0,0x5390,0x1E09,
0x8E0F,0x8203,0xE071,
0x8000,0x7FFC,0x0383,
0xE040,0x0000,0x200D,
0x9C07,0xE015,0x4071,
0x8300,0x1DC0,0x0181,
0x90F0,0x0000,0x1E01,
0x830F,0x8003,0xE001,
0xC0E8,0x7FFC,0x07C3,
0xF006,0xC000,0x0C0F,
0x8E00,0x701F,0x01F9,
0x8380,0x1DC0,0x0F05,
0x90FC,0x0000,0xF853,
0xF103,0xFFFF,0x83CE,
0x0E36,0x0000,0x69F8,
0x0381,0x3A84,0x8F00,
0x00FC,0x0008,0xF800,
0x0003,0xFFFF,0x8000,

compface from the 1.4.9 distribution gives this:

 #UW6Pu"eg3:p^#1__\&p,H;YIYx0i_KN:3hj1)^3hxYAv0+$UP0O7%\m(j/O*u%=#5LO8#L
 Od;f^$.;q3))-kxw[b-)EsDR[m-wOn'=B{{,&M`ZXk2Xe:.z47Y&/+(a)q$V*/UXR;^K7tHK$VZ@:,
 Q&7?>d1\Xbj+p=8TJrh-_~[jw'hmt+m_f}H_!VXE(-R%kh&#2fVk!ZSmanue8V9LcmGpHG'u'xKzf\
 }|m

compface from the 1.5.1 distribution gives this:

 +;75%|8:$u:]yiY/y5T!\P_%:l*1AOwKzYeav+!jKN{iSA(vFd)TVZR+L^E>7fpr!$rm\XW
 Clh*|4wi{kT$,eC7~co-u)<p'C^WO@:>B"g4VZbgfAu$17/{?\P:'%OBE{Ge*!T'\P}Fx<TF^eq3{[
 !WBqe:&`PICL-;trf_p;U[::,HL$kYXAD:j!^9@NM05A1`BEs/&r-#Nc#R)=|M,&Pa6eB^W$4L{JN]
 cj^ii&

The face resulting from the uncompression of a 1.4.9 X-Face: using the
1.5.1 algorithm seems to shift the whole image to the left a bit (or
maybe two - I don't really have time to check this out thoroughly) and
introduces some corruption into the bottom right of the face.  Caveat:
these observations are made on the basis of a sample space of 1 face.

I should think that it is _very_important_ that everyone be running a
compatible versions of compface.  A patch to restore the old encoding
is critical (I should think most faces in existence were built using a
version <= 1.4.9).  Sorry I don't have the time to go further with this
- hopefully someone else does and can provide a quick patch.

Also we now have the task of trying to determine which faces need to
be recompressed to make them compatible and to do this we will need to
determine at what version the new format first appeared.  As a final
remark, maybe the version of faces should be somehow encoded into the
compressed face - this seems like a bad idea at this stage so maybe we
should just be careful that the encoding never changes.

Alan Skea.

---

From: John Mackin <[email-masked]>
Date: Thu, 9 May 91 22:15:25 +1000

From: Alan Skea <[email-masked]>
    Date: Thu,  9 May 91 15:53:49 +1000

    Oh dear, something very bad seems to have happened somewhere.
    Sometime between versions 1.4.9 and 1.5.1, some change to
    compface/uncompface has made it produce different output.  [...]
    I should think that it is _very_important_ that everyone be running
    a compatible versions of compface.  A patch to restore the old
    encoding is critical (I should think most faces in existence were
    built using a version <= 1.4.9).  Sorry I don't have the time to go
    further with this - hopefully someone else does and can provide a
    quick patch.

Arrgh.  I knew the situation was bad, but I didn't know it was this bad.
I don't have time to look at this now either, but I will have to.  It
won't be for a few days though as I am presently too ill to go in to
work.  The situation, so that everyone knows (Rich already knows) is
this: there are definite problems with post-1.4 compression and
decompression.  My understanding of the code is by no means complete,
so I cannot, at this time, give a fix.  I am liasing with jaa, but he
is very busy too now and has little time to look at it; what I was
hoping was that I could work out what was wrong and then discuss the
fix with him.  He is in no doubt that Victor's version of gen.c is
not correct.

I will try to work out something about what is going on, and talk
to jaa and see if we can come up with a fix between us.  (Of course,
if anyone on the list thinks they understand jaa's code and can fix it,
that would be terrific.)  I agree that all versions of compface must
work identically and that the old behaviour must be restored as a
matter of urgency.

    As a final remark, maybe the version of faces should be somehow
    encoded into the compressed face - this seems like a bad idea at
    this stage so maybe we should just be careful that the encoding
    never changes.

I lobbied strongly for the inclusion of a "magic string" at the
beginning of a compressed face when jaa was developing the algorithm
back in 1989.  This would have given a bit of bullet-proofing, as Mark
(most reasonably) wants, and more importantly the ability to support
multiple compression algorithms, should one be discovered that is
better than jaa's on average for faces (in my view, a tad unlikely,
but we should never underestimate human ingenuity) or if we wanted to
provide a different algorithm for compression of line drawings as opposed
to halftone images, which the current algorithm typically doesn't work
so well on.

Unfortunately, I lost that argument, so no magic/version number got
included.  I think we are stuck with compface format now.  All we need
is to keep compface format working...  Sigh.

John.