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
cameron@cse.unsw.edu.au, DoD#743
-- Sam Jones <samjones@leo.unm.edu> 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.