> At 1:36 PM 1/9/95, lilley wrote:
> >Kee Hinckley writes:
> >> 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?
> There is an advantage to doing something incremental off of the existing
> format - it speeds the acceptance. In fact, a proposal (and implementation)
> have already been made for an LZHUF version of GIF, but it doesn't always
> compress quite as well.
Well yes. But now that Unisys have pressured Compu$erve into claiming GIF
as their own, there is a problem. If you make something like GIF and don't
call it GIF, it is effectively a new format which may, as you say, slow down
acceptance. If you call it GIF95 to speed acceptance, then Compu$erve own it and
it is to be used "primarily for files obtained directly from Compu$erve" and
all the other stuff they threw in that went far beyond what UniSys pushed
them into.
> But (as someone else pointed out)
might have been me, over on comp.graphics
> TIFF might be
> the way to go for an alternate. The only concern I have there is to make
> sure that the overhead for small images isn't too high.
Overhead? Ah yes, oops. Here is a small ( 14 by 14 pixels) gif like
you see all the time for pretty balls on lists ;-) It has 40 similar
shades of red in it.
cguhpc [140]: giftoppm reddot.gif | pnmtotiff -none > reddot.none.tif
pnmtotiff: computing colormap...
pnmtotiff: 40 colors found
cguhpc [141]: giftoppm reddot.gif | pnmtotiff -packbits > reddot.packbits.tif
pnmtotiff: computing colormap...
pnmtotiff: 40 colors found
cguhpc [142]: giftoppm reddot.gif | pnmtotiff -lzw > reddot.lzw.tif
pnmtotiff: computing colormap...
pnmtotiff: 40 colors found
cguhpc [143]: ll
total 14
-rw-r--r-- 1 lilley users 331 Jan 9 20:28 reddot.gif
-rw-r--r-- 1 lilley users 1892 Jan 9 20:31 reddot.lzw.tif
-rw-r--r-- 1 lilley users 1962 Jan 9 20:30 reddot.none.tif
-rw-r--r-- 1 lilley users 1936 Jan 9 20:31 reddot.packbits.tif
The converter I was using does not support Huffman compressed TIFF or JPEG
compressed TIFF so I could not test those. I see that packbits is pretty useless
on this example and lzw, obviously, is not a wise choice at present ;-)
Imconv is similarly limited. Here is what imconv can do when reading and writing TIFF:
tiff Tagged image file
a.k.a.: tif
Creator: Aldus, MicroSoft, and NeXT
Read support:
1-, 4-, 8-, and 32-bit color index images. 24-bit RGB and 32-bit
RGB+alpha images. Standard (uncompressed), Mac Packbits, and Lempel-
Ziv & Welsh compression.
Write support:
1-, 8-, and 32-bit color index images. 24-bit RGB and 32-bit
RGB+alpha images. Standard (uncompressed), Mac Packbits, and Lempel-
Ziv & Welsh compression.
Although TIFF can do 24 bit images, note that a pallette (256 colour) TIFF
has been generated here.
cguhpc [144]: tiffinfo reddot.none.tif
TIFF Directory at offset 0xcc
Image Width: 14 Image Length: 14
Bits/Sample: 8
Compression Scheme: none
Photometric Interpretation: palette color (RGB from colormap)
FillOrder: msb-to-lsb
Document Name: "Standard Input"
Image Description: "converted PNM file"
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 585
Planar Configuration: single image plane
Color Map: (present)
With widdy little images like these, the tags and stuff and the
pallete start to take up a lot of the file, proportionately, compared
to the actual pixel data.
Actually, raw ppm files are not too bad.
cguhpc [145]: giftoppm reddot.gif > reddot.ppm
-rw-r--r-- 1 lilley users 601 Jan 9 20:40 reddot.ppm
especially if gzipped
-rw-r--r-- 1 lilley users 274 Jan 9 20:40 reddot.ppm.gz
Ha! smaller than the GIF. Also, ppm is very definitely in the public domain,
no company owns it.
> >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).
>
> 2b doesn't really solve the problem for other uses of the format though. I
> think any solution has to take into account the millions of other files in
> GIF format.
Well if you apply that logic, then a separate alpha file doesn't help other
users of the format either, it needs to be all one file for their convenience.
> >> 3) Add a "mask" attribute to <img>
> >3a) Have an external mask file for all image types
> >3b) Have the mask information inside the image file
> I'd prefer 3b,
me too, on balance
> since it's easier to manage, but practically, I think we
> have to do 3a, since modifying JPEG to add a mask doesn't seem terribly
> practical. (Although, masking a lossy compression file may not be very
> practical either).
Masking a JPEG compressed file is certainly going to be tricky.
Remember, folks, while glibly talking about "a JPEG file" we mean one of
two things:
1] A JPEG JFIF file, ie a format
2] A file format that uses JPEG compression, such as TIFF, CGM, etc etc
>
> >Well OK but then we need registration hints. What if the mask and the
> >image are different sizes?
>
> Ugh. I suppose an xoffset and yoffset setting would work, but I'd rather
> just disallow it.
xofset and yoffset use what units? Pixels? Ems?
Not trying to be picky (honest!) but this does impact the discussion about
compositing, (partially) overlapping multiple images, vector overlays on
pixel images, and such that came up just before the Yuletide break.
For a single image and a single, separate mask there are these options:
A] stretch or shrink the mask to fit the image
B] map the mask onto the top left/ top right / centre/etc of the image
C] replicate the mask as a tiling
D] ignore non-registered mask data
E] throw a fit and dump core
F] map the mask onto some offset with defaults 0,0 (top left? bottom left?)
For a single image with an integral, optional alpha channel, like TIFF, there
are none of these problems. Then again, if you want multiple overlapping
images composited together and a single mask over them (do we?) clearly the
mask must be in a separate file.
> (BTW, I've seen no activity on this mailing list in weeks, has it lulled,
> or did I get dropped somehow?)
I just got all the messages from 1 Jan onwards in the last hour or so. I
assumed it was our flakey mail server but if you see that behaviour too, it
may well be the CERN list server.
-- Chris Lilley +-------------------------------------------------------------------------+ | Technical Author, Manchester and North HPC Training & Education Centre | +-------------------------------------------------------------------------+ | Computer Graphics Unit, | Email: Chris.Lilley@mcc.ac.uk | | 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="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +-------------------------------------------------------------------------+ |This is supposed to be data transfer, not artificial intelligence. M VanH| +-------------------------------------------------------------------------+