HDTenEightyP/NetNews huggingface dataset:
From: mccarty@netcom.com (Michael K McCarty)
Subject: Re: bitmap compression
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 6 Nov 1992 09:23:42 GMT

umfehr06@ccu.umanitoba.ca (John Fehr) writes:

>I'm currently looking for compression algorithms to compress weather charts.
>These charts contain about 95% white pixels, and 5% black pixels.  I've
>already thought of using GIF, but the files only shrink down to ~100k.
>(Originally ~1meg uncompressed.)  I've also thought of using arithmetic
>coding.  Does anyone have any suggestions as to other compression methods?
>  Thanx for your help,
>    John
Why don't you store the offsets of the black pixels?  That should bring
it to under 100k.  

>-- 
>-----------------------------------------------------
>-  John Fehr                        -    DoD#505    -
>-  umfehr06@ccu.umanitoba.ca        -    GPz550     -
>-  umfehr06@silver.cs.umanitoba.ca  -  A3000 kicks! -
-- 
<=-----------------------------------------------------------------------=>
  Michael K McCarty                Internet: mccarty@netcom.com
					     mccarty@dhvx20.csudh.edu
"...close the hatch. Careful not to lock it on the way out."
    -Buzz Aldrin :: Apollo 11
Newsgroups: comp.compression
From: rainy00@DMI.USherb.CA (YVES RAINVILLE)
Subject: statistics needed
Reply-To: rainy00@DMI.USherb.CA
Organization: Universite de Sherbrooke -- Dept. De Mathematiques et D'Informatique
Date: Thu, 12 Nov 1992 21:59:12 GMT


Hi, this is my first time on this network.  I`m doing a project on file compression.
The compression algorithms that I use are : Huffman and LZW.  
I would like to receive a table showing the compression ration of those two algorithms
for different kind of files. (.EXE, .COM, etc...)

That would help me a lot.  Thank you.
(I hope that my English is not to bad to read)
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Latest PKZIP.
Date: 8 Nov 92 14:36:13 GMT
Organization: Academic Computer Centre Utrecht

In <BYA=qN#@engin.umich.edu> ganesha@statler.engin.umich.edu (khurt lef williams) writes:

>	Anyone know where I can find the latest version of PKZIP?  I belive its version 2.0.

The latest official PKZIP is (stil) version 1.1. Version PKZIP 2.0 should
be comming soon (tm). There is a PKZIP 1.93 alpha version but this one
is buggy and PKWARE advices not to use it for serious work.

There are three major alternatives available currently. ARJ 2.30 (little
slower, comparable compression, more features, free for private use) and
InfoZIP 1.9, InfoUNZIP 5.0. These are portable PKZIP clones which are compatible
with PKZIP 1.1, PKZIP 1.93a and PKZIP 2.0 (according to PKWARE). Info is
freeware which as bonus is portable to UNIX, Mac, etc. Also ZOO is
interesting as the leading free portable archiver for OS/2 and UNIX.

>							-Khurt

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
Newsgroups: comp.compression
From: rsrodger@wam.umd.edu (Yamanari)
Subject: Re: Floppy Compression
Organization: University of Maryland, College Park
Date: Sun, 8 Nov 1992 15:59:39 GMT

In article <3300@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>Stacker 3.0 is capable of making such diskettes. I believe the compression
>decompession code on the diskette is royaltee free. SuperStor (Pro) also
>can make such diskettes but those can only be decompressed without
>SuperStor

	
	Stacker _3.0_???

	How nice of STAC to have notified me.  Gee, let me guess, there
	is no discounted upgrade price.. 



-- 
 /============================rsrodger@wam.umd.emu====================\
| Snout: O Bottom, thou art chang'd!  What do I see on thee?           |
| Bottom: What do you see?  You see an ass-head of your own, do you?   |
 \NeXTMail accepted here......I'd sell my soul for Offline mail!!!..../!
Newsgroups: comp.compression
From: franti@polaris.utu.fi (Pasi Fr{nti)
Subject: Re: bitmap compression
Organization: University of Turku, Finland
Date: Fri, 6 Nov 92 14:30:20 GMT

umfehr06@ccu.umanitoba.ca (John Fehr) writes:

>I'm currently looking for compression algorithms to compress weather charts.
>These charts contain about 95% white pixels, and 5% black pixels.  I've
>already thought of using GIF, but the files only shrink down to ~100k.
>(Originally ~1meg uncompressed.)  I've also thought of using arithmetic
>coding.  Does anyone have any suggestions as to other compression methods?

I have tested several methods for a little bit similar A4-size image with 
94,8% white pixels of total 2 miljon pixels (278kB).

        Method:                Ratio (1:N)      Speed (sec)
        -------                -----------      -----------
        PCX                       3,76               ?

        GIF                       7,05               ?
        CCITT G3-standard         7,23              22 (#)
        PKZIP -es                 8,17               1 (*)
        Block Coding              8,89               4

        CCITT G4-standard        16,36              24 (#)

        BQ-coder                 21,24              13
        Arithmetic Coding        21,86              64
        Q-coder                  21,86              36

(*) I used pkzip for the PCX-file.
(#) Alchemy's TIFF-format was used.

As you can see, it is a compromize of size and speed. All versions
of arithmetic coding (BQ, A, Q) gave good result but they are also
slower than for example Pkzip or Block coding. The arithmetic coders,
especially Q-coder (BQ includes Q-coder) are complicated methods, so
don't believe those who tell they are simple.

What format your weather maps are? Can you possibly send me one or two
files of them? I would like to use them as a test images also. 


----------
Pasi Fra"nti
franti@utu.fi
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: compressing gif files
Date: 11 Nov 92 19:00:38 GMT
Organization: Academic Computer Centre Utrecht

In <1992Nov8.114946.11060@ccsun7.csie.nctu.edu.tw> chuang@csie.nctu.edu.tw ( ** No Record **) writes:

>Dear user:

>    You can use the gifblast.exe find in CCCA Garbo/pc/gifutil/gifbla11.zip.

>The author anounce that program can save about 25 to 30 percent of space.

>Most important of all ,It's looseless compress(JPEG format is loosely compress)

>So it's not so efficient as JPEG format in saving space but save the resolution 
I am reasonably sure (the author of GIFBLAST mentioned it I believe) that
GIFBLAST does use lossy compression.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
Newsgroups: comp.compression
From: sh@cypress.com (Steve Haigh/VDSP)
Subject: ANNOUNCMENT - SHORT COURSE ON MPEG COMPRESSION
Originator: sh@kahuna
Organization: Cypress Semiconductor/San Jose, CA
Distribution: na
Date: Fri, 13 Nov 1992 16:51:06 GMT


Part 1: MPEG video. 9am - 5pm, Nov 30th -Dec 2nd 1992. $600.
Part 2: MPEG audio and systems. 9am - 5pm, Dec 3rd - Dec 4th 1992. $500.
Parts 1 and 2: $1000.
at the Techmart. Great America Parkway, Santa Clara, California.

This short course is designed for engineers, managers and professionals
seeking an overview of the key concepts and techniques in video and audio
compression for entertainment, communications and multi-media applications.
The presentation will not dwell on complex mathematical proofs and no
prior knowledge of video techniques or digital signal processing is assumed.
Instead, the course will lead participants through a descriptive and
substantive review of video and audio compression without getting mired in
complexity.

Presented by Steve Haigh, Director of video DSP, Cypress Semiconductor.

Part 1 introduces transform based video coding and the draft ISO standard
MPEG video compression algorithm.
Day 1:
o Applications for video compression.
o Overview of spacial, temporal and entropy coding.
o Motion video coding for MPEG and Px64 (h.261).
o Transform based coding of images.
Day2:
o Motion estimation and compensation of moving picture sequences.
o Entropy coding.
o Quantization, rate buffer control and encoding techniques.
o Performance requirement for real time coding and decoding.
Day3:
o MPEG 1 bit stream syntax.
o MPEG 2 work in progress.

Part 2 introduces MPEG audio compression layers 1 through 3 and the MPEG
systems layer.
Day 1:
o Psychoacoustics.
o Quadrature mirror filters.
o MPEG audio layers I and II.
o MPEG audio layer III.
Day 2:
o MPEG audio bit stream syntax.
o Performance requirement for real time coding and decoding.
o MPEG systems overview.

Attendance is limited to 30 people. Payment can be made with Visa, Master
Card or American Express.
Call 408 943 2904 for more details and registration.
Newsgroups: comp.compression
From: a7657@mindlink.bc.ca (Stephen H. Kawamoto)
Subject: Re: compression of small files
Organization: MIND LINK! - British Columbia, Canada
Date: Thu, 12 Nov 1992 23:20:45 GMT

> work well: means a good compression ratio, speed is unimportant.
>
> small files: means 1024 bytes or less.
>
> Or would a file of such a size be too small to effectively compress
> ?
Would this be repetitive data as in small database or spreadsheet files,
or text? The minimal size would still have to be greater than 14 bytes.
(My t{sts seem to indicate that the minimal size for a file with repetitive
data to effectively compress is about 14 bytes for LHA and ARJ but 7 bytes
for PKZIP.)

What this means is that for the source algorithms for compression within
these compression utilities, the algorithms in LHA and ARJ are probably the
same with minute variations and the smallest size that a stream of characters
can be represented is 13 bytes. On the other hand, PKZIP uses a small stream
of characters size, and the smallest size that can represent a group of data
characters is 6 bytes.

Of course the overhead of these methods leaves up with large PKZIP files due
to the large header, and smaller ARJ and LHA files even when the minimum file
size is less than the minimal (less than 14 bytes).

 Thus it stand to reason that there has to be a minimal file size that doesnt
result in an INCREASE in file size for the resulting compressed file. For
LHA, that is actually about 42 bytes; for ARJ, 110; and for PKZIP, about 120.
(This information is based on tests using a test file with 8 bytes of data
created by ECHO AAAA>test.txt and compressing the resulting file by each of
the utilities, LHA, ARJ and PKZIP. The resulting filesizes were used to make
a determination of the actually minimal file size. Note that perhaps a file
with a size 6 bytes less than given above might be the absolute minimal. What
this means is LHA has a 36 byte header for a 8 character filename with 6
bytes in it. ARJ, a 104 byte header. And PKZIP, a 114 byte header. Filesizes
also vary according to length of filename and the inclusion|exclusion of
pathnames into the directory structure in the resulting compressed file.)

 Of course, there are probably documents with better scientific method than
the ones I've employed (minimal ones in my case). The smallest size of a file
does depend on the filename length, inclusion|exclusion of pathnames as well
as the size of the file itself.

So the answer to your question: Or would a file of such a size be too small
to effectively compress ?

NO.



--
PGP 384/D7484F Stephen Kawamoto

a7657@mindlink.bc.ca.


UUENCODED on MIND LINK! Fri Oct 30 10:35:08 1992


begin 666 sign1a.pcx
M"@4!`0`````K`3L`+`$\`````/___P``````````````````````````````
M```````````````````````````!)@``````````````````````````````
M``````````````````````````````````````````````````#E_\'PY?_!
M\.7_P?#E_\'PY?_!\.7_P?#$_\'/X/_!\,3_P<_@_\'PQ/_!Q\W_/]+_P?#$
M_\''S?\
Newsgroups: comp.compression
From: chuang@csie.nctu.edu.tw ( ** No Record **)
Subject: Re:compressing gif files
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: TIN [version 1.1 PL6]
Date: Sun, 8 Nov 1992 11:49:46 GMT

Dear user:

    You can use the gifblast.exe find in CCCA Garbo/pc/gifutil/gifbla11.zip.

The author anounce that program can save about 25 to 30 percent of space.

Most important of all ,It's looseless compress(JPEG format is loosely compress)

So it's not so efficient as JPEG format in saving space but save the resolution 

of image. I have been using it recently ,No thing wrong until now why don't you

try it.

                                                             Sincerely yours.
From: gonzalem@ucs.orst.edu (M-FORCE)
Newsgroups: comp.compression
Subject: Compression of Raw Binary Data Sent via TCP/IP
Date: 9 Nov 92 05:12:27 GMT
Organization: College of Engineering, Oregon State University
NNTP-Posting-Host: ucs.orst.edu
X-Newsreader: TIN [version 1.1 PL6]


Greetings all.

I have a little project that I am working on.  It deals with the
transmission of huge amounts of raw binary data.. Right now I am using
sound files as my test subject.

We are using simple TCP/IP send/recieve routines and I would like to
know what type of compression that we could incorporate into the
program that would deliver good compression with the least impact
upon speed.  So if we were gonna send sound or video what type
of compression would give the best performance.

If their happens to be code available we are writing the preliminay
program in Pascal.

The transfer rates are as follows:
11Khz audio file. sending via TCP/IP as fast as we can.

Thanks for any help of info that you may be able to provide.

Also what other packet schemes would we want to look into.  TCP/IP
has a fair amount of overhead to ensure the proper transmission and
order of recieved packets.  we need that but is their a better way?

Thanks

Mario Gonzales
Newsgroups: comp.unix.aux
From: root@machost (Operator)
Subject: AUX 3.0 and the IIVX - install -> NO
Organization: Novell, Inc.
X-Newsreader: Tin 1.1 PL3
Date: Fri, 6 Nov 1992 00:51:30 GMT

Also wanted to let everyone know what they are up against with AUX and the 
IIVX systems...

I tried the normal IICI install and the Quadra install... both said that the
system software level was not supported on the Vx

	point 1 - the VX REQUIRE 7.1, AUX is not compatible with 7.1
		This affects other that may want 7.1 but have a Quadra
		or a IIci

I made a 7.1 install disk... by transferring the System files from the 
7.1 install onto a copy of the AUX install disks.  
	point 2 - 7.1 is too large for a 1.4 meg disk with the AUX install
		stuff on it... and the fonts folder is a new novelty that
		may be the cause of problems.

I formated a hard disk to use as an install disk rather than a floppy.  Got
all of the system stuff straightened out, or so I thought and proceeded to 
try and install... IT WAS ACTUALLY WORKING....
Then after the load hit a certain point, the screen went grey (this is normal
in the install... remember the screen blanks and the load banner comes back to 
finish).  With this install the loading banner never came back, the system
was hung.  So I thought to myself, the video is different (per Apple the IIVX
uses the LCII video scheme).  
	point 3 - the internal video seems to be incompatable.

Not to be discouraged, I installed a TOBY video card (known to work with
AUX on the IICi if you did not want to use internal video and slow the 
machine down....Same thing happened as before..
	point 4 - standard video did not make a difference.

I can see nowhere else to go except to hound apple about this...If anyone 
knows someone high enough in Apple to get results, yet low enought to listen
to me about this please let me know about him/her.  I understand that a new
director of AUX vars was created... If someone knows how to get to him let 
me know.


	


--

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mike Cederholm....
mike_cederholm@novell.com
mike_cederholm@npd.novell.com
++ or IF you prefer talking to a human ?? (801)-568-8681 - daytime ++
   << No Man is an Island, although many are good candidates.... >>

Newsgroups: comp.unix.aux,news.answers
From: aa550@cleveland.Freenet.Edu (Don Zolinski)
Newsgroups: comp.unix.aux
Subject: unix shareware
Date: 7 Nov 1992 20:10:29 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: aa550@cleveland.Freenet.Edu (Don Zolinski)
NNTP-Posting-Host: thor.ins.cwru.edu

Does anyone know of a program that could be used to test
short unix,A/UX script on the mac without installing A/UX?
Newsgroups: comp.unix.aux
From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Subject: Re: Yet more about 'tc' (blocking issues)
Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Organization: NASA/Goddard Space Flight Center
Date: Thu, 12 Nov 1992 12:35:42 GMT

tody@noao.edu (Doug Tody) writes:

>The 8k limitation is a minor nusiance for A/UX-only usage, e.g., file backups,
>but is a MAJOR problem if the tape drive is to be used to transfer data to or
>from an external, non-A/UX system.

>A variable record size is preferred over a fixed block size since for some
>tape formats the record size may have some meaning, and since variable size
>records cause fewer transport problems.  If fixed size blocks are used, one
>system may use, e.g., 1k blocks and the other 8k blocks, and it may not be
>possible to read the tape.

I've seen most drivers use fixed block and not variable. Unless, of course,
they're driving 9-track... The most common form of tape drivers are those
that implement blocks via a raw device. This allows sequential and indexed
I/O. Of course, this means that you need to have fixed block sizes.

>Cartridge drives support only fixed size blocks, but DAT and Exabyte are
>capable of a variable record size mode as well as a fixed block mode
>(variable record size mode is enabled by setting the device block size to 1
>byte; in variable record mode each read returns one record).

Actually, you must set the Block Length parameter in Mode Select to 0.
Some also require a bit to be set. Some (such as the Sony DAT) also
require a Fixed Bit Field be set in READ and WRITE...

I believe the "default" for these drives is fixed length though...

>                                                             9 track reel
>tape drives support only variable size records.  For DAT and Exabyte a good
>driver will provide different device entries for fixed block mode i/o and
>variable size record i/o, so that the user can decide which to use.  If the
>device is capable of compression, there should be different device entries
>for compression mode and non-compression mode as well.

Ahhh infinite resources would definately help make this so... How about
a driver that also plays a little trumpet fanfare when it ejects a tape? :)

Seriously though, variable block sizes would be a good addition and
most probably will be added to 'tc' after a while. The trick is getting
all the information about it to implement it. Until then, it is possible
to filter the output to the tapes on the Suns thru a little application
that'll block output at 8k (or the tape'd physical block size)? Or is it
too much to expect Suns to "compromise" but Apples have to??

Cheers!
-- 
    Jim Jagielski               | "It is not I who am crazy...
    jim@jagubox.gsfc.nasa.gov   |  it is I who am MAD!"
    NASA/GSFC, Code 734.4       |
    Greenbelt, MD 20771         |            - Ren
Newsgroups: comp.unix.aux
From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Subject: Re: POLL: Which tape drive to buy?
Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Organization: NASA/Goddard Space Flight Center
Date: Tue, 10 Nov 1992 10:59:45 GMT

Mike_Peters@vos.stratus.com (Mike Peters) writes:

>Just when you thought the polls were over...

>I'm contemplating the purchase of a tape drive for my Mac to use with A/UX
>and the MacOS.  I have two primary goals:

>1.	Compatibility with other Unix systems.

>2. Speed and capacity.

>I'm most familiar with DC6000 compatible drives, however, I understand that
>4mm DAT and 8mm drives are becoming more popular and hold more data.

There is currently a big push towards the new generation of DC drives.
I know few specifics but I'm sure there will be some bugs and pains in
getting them out and available.

For my money, you can't beat DAT. Fast (esp. with compression drives),
cheap and reliable. You can get top notch units for about $1300-$1600
but when you figure that a single 90m tape will hold around 5-8GB of data
(and the tape costs maybe $25) then you see the advantage.

I used the Teac 150's for a while and have nothing but favorable comments
about them. For smaller systems, the 150 or 600 (which I haven't used)
seem quite good.

The problem with compatibility is that systems use different blocking
factors when reading/writing tapes so just because you can hook up
your Exabyte to you Mac, a Sun and an HP doesn't mean that you'll be
able to read the tapes...
-- 
    Jim Jagielski               | "It is not I who am crazy...
    jim@jagubox.gsfc.nasa.gov   |  it is I who am MAD!"
    NASA/GSFC, Code 734.4       |
    Greenbelt, MD 20771         |            - Ren
Newsgroups: comp.unix.aux
From: koch@eis.cs.tu-bs.de (Andreas Koch)
Subject: ** HELP **: Can't read backup tape!!
Organization: TU Braunschweig,Informatik,EIS,West Germany
Date: Sat, 7 Nov 1992 22:44:34 GMT

(taking three deep breaths, calming down)
I am confronted by the following problem:

I made a backup DAT under A/UX 2.0.1 using Tony Cooper's
st driver (generic) using a WangTEK 6130-HS DAT drive
and the following command:
	dump.bsd -T4.2 0unbsf 64k 1300m / | tbb >/dev/rmt/nrst

This backup must have worked, since I have restored various
files using it.

Now, I have installed A/UX 3.0 plus Jim Jagielski's tc driver,
since it supports the WangTEK directly and st has again expired.
But when I try to use the command (and various permutations thereof)
	restore -T4.2 ivbf 64k /dev/rmtc
I get only the message
	no header after volume mark
and the restore aborts. Can anyone help me to restore the backup
or have I lost more than 500MB of data, accumulated over 4 years?

I don't think that the WangTEK is broken, since testdrive works perfectly
and backups created using A/UX 3.0 dump.bsd can be read using A/UX 3.0
restore. However, A/UX 2.0.1 restore is unable to read the 2.0.1 backup
under A/UX 3.0. What has happened? Are the tape formats written by
st and tc incompatible? If so, where can I get a non-expired version of
the generic st driver? Or do I have to play games with the system clock?
_ANY_ hints are appreciated!

Panicking,
	Andreas Koch
Newsgroups: comp.unix.aux
From: m211037@regen.DKRZ-Hamburg.DE (Martin Heimann)
Subject: setting A/UX up for receiving mail
Organization: Deutsches Klimarechenzentrum GmbH, Hamburg
Date: Fri, 6 Nov 92 08:19:30 GMT

Could some kind soul instruct me how I set up my A/UX system such that it
can send mail to the outside? At present I can only receive mail from the network. I know that one has to start the sendmail
program, however, I do not have the administration manuals that describe
all the necessary steps. 

Martin 

-- 
----------------------------------------------------------------------
"If you fail to prepare - prepare to fail"


				Martin Heimann
				Max-Planck-Institut fuer Meteorologie
				Bundesstrasse 55
				D-2000 Hamburg 13
				Germany

				phone:	+49 40 41173 240
				fax:	+49 40 41173 298
				email:	heimann@dkrz-hamburg.dbp.de
From: J.Pearce@cs.ucl.ac.uk (John Pearce)
Newsgroups: comp.unix.aux
Subject: PPP (or Morning Star) for A/UX 3.0
Date: 5 Nov 92 16:43:09 GMT



Can anyone tell me if PPP or its commercial replacement (Morning Star
?) are ported/available for A/UX 3.0 ?

Many thanks,

John Pearce.

jpearce@cs.ucl.ac.uk