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.
> 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?
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!
> Should the compression be lossless as now or can we afford
> 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.
> Since we have colours will we use dithering? Dithering
> obviously helps alot with a limited number of available colours
> 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.
> Will the images look the same on different hardware or will
> 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.
> 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.
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.
> 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.
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?
> 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.
Absolutely!!!
-- Matthew V. Hughes - MN Supercomputer Institute Graphics Support Coordinator Minnesota Supercomputer Center, Inc. Ph: (612) 626-1765 1200 Washington Avenue South hughes@msc.edu hughes@msi.umn.edu WWWeb home: Minneapolis, MN 55415 <http://i5.msi.umn.edu/WWW/People/hughes.html>