HDTenEightyP/NetNews huggingface dataset:
From: wardrb@cs.utexas.edu (Richard Byron Ward)
Newsgroups: comp.compression
Subject: Re: compressing gif files
Date: 11 Nov 1992 18:33:12 -0600
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: im4u.cs.utexas.edu

In article <3309@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
|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.
|
The main selling point of GIFBLAST is that it performs lossless compression,
it's certainly not speed!  The author did mention that the decompressed
GIF may not match the original because of slight variations in the way that
different programs encode GIFs, but that the information is unchanged.

Rick
From: vinaya_s1@verifone.com
Newsgroups: comp.compression
Subject: MultiVolume Zoo Wanted.
Date: 27 Oct 92 21:50:29 -1000
Organization: VeriFone Inc., Honolulu HI

Hello !
	I am interested  about the multivolume archiver zoo
( rahul dhesi's zoo ). I read that it is available. Please 
inform me on where to find it. I am interested in the multivolume zoo's ports
to MSDOS, QNX.
Please send replies by email.
Thanks
Vinaya S.
email : vinaya_s1@blrv1.verifone.com
----
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Executable file compressors wanted
Date: 7 Nov 92 16:51:28 GMT
Organization: Academic Computer Centre Utrecht

In <1992Nov6.100628.3170@htsa.aha.nl> benc@htsa.aha.nl (Ben Castricum) writes:

>Hi everybody, I would like some help with my program..

>I am working on a program that expands compressed executables.
>Something like DISLITE or UNLZEXE but I want to decompress all files
>with one program.

That is relatively easy to do if you let the decompression stub do the
decompression (DISLITE works that way, UNLZEXE has a real decompressor
integrated).

>-- COM files --
>DIET V1.10a	{
>DIET V1.20	{

Please notice there is a DIET 1.44 already. Also notice the newest
DIET has multiple options for decompression (speed ot size, BTW
always go for speed!)

>Anyone who has send me an addition to my collection or in another way improved
>my program can receive the latest version of it.
>To make this interresting:
>It's able to make normal pklited files unextractable, even dislite v1.01 can't
>handle them! (ofcourse it's just a simple trick)

The new DISLITE will probably solve this (the author is quite busy at the
moment but knowing him he will come back ..... :-))

You didn't mention EXECUTRIX. 

>Ben.

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.
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: compressed files salvagable?
Date: 6 Nov 1992 18:00:18 GMT
Organization: California Institute of Technology, Pasadena
Distribution: usa
NNTP-Posting-Host: sandman.caltech.edu
Keywords: lempel-ziv, compression, compress(1)


>> Most versions will also reset the table when the compression worsens, so
>> it would be possible for compress to reset before it fills up.  In this case

Actually, no.  From the comments in compress.c:

 * to a faster exclusive-or manipulation.  Also do block compression with
 * an adaptive reset, whereby the code table is cleared when the compression
 * ratio decreases, but after the table fills.  The variable-length output
 * codes are re-sized at this point, and a special CLEAR code is generated

>> It's also possible that the entire lost block was composed of an already-
>> seen prefix.  The odds of this happening are pretty slim though.  You may

I don't understand this comment.  As far as I can tell by perusing the
source, clear really means clear, and there is no history of the file
kept from before that point.

Mark Adler
madler@cco.caltech.edu
From: madere@austin.ibm.com (Steve Madere)
Newsgroups: comp.compression
Subject: Readable LZW source code?
Date: 9 Nov 92 21:32:35 GMT
Reply-To: madere%aixserv@uunet.uu.net
Organization: IBM Austin
Originator: madere@julius.austin.ibm.com



  Does anybody know of publicly available source code containing 
  LZW compression in a comprehensible form?

  What I'm really looking for is a routine like this in C:

  LZWCompress(char *source,int srclen, char **dest,int *destlen);

  Or even better yet...

  LZWCompress(LZWDictionary *dictionary,char *source int srclen,
	       char **dest,int *destlen);
   
  Ideally, the code within this routine would be easy to understand
  and reasonably well documented.  And maybe even well-structured
  with subroutines here and there!

  I need to modify the algorithm slightly so I'd like some code that
  is reasonably easy to understand.

  I've looked at the compress 4.0  source code and it's a real mess!

  The FAQ only lists locations for some compression programs but
  they all seem to be file compression oriented and optimized like crazy
  (basically unreadable) as well as adapted to every weird non-virtual
  memory architecture known to mankind (another "feature" that leads
  to difficult reading).
  
  Any help would be much appreciated.

Steve Madere
madere%aixserv@uunet.uu.net


-- 

Steve Madere
(Do not reply with R! use the following address)
madere%aixserv@uunet.uu.net
Newsgroups: comp.compression
From: hugh@cantua.canterbury.ac.nz (Hugh Emberson)
Subject: Re: bitmap compression
Organization: University of Canterbury, Christchurch, New Zealand.
Date: Fri, 6 Nov 1992 06:42:01 GMT

In article <Bx9C19.4r2@ccu.umanitoba.ca>, 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?

You could try Group 4 fax, but I wouldn't expect it to be much better than GIF.

Probably the best method would be an arithmetic encoder with a template model. 
Have a look in:

@article{Langdon81,
   author = {Glen G. Langdon, Jr. and Jorma Rissanen},
   journal = {IEEE Transactions on Communications},
   month = jun,
   number = {6},
   pages = {858--867},
   title = {{C}ompression of {B}lack--{W}hite {I}mages with 
					{A}rithmetic {C}oding},
   volume = {COM-29},
   year = {1981}
}


and:


@inproceedings{Moffat91,
   author = {Alistair Moffat},
   address = {Los Alamitos, California},
   booktitle = {{P}roceedings of the {D}ata {C}ompression {C}onference 1991},
   editor = {James A. Storer and J.H. Reif},
   pages = {382--391},
   publisher = {{IEEE} {C}omputer {S}ociety {P}ress},
   title = {{T}wo level context based compression of binary images},
   year = {1991}
}

[The above is in BibTeX format, just strip out the {braces} to read it.]

I understand that this method is/will be  used in the JBIG standard.  It is
very good and very simple.



Hugh
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Which will come first?
Keywords: PKZIP
Date: 9 Nov 92 17:03:00 GMT
Organization: Academic Computer Centre Utrecht

In <ksiew.721211744@munagin> ksiew@mullian.ee.mu.OZ.AU (steven kok-hsien siew) writes:

>  Which will come first?        
> 
>  The second coming of Christ or the second coming of PKZIP? 

:-)

The latest rumours I have (and I try anything to get those :-)) where
begin November (which is about now). I am out of rumours now. Perhaps
they wait for Comdex to release it to the public. Or perhaps they
still didn't figure out why the WEB engine they bought didn't work :-)

It is also possible they are working on a completely new archiver much
better than 1.93a in a secret project. 

>The only people who believe that unlimited | Steven Siew  tel 03 803 4662

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.
From: omahony@swift.cs.tcd.ie
Newsgroups: comp.compression
Subject: Re: U-Law Encoding....HELP!!!!
Date: 11 Nov 92 17:39:00 GMT
Organization: Computer Science Department, Trinity College Dublin

In article <1992Nov10.163040.27563@rmece49.upr.clu.edu>, julior@rmece02.upr.clu.edu (Julio A. Rodriguez) writes:
> 
> 	I've been working with the program PLAY and RECORD.  RECORD produces a
> file with a .au extension and is supposse to use the U-LAW encoding method.
> I need to decode this data to be able to process this information usign FFT.
> If you got any ideas on how to do so please send me your ideas.  Thanks.
>

Mu-Law encoding involves passing the analogue signal through a compressor
that conforms to the Mu-Law before quantizing it.  I expect what you
need to do is to "expand" the digital values by performing the reverse
transformation on the digital values held in the file.
 
According to "Principles of Communication Systems", Taub & Schilling,
McGraw Hill, 1986 pg 245

A Mu law compressor relates input to output by the relation


y  = +   log(1+mu/x)
     -  ______________
         log(1+mu)

the plus sign applies when x is positive, and the minus sign is used when
x is negative

where x = Input Voltage/ V and
      y = Output Voltage/ V
      range of allowable voltages is -V..+V
     

The parameter mu determines the degree of compression, and a common value is
255

__________________________________________________________________________
Hope this helps!

Donal O'Mahony,             omahony@cs.tcd.ie
Computer Science Dept
Trinity College
Dublin 2
Ireland
Xref: sparky comp.compression:3752 comp.compression.research:260 comp.graphics:11568 sci.image.processing:1113 alt.graphics.pixutils:2571 misc.books.technical:1637
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: compression of small files
Keywords: small files 1024 bytes
Date: 13 Nov 92 01:09:05 GMT
Organization: Academic Computer Centre Utrecht

In <1992Nov11.210509.20715@cbnewsj.cb.att.com> jef0@cbnewsj.cb.att.com (john.e.fetchko) writes:


>Does anyone have information on any compression routines
>that work well on the compression of small files ?
>     ^^^^^^^^^                       ^^^^^^^^^^^ 

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

If you have a collection of small files binding them together and
compressing the bunch at one might be an idea (disadvantage is
slow access to last file etc).

If you want a single small file to compress well use a static dictionary.
For small .C file for example this one would contain "#include" file etc.

Both ways do not need a slow compressor. A static dictionary will make
compression slower because the dictionary will have to be parsed
into the hash chains.

If you can't use a static dictionary because the small files are
unpredictable use higher order arithmetic compression. If that
fails give up :-)

>Thanks in Advance,
>John Fetchko
>...att!attmail!jfetchko
>(908) 457 - 6429

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.
From: sv@id.dth.dk (Stig Valentini (920401#PF))
Newsgroups: comp.compression
Subject: PKZIP 1.93 bug!
Date: 11 Nov 92 13:19:18 GMT
Organization: Department of Computer Science


PKUNZIP -t * sometimes gives a CRC errors which doesn't occurs when you
unpack or test the files individually. Not surprising when you remember
that the v1.93 is a beta version.                
Newsgroups: comp.compression
From: ksiew@mullian.ee.mu.OZ.AU (steven kok-hsien siew)
Subject: Which will come first?
Keywords: PKZIP
Organization: Computer Science, University of Melbourne, Australia
Date: Sun, 8 Nov 1992 08:35:44 GMT

  Which will come first?        
 
  The second coming of Christ or the second coming of PKZIP? 

-----------------------------------------------------------------------------
The only people who believe that unlimited | Steven Siew  tel 03 803 4662
growth can take place in a finite system   | ksiew@munagin.ee.mu.oz.au
are madmen or economists. Spaceship earth: | Don't call me! Gundam me! 
-----------------------------------------------------------------------------
Newsgroups: comp.compression,comp.sys.mac.apps
From: cuffell@spot.Colorado.EDU (CUFFELL TIMOTHY MICH)
Subject: InfoZip
Organization: University of Colorado, Boulder
Date: Fri, 13 Nov 1992 05:16:03 GMT

I just grabbed the InfoZip zip and unzip, and they work great for my Unix
account.  I noticed they had makefiles for various DOS compilers.  Is there
any compelling reason why I should use InfoZip rather than Pkzip?  



-- 

-Tim Cuffel
Newsgroups: comp.compression
From: ganesha@statler.engin.umich.edu (khurt lef williams)
Subject: Latest PKZIP.
Date: Sat, 07 Nov 92 17:42:24 EST
Organization: University of Michigan Engineering, Ann Arbor
Originator: ganesha@statler.engin.umich.edu


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

							-Khurt
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Floppy Compression
Date: 9 Nov 92 17:05:09 GMT
Organization: Academic Computer Centre Utrecht

In <1992Nov8.155939.27048@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari) writes:

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

I don't beleive it has been released already. Latest I heard was about
a final BETA stage of 3.0 for DOS and for OS/2 2.0 (althought I don't
know if the OS/2 2.0 version is Stac 2.0 or 3.0).

> /============================rsrodger@wam.umd.emu====================\

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.
From: zhao@nmsu.edu (Z. Zhao)
Subject: test of video compression
Reply-To: zhao@nmsu.edu
Organization: Computing Research Lab
Distribution: comp.compression
Date: Thu, 12 Nov 1992 21:14:29 GMT

Besides eye-acceptability, do we have other measurements to 
test the quality of decompressed video pictures from different 
compression algorithms and programs?

Recently, I have read and saw something about video compressions.
But, it seems that there is no certain way to tell people how 
good or how bad these reproduced images are, i.e., there is no defined
technical standards to classify those images. Maybe, there are some
common test methods, but I just haven't learned them. Do you know
some of these methods to test compressed-decompressed video images?
 
Many vendors just show us the video pictures and tried to tell us they
were PERFECT. It is possible other people can not see the difference
between the original and reproduced ones, but I alway can. I ask for
measurement data, or technical data and curves about the image quality,
they don't have.  Eye-acceptability? it doesn't sound so technical to
me. :-) :-) :-) 

ZiZi
From: markp@adsi.homecare.com (Mark Parr)
Newsgroups: comp.compression
Subject: PKZIP/PKUNZIP current version
Date: 7 Nov 92 17:36:23 GMT
Organization: Application Data Systems, Inc.

I posted a similar message a couple of weeks ago, but we lost our Usenet
feed for several days so I never got a response....

Can anyone tell me the most current and valid version number for PKZIP and
PKUNZIP?

Thanks,
Mark


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 | |-------------|  Application Data Systems     |  Phone: (601) 393-2046  | |
 | |  Mark Parr  |  1930-B 1st Commercial Dr. N  |    Fax: (601) 393-6605  | |
 | |-------------|  Southaven, MS 38671          |    markp@adsi.vp.com    | |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: Latest PKZIP.
Date: 8 Nov 1992 17:32:52 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


To clarify what Nico said:

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

True, but InfoZIP 1.9 is not compatible with pkUNzip 1.1--InfoZIP 1.9 only
uses the newer compression method introduced by PKZIP 1.93 and (the ever-
promised) PKZIP 2.x.  There is also an InfoZIP 1.1 for generating zip
files compatible with PKUNZIP 1.1.

InfoUNZIP 5.0 works with all the formats (1.1 and 1.93).

Mark Adler
madler@cco.caltech.edu
Newsgroups: comp.compression
From: tgl+@cs.cmu.edu (Tom Lane)
Subject: Re: Review: "JPEG Still Image Data Compression Standard"
Summary: oops, wrong phone number
Keywords: JPEG, book review
Organization: School of Computer Science, Carnegie Mellon
Date: Fri, 6 Nov 1992 21:13:39 GMT

It seems Van Nostrand Reinhold has recently changed their phone number.
If you're thinking of ordering the JPEG book, call
        Phone: 800/842-3636       Fax:   600/525-7778
*not*
        Phone: 800/926-2665       Fax:   600/525-7778

Sorry for the misinformation.

				tom lane
Newsgroups: comp.compression
From: cc2955@thor.albany.edu (Charley Chen)
Subject: hpux
Organization: State University of New York at Albany
Date: Fri, 6 Nov 92 02:44:03 GMT

Does anyone know how to uncompress a file with the extension .hpux?
I don't know what software is needed so the more info the better.
I don't read the newsgroup very often so if you so kindly send me the
response by e-mail I would greatly appreciate it :)


					Thank You

					Charley


Newsgroups: comp.compression
From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn)
Subject: Re: U-Law Encoding....HELP!!!!
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
Organization: CSD., University of Erlangen, Germany
Date: Fri, 13 Nov 1992 13:17:38 GMT

julior@rmece02.upr.clu.edu (Julio A. Rodriguez) writes:

>	I've been working with the program PLAY and RECORD.  RECORD produces a
>file with a .au extension and is supposse to use the U-LAW encoding method.
>I need to decode this data to be able to process this information usign FFT.
>If you got any ideas on how to do so please send me your ideas.  Thanks.

The mu-law coding method (it's the greek letter mu, not a U) is defined in
CCITT recommendation G.711. You should find this in the CCITT Blue Book
or CCITT Red Book (old version) in a good library or perhaps an unofficial 
version in some ftp cites.

The mu-law encoding is just a table (defining a funktion) that transforms
a linear 12-bit sample value in a 8-bit value. This is obviously a
lossy 3:2 (= 1:(2/3)) compression method. The table comes from a
logarithmic quantization function.

The decoder has a smaller table that gives a 12 bit value for every
of the 256 possible 8-bit input value.

G.711 defines also the a-law coder.

Hope this helped.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
--- Wer, wie, was? Wieso, weshalb, warum? Wer nichts fragt bleibt dumm. ---
Newsgroups: comp.compression
From: rdippold@qualcom.qualcomm.com (Ron Dippold)
Subject: Re: pkzip 3.05
Organization: Qualcomm, Inc., San Diego, CA
Date: Wed, 28 Oct 1992 19:10:54 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
>The message you are forwarding is completely bogus. It is obviously
>designed as a prank. Anybody who understands at least a little bit of
>computer viruses should be able to see this. The properties of the
>"virus" described in it are just IMPOSSIBLE.

I loved the part about it hiding "in the modem port"... heh.
-- 
Ted Kennedy is leading the fight against sexual harassment:  He's promised to
turn state's evidence.
From: dave@gctech.co.jp (Dave)
Newsgroups: comp.compression
Subject: Re: Review: "JPEG Still Image Data Compression Standard"
Date: 11 Nov 92 06:28:59 GMT
Organization: GC Technology

In article <1992Nov9.011027.29183@cs.wayne.edu> bhh@loki.cs.wayne.edu (Bhaskar Holur) writes:
   Hi, I am doing a project on video compression using ...
   the MPEG algorithm....

   1.  I am looking for an image sequence (video sequence preferably)
       512x512 (or 256x256) gray-scale, 8 bit/pel quantized, suitable
       for use on Sun Sparc 4 station terminal.

       Actually, if anyone knows or has a good test sequence for the
       simulation of MPEG, it would be best.

If you're simulating MPEG, you may want to use one of the standard CCIR601
formatted test pictures.  They are YUV with 720 pels per line by 488
lines.  "Flower Garden" is probably the most often used sequence.  Mail me
if you want to FTP it.


   2.  Although I got quite some info from various tech. papers,
      especially from Proc., SPIE about MPEG and various motion-compensated
      prediction/interpolation encoder development and various motion-
      estimation techniques, and an overview on MPEG as well, I need more
      info for the exact implementation details for the encoder. (esp.
      for software simulation)

The exact implementation details of the coder were purposefully left out
of the standard.  You can implement the coder any way you want as long as
the output conforms to the definition of an MPEG bit stream.  The aim is
to get companies who think they can make a good coder to cooperate in the
standardization process.  There is some public domain software available,
or at least semi-public.  I have heard of some at Columbia University, but
I don't know where yet.


   I did try to ftp into isy.liu.se for some image sequences. I was
   not able to convert from the .imf format.  When I went into the
   vi editor to strip the header from the .imf file, it said line
   too long!???

Your first mistake is using the vi editor.  Learn Emacs.  Your second
mistake (though some may disagree) is using a text editor to modify an
image file.  I've never used the .imf format, but I imagine it is not
composed of only ASCII characters.

Dave
From: ericb@hplsla.hp.com (Eric Backus)
Date: Fri, 30 Oct 1992 18:30:25 GMT
Subject: Re: tar.Z
Organization: HP Lake Stevens, WA