Re: The GIF format as intellectual property (fwd)

lilley (
Tue, 10 Jan 1995 00:17:45 +0100

Kee Hinckley writes:
> [For those on the cc list, who may not have seen the news, Compuserve and
> Unisys have decided to charge royalties for all software that uses GIF.

> I'd propose the following.
> 1) (Moves are already being made in this direction.) Get code out there for
> all existing browsers to gain JPEG support ASAP.

Fine. Needs doing anyway.

> 2) Draft a spec, similar in concept to GIF, but using an alternative
> non-lossy compression mechanism

Ah, the invent-another-format position. Why? What is wrong with all the
hundreds of existing formats?

While we are at it, there are actually two sub-options here:

2a) Use an existing format that uses non-LZW compression
2b) Use an existing format, and use the MIME content-encoding header to
specify a suitable compression scheme. I notice that Arena already supports
inline XPM (which is in dire need of compression, I admit).

> 3) Add a "mask" attribute to <img>

Is adding to HTML 2.0 wise? Supposed to be about frozen - adding to HTML 3.0
seems a better idea. So, add attributes to FIG and IMG

> which specifies an 8-bit grayscale mask

Hooray! Yes! Proper antialiased text in transparent graphics without having
to guess a likely background colour!

Again there are two sub-options:

3a) Have an external mask file for all image types
3b) Have the mask information inside the image file

> for handling anti-aliasing (aka "transparency")

Well, transparency and antialiasing are separate though related issues.
You can have an antialiased figure that has no transparency; you can have
a figure with transparency that is not antialiased. At present though,
producing a figuire that is both antialiased and transparent involves
making the assumption that the background is not too far from a mid grey.

> Its argument is any
> format supported by "src".

Well OK but then we need registration hints. What if the mask and the
image are different sizes?

> That will more than make up for the loss of the
> transparency option in GIFs.

> The only disadvantage I can think of for not
> providing this in the image format is that you can't provide a mask with an
> non-in-line image, but I think the benefits of doing this without creating
> a new image format outweigh that minor issue.

Again, a new format need not be defined. There are loads of valid arguments
that could be put forward on the merits of 3A or 3B, but the labour of
creating a new format is a spurious one. Just use an existing format that has
an alpha channel. TIFF 6 springs to mind as the obvious candidate: AVS X image
files, Photoshop files etc are other, less suitable examples. TIFF does of
course have a freely available library which can be linked to, so inline
TIFF should be fairly easy to add.

> None of this is rocket science. If those three things can be pushed forward
> with a minimum of fuss, and no time wasted fighting with Compuserve and/or
> Unisys

I agree that this would be unproductive.

Chris Lilley
| Technical Author, Manchester and North HPC Training & Education Centre  |
| Computer Graphics Unit,        |     Email:      |
| Manchester Computing Centre,   |     Voice: +44 61 275 6045             |
| Oxford Road,                   |       Fax: +44 61 275 6040             |
| Manchester, UK.  M13 9PL       |      X400: /I=c /S=lilley              |
|                 /O=manchester-computing-centre /PRMD=UK.AC /ADMD= /C=GB/|
|<A HREF="">my page</A> | 
|This is supposed to be data transfer, not artificial intelligence. M VanH|