Subject: son of X-Face:

From: [email-masked] (Cameron Simpson)
Date: Tue, 17 Aug 93 12:57:38 +1000

James Ashton <[email-masked]> writes:
| Apparently customers want colour.

Argh!

| I expect 48x48x8+colour map will be the easiest for me to work with.

Perhaps you should consider 48x48x9 (giving 3x3x3 `full-colour' resolution)
which would obviate the need for a colour map.

| 	Resolution.  Almost certainly still 48x48.

Sounds right, small and will fit neatly with existing faces.

| 	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?

Rather than a colour map, a simplescheme as described above might be the go.
For example, xv-3.00 uses a standard 256 cells map for full colour images
which I suspect is a 3x3x2 fill of the colour cube.

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

Given the low resolution of the image to start with, lossy compression

	- might not actually gain you much spacewise
	- might blur an already grainy image

| 	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 think you should assume some reasonably `ideal' hardware and put hooks in
the display code for accomodating different gamma factors for the RGB
components to tune the image for a particular display.

| 	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'.

How about X-Face-RGB or X-Face-Colour, basically to keep the X-Face prefix?

How about:
	- on colour (or greyscale) displays use the colour header if supplied,
	  else the 1 bit version
	- vice versa for 1 bit displays
	- be prepared to dither colour down to 1 bit if there's no 1 bit
	  version and we have a 1 bit display

Personally I think we should encourage use of only one header in a message,
but the code should accomodate both.

| 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.

Why not? Sound like a good idea.
	- Cameron Simpson
	  [email-masked], DoD#743
--
Sam Jones <[email-masked]> on the Nine Types of User:

X-user -	"Will you look at those. . .um, that resolution, quite
		impressive, really."
Advantages:	Using the cutting-edge in graphics technology.
Disadvantages:  Has little or no idea how to use the cutting-edge in graphics
		technology.
Symptoms:	Fuzzy hands, blindness
Real Case:	When I was off duty, two users sat down in front of me at DEC
		station 5000/200s that systems was reconfiguring.  I
		suppressed my laughter while, for twenty minutes, they sat
		down and did their best to act like they were doing exectly
		what they wanted to do, even though they couldn't log in.

---

From: [email-masked] (Cameron Simpson)
Date: Tue, 17 Aug 93 14:17:37 +1000

Jamie (I think) wrote:
| 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.

I wrote:
| I used to think this way too, but it uses up so much screen real estate.

Jamie Zawinski <[email-masked]> writes:
| But that's the point: as DPI goes up, the icons get *smaller*.  They don't
| take up more mm on the glass, they just shrink.  Bigger pixel counts don't
| translate to more screen real estate over time, they just translate to better
| image quality.

Truely, as DPI goes up, actual size goes down, but DPI doesn't go up very fast.
I have had a 1280x1024 1 bit screen for the past 4 years and

	- I use twm, whose _major_ attraction for me is the Icon Mangler
	  which gives me a popup menu of window names rather than icons,
	  which consume much space
	- I have turfed all my window borders and titles (I think they
	  clutter things)
	- my root window access is a 3 pixel strip across the top of the screen
	  (easy to aim at, just slam!-click)
	- the next 100 pixels down is a console window and faces and xloads
	  and a clock
	- the bottom 900 pixels is vertically split into two windows; a shell
	  and an editor
	- I still don't think I have enough screen real estate. I want
	  manuals off to the right and a browser to the left and a calendar
	  above and ...

This is on an HP/Apollo. One of these days I'll migrate to a Solaris box I
expect (mostly for the grunt). I suspect I'll have to squeeze into an 1152x900
screen for that. Ouch.

My point is that high res screens are still very expensive (high res colour
extremely expensive) and I don't see 2560x2048 pixel screens coming any time
soon. (But I want, I really do, 2x the current res and 1.5x the current DPI).

I agree that more DPI means better image quality, but we're not getting more
DPI. DPIwise my screen is still more or less top-of-the-line for desktop
machines (barring pure full-on graphics workstations) as it was 4 years ago.

| > 	- the images rapidly get too big to pump around as mail headers.
| > 	  I fear the day when the headers outweigh the message text by orders
| > 	  of magnitude.
| 
| They don't get big unless you make them big.  If someone doesn't want their
| headers to swell, then they'll just use a 48x48 image, right?

In a multimedia environment people won't even consider it. But those of us
outside such an environment have to deal with the fallout.

| > | I think a good approach might be to use the XPM3 format as the baseline,
| > Where could one find the spec for this?
| export.lcs.mit.edu: contrib/xpm3.2g.tar.Z or something close to that.  
| I think a slightly older version also comes with X11R5.  The pbmplus 
| toolkit can convert to xpm too.

Thanks, I'll go look.
	- Cameron Simpson
	  [email-masked], DoD#743
--
If Brawny wants to print something on its paper towels, it should print
chainsaws or Monster Trucks or maybe scantily-clad large-breasted women.
None of this duckie crap.	- Alex Elliott, The Lemming.

---

From: [email-masked] (Rich Burridge)
Date: Mon, 16 Aug 1993 22:45:37 -0700

> | that large.  The same people who want color today will want bigger tomorrow.

Let's talk interested parties here. I know that Dan Heller has approached
James for color X-Face:'s for inclusion in the Z-Mail mailtool product. This
runs on Unix, DOS and the Mac. Somebody from Microsoft approached me to
include X-Face: in their mailtool; I suspect they've approached James too by
now. There could be others...

We're talking influential software here; it's no longer a case of just putting
up a list of icons in a row as mail comes in. It's inclusion of a visual
representation of the sender in a special window when viewing a mail message.
I predict that 128x128x8 color images will be required soon. Whatever we
choose now should allow for this possible expansion. There are all those
Usenix FaceSaver images out there. I know they were 128x128 grayscale images
a couple of years ago. Are they saving them as color images yet?

My own feeling is that the size of the image shouldn't be fixed; it should
be included in the data. The XPM standard is nice for this. I easily added
XPM "view by content" support to Sun's file mangler. There are standard
libraries routines that can be used. You can have as many (or as few) colors
as you want. You can edit the files with a text editor.

Another approach is to use a standard palette of colors. The Sun DeskSet tools
use a palette of 72 "standard" colors. This works well, and leaves slots free
for other tools to use.

If XPM is used, then I suggest the mono X-Face: should be converted to use
either XBM or the "mono" part of XPM. Preferably the latter. XPM allows you
to define not only a color representation, but a mono equivalent in the same
file. This might be useful if transmission has to be over low bandwidth lines.

I definitely believe that an RFC should be written.