Subject: son of X-Face:

From: [email-masked] (James Ashton)
Date: Tue, 17 Aug 93 9:43:52 EST

With `multimedia' computing taking off even for some pretty low end
machines it looks like X-Face is gaining wider acceptance.  As the
author of the compface routines which define the `X-Face' standard I've
had contacts from people interested in using X-Face in products and in
extending the standard.  Apparently customers want colour.

I'm happy to be involved in doing the work required to create an
extension to the standard.  I can probably clean up the existing
compface routines at the same time.  What I need is feedback about what
people want and what is practical.  Also if I proceed I'd like some
sample data to play with.  I can scan in colour here but images from a
single site tend to be similar.  I'd hate to spend time tuning my
compression and then find that data from elsewhere compressed poorly.
I expect 48x48x8+colour map will be the easiest for me to work with.
I'm sure I can convert from any of the popular standards.

A quick list of issues that have occured to me are:

	Resolution.  Almost certainly still 48x48.

	Colour map usage.  Per face maps or a fixed map for all faces?
	Other possibilities?  How many colour map entries can users
	afford?  Can we support hardware with very few available
	colours?

	Should the compression be lossless as now or can we afford
	lossy compression with colour?

	Since we have colours will we use dithering?  Dithering
	obviously helps alot with a limited number of available colours
	but it makes compression harder.

	Will the images look the same on different hardware or will
	more available colours allow a better image.

	I'm assuming existing standards (JPEG comes to mind) are
	unsuitable for this purpose.  Please let me know if not and
	save me lots of work.

	How many data can we stand in the headers?  Given that `X-Face'
	is usually three to four lines it's hard to see a colour
	version using less than six lines.

	Backward compatibility is impossible without choosing a new
	header title, say `X-Image'.  Should an old style,  one bit
	image be available from an `X-Image' along with a colour
	version or should we just include both an `X-Image' and an
	`X-Face'.

Speaking of standards, this is all unofficial at this stage.  What do
people think of moving towards a `Proposed Standard' RFC or at least an
`Experimental' RFC.

TIA for any feedback.  I may post this to an appropriate newsgroup
depending on the response from this list.  Finally, if you know of a
good reference on image compression that may be useful let me know.
There's likely to be some recent work I'm unaware of.
--
James Ashton						  System Administrator
VK1XJA					     Department of Systems Engineering
Voice +61 6 249 0681	  Research School of Physical Sciences and Engineering
FAX   +61 6 249 2698				Australian National University
Email [email-masked]			   Canberra ACT 0200 Australia

---

From: Jamie Zawinski <[email-masked]>
Date: Mon, 16 Aug 93 18:40:55 PDT

> 	Resolution.  Almost certainly still 48x48.

I think restricting the image size so arbitrarily is a bad idea; 48x48 is
really tiny!  All of my other icons are 64x64, and they just don't look all
that large.  The same people who want color today will want bigger tomorrow.

> 	unsuitable for this purpose.  Please let me know if not and

I think a good approach might be to use the XPM3 format as the baseline, and
find some way of compressing it efficiently.  It's a very nice format, in
that it allows you to efficiently tune your image for color, grayscale, and
monochrome devices without duplicating data.  Also there is a good library
for managing color allocation, etc.

> 	header title, say `X-Image'.

You could put a magic number in the new format that is unlikely to occur at
the beginning of the old format.  For example, some character which the old
format doesn't use.  (I don't know how practical this is.)  Or just put a
checksum in the new format; if the checksum doesn't match, assume it's the
old format.  That should be foolproof for non-corrupted images.

	-- Jamie

---

From: [email-masked] (Paul Smith)
Date: Tue, 17 Aug 93 09:22:17 EDT

[] Regarding son of X-Face:;
[] [email-masked] (James Ashton) writes:

    ja> 	Resolution.  Almost certainly still 48x48.

I'm afraid I agree with Jamie and Rich on this, *especially* if you're
going to be generating an RFC (which I think is a great idea): I don't
think we should mandate an icon size.

Definitely suggest one, and make it the default, and even go so far as
to tweak the compression for a certain size (or maybe use a tuned
algorithm for 48x48 or 64x64, and a generic algorithm for larger ones?)
But it seems a bit short-sighted on our part if we seriously restrict
the size.

Face display programs can offer the user a choice of how to do displays,
which is where you want that choice anyway: the viewer can crop, shrink,
display full-size, or not display large faces at all.  You could even
have a viewer that shrunk the icon, then if you clicked on it it would
pop up the full face.  Or whatever.

The point is, the sender should send what he wants and the viewer should
view what she wants.

    ja> 	I'm assuming existing standards (JPEG comes to mind) are
    ja> 	unsuitable for this purpose.  Please let me know if not and
    ja> 	save me lots of work.

I third or fourth the vote to examine XPM; we used this for icons at my
last job to excellent effect.  A very nice package.

    ja> 	Backward compatibility is impossible without choosing a new
    ja> 	header title, say `X-Image'.  Should an old style,  one bit
    ja> 	image be available from an `X-Image' along with a colour
    ja> 	version or should we just include both an `X-Image' and an
    ja> 	`X-Face'.

I think Jamie is correct: the best thing would be to find a way to make
old vs. new detection automatic.

Also, the new X-Face spec should imbed some kind of version info so the
compression algorithm, etc. can be updated and not break everything
(except you'd need a new viewer--but old viewers could handle this
relatively gracefully with a message or special icon or something).

                                                                paul
 _____________________________________________________________________________
/                                                                             \
 Paul D. Smith                   | That's the thing about being a boxer:
 <[email-masked]>          | even when you're at the top of your field,
 Wellfleet Communications, Inc.  | people still hit you in the head.
 Network Management Development  |                    -- Paula Poundstone
\_____________________________________________________________________________/

---

From: [email-masked]
Date: Tue, 17 Aug 1993 09:34:08 -0600 (CDT)

> extending the standard.  Apparently customers want colour.

We might as well bite the bullet now.  Once you incorporate color, you're
pretty much done.  I don't think the world will come to an end because
people are sending 48x48x9 face images through the mail either, so I wouldn't
worry about net traffic in this case.  Hell, http and gopher traffic is going 
to crush email until MIME stuff is used more often.  Should the face be
added as part of MIME, or left in the header though?

> 	Resolution.  Almost certainly still 48x48.

Why bother, the display program can resize it.  If people start sending
300x300 images of themselves they'll hear about it from someone when they
are complaining about the size of their mailbox or the time it took to
update the faces pictures when new mail arrived, etc.

> 	afford?  Can we support hardware with very few available

Again, I'd let the program handle it.  It'll just have to be written to
be smart about which colors it shares.  Very smart!

> 	lossy compression with colour?

What does lossy compression do to extremely small images?  Isn't that
a problem.  I think the people mailing out their face in the header
or putting it on some database should decide for themselves.

> 	but it makes compression harder.

No.  Let's just send up to a clean full color full size image, and let
people decide on their own what to actually send.  Even sites can decide.
I went to post some net-news, and our Pnews said my signature was too
long.  There's a precedent.  People that are religious about not spending
taxpayer money (or their own when they start paying packet based) will
create dithered, compressed, itsy-bitsy images. 

> 	more available colours allow a better image.

I would go with more colors allows better image.  Why sacrifice the high
end for the low end.  That would be a big mistake. 

> 	unsuitable for this purpose.  Please let me know if not and

You certainly don't want to get into the problem where people have to first
have compiled the jpeg libraries, and then the tiff libraries, and then
have PBMplus installed, and all that crap just to build the programs.  I
think just sticking to uncompressed simple standards would be a good start.
GIF, xNm, pNm would probably do the trick.

> 	version using less than six lines.

So who counts lines in headers anymore anyway.  I don't thing the added 
bandwidth will be noticable on the net!  I hope people start to ignore
this as being a big issue, and recognize that recognizing the people that
you've been conversing with is very important to memory retention and 
therefore has great impact on your work!!!!  I'm on many mailing lists,
and I have a hard time telling who is who on follow ups, and who are the
people worth listening to, etc., because I do not recognize their names!
Memory retention literature will tell you images are key!! Does anyone
agree with me that header size for full color uncompress images is no
big deal?

> people think of moving towards a `Proposed Standard' RFC or at least an

Absolutely!!!

-- 
Matthew V. Hughes - MN Supercomputer Institute  Graphics Support Coordinator
Minnesota Supercomputer Center, Inc.                      Ph: (612) 626-1765
1200 Washington Avenue South  [email-masked] [email-masked]   WWWeb home:
Minneapolis, MN 55415          <http://i5.msi.umn.edu/WWW/People/hughes.html>