HDTenEightyP/NetNews huggingface dataset:
From: jloup@nocturne.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: HELP: Need Message Signature (e.g. MD4 Message Digest Algorithm)!!!
Date: 29 Aug 92 19:43:43 GMT
Reply-To: jloup@nocturne.fr (Jean-loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France

dathomps@vela.acs.oakland.edu (dathomps) writes:

> I've looked on wuarchive, on garbo, and in the FAQ's and
> I cannot find any information on the Message Digest Algorithm.

You are posting to the wrong group. sci.crypt would be more
appropriate. Anyway, what you are looking for is available by ftp on
rsa.com in directories /pub and below.

Jean-loup Gailly
Newsgroups: comp.compression,comp.dcom.modems,comp.protocols.misc,comp.protocols.tcp-ip
From: pauln@nuustak.csir.co.za (Paul Nash)
Subject: Any experiences with Compressing TDMs?
Organization: Infotek, CSIR
Date: Fri, 04 Sep 92 09:39:38 GMT
Keywords: compress TDM multiplexor leased-line satelite

We are considering installing a pair of Symplex Datamizer compressing
TDMs, to optimise the use of an international leased line.  However, we
would like to find out others' experiences first.  For those who don't
know, the device is basically a TDM with a data compressor attatched to
the aggregate channel.

We would like to know of any good or bad experiences in the following
areas:

1) Reliability:  

2) Throughput:  the local marketing people claim 4:1.  From experiences
                with modems, I would guess that 2:1 is a better bet in
		the real world, but would like to hear what sorts of
		throughput people actually get.

3) Satelites:  we want to use these over a satelite link.  Does the
               increased latency have any nasty side-effects?

The types of traffic that we plan to shove down the line include X.25,
SL/IP or PPP and SNA (perhaps).

If there are any other comments, or other products, I would appreciate
the info.  Mail or posting is great, and I will summarise any mail I get,
if there seems to be any interest.
-- 
 ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
 Paul Nash                                         paul@frcs.Alt.ZA
 Box 12475, Onderstepoort, 0110 South Africa         +27-12-8413050

     "God isn't dead, He's just metabolically challenged" -- me
Newsgroups: comp.compression
Subject: JPEG style compression on radar height data
From: epoo1@cs.aukuni.ac.nz (Edouard Poor)
Date: Thu, 27 Aug 1992 02:49:21 GMT
Organization: Computer Science Dept. University of Auckland

Just wondering of anyone has had any experience with storing height data
(terrain maps, down to, say, a 5m grid) with lossy techniques such as
JPEG?

The situation in which I would like to apply this doesn't really require
very high accuracy in the data, but the amount of data to be stored may 
well be astronomical (or at least the budget for storage media will :-)

By inspection I would say that JPEG might do a very good job, but I was
wondering if there was anything in the way of tech reports/thesis/articles/
personal experience in this area before I jump in head first (a lot
of the data will be coast lines and thus will be able to have all the
sea portions eliminated, a quad tree representaion might do a good
job, perhaps as a preprocess...)

Thanks in advance,
Edouard
Newsgroups: comp.compression
From: dec@gtech.com (Dehe Cui)
Subject: Re: comp.compression FAQ (reminder)
Keywords: data compression, FAQ
Organization: GTECH Corporation, West Greenwich, RI
Date: Fri, 28 Aug 1992 12:31:49 GMT
From: reisert@mast.enet.dec.com (Jim -- DTN 223-5747 -- Moved to MLO5-2/13A)
Newsgroups: comp.compression
Subject: MS-DOS ZIP 1.9 - How much memory needed?
Date: 1 Sep 92 01:05:21 GMT
X-Received: by usenet.pa.dec.com; id AA08960; Mon, 31 Aug 92 18:05:53 -0700
X-Received: by enet-gw.pa.dec.com; id AA06366; Mon, 31 Aug 92 18:05:21 -0700
X-Received: from mast.enet; by decwrl.enet; Mon, 31 Aug 92 18:05:21 PDT
X-To: comp.compression.usenet
X-Apparently-To: comp.compression.usenet

I shelled out of a DOS program, and have 279K free according to 4DOS.

However, when I try to ZIP some files, I get the error message:

	Out of memory (window allocation)

Is this because the DOS program is running in a DOS compatibility box under
OS/2, and I have the wrong type of memory? Is my environment too small?
Here's what 4DOS says I have:

    655,360 bytes total DOS RAM
    279,552 bytes free

  2,490,368 bytes total EMS memory
  1,900,544 bytes free

  2,031,616 bytes free XMS memory  (HMA in use)

      1,024 bytes total environment
        278 bytes free

So what's going on?

- Jim

--
Jim Reisert                     Internet:  reisert@mast.enet.dec.com
Digital Equipment Corp.         UUCP:      ...decwrl!mast.enet.dec.com!reisert
146 Main Street	- MLO3-6/C9	Voice:     508-493-5747
Maynard, MA  01754		FAX:       508-493-1890
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Where is freeze?
Date: 28 Aug 92 13:56:55 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

Someone asked me about freeze the other day, and all I have is an old
version. I think I saw something on it recently, but I don't remember
where. Can someone jog my memory?

Mail is fine unless there's a big demand for this info.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.compression
From: roland@sun-2.cs.uct.ac.za (Roland Paterson-Jones)
Subject: Best compression technique & ratio for (ascii) text
Organization: Computer Science Department, University of Cape Town
X-Newsreader: Tin 1.1 PL5
Date: Thu, 3 Sep 1992 08:10:35 GMT

Sorry if this is a FAQ, but I am interested in knowing what compression ratios
are possible for English text in ascii. Unix's compress (adaptive Lev-Zimpil)
claims 50-60% for such files. Is this as good as can be done? Quick
decompression would be essential.

Thanks for any responses...
--
Roland P-Jones			aka roland@uctcs.cs.uct.ac.za
University of Cape Town		 or roland@sun-2.cs.uct.ac.za
South Africa
Xref: sparky comp.compression:3083 comp.sys.ibm.pc.hardware:22634
From: rfrost@degas.jrc.flinders.edu.au (Richard Frost)
Newsgroups: comp.compression,comp.sys.ibm.pc.hardware
Subject: WANTED: Help on Fluent PC CODEC & Fluent's email address
Date: 24 Aug 92 14:15:06 GMT
Organization: CSIRO/Flinders Joint Research Centre in Information Technology


We have purchased the Fluent real-time video codec add-in card for a 
a PC. We have a problem (described below) and have faxed them twice 
with no response.

Now, I recall someone mentioning their email address a while back..
does it exist? Are they on the Internet at all?

If there are ANY users of this product out there, PLEASE contact me
via email, it would be could to exchange bugs found in Fluent's API
for instance or plain simple untruths in their documentation (ie.,
Fluent touts support for NETWORKED APPLICATIONS when their API has 
no such support!). 


PROBLEM:

    Fluent says that their board can decompress compressed
video and compress live video at the same time. ie.. you
would have 2 windows, one showing the live source (being compressed), 
the other showing a playback of a compressed video sequence.

However, this is not the case, and from looking at the API, this
is impossible... 

Does anyone know about this?.. please email replies.

Thanks.




--
.--------------.------------------------------------------------------------.
|Richard Frost | Internet Address :    rfrost@jrc.flinders.edu.au           |
.--------------^------------------------------------------------------------|
| Phone:       |    CSIRO/Flinders University Joint Research Centre in      |
|+618-201-3651 |Information Science and Technology Adelaide, SOUTH AUSTRALIA|
`---------------^-----------------------------------------------------------'
Newsgroups: comp.compression,comp.graphics.avs
From: haggas@kean.ucs.mun.ca
Subject: Searching for specific uuencode.exe
Organization: Memorial University. St.John's Nfld, Canada
Date: Thu, 3 Sep 1992 17:27:34 GMT

I'm seaching for an anonymous FTP site of a self-expanding format of a 
specific DOS related uuencode/uudecode program. The program is: QUUNCD 
Ver1.2, Copyright 1988,1989 by Theodore A. Kaldis.

Your help would be appeciated. There are two others on 
comp.graphics.avs who like this information, also. If I get this, I'll
send it to them.

Thankyou.
John Haggas
haggas@kean.ucs.mun.ca
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: new better than jpeg?
Organization: California Institute of Technology, Pasadena
Distribution: comp
Date: Thu, 27 Aug 1992 16:28:59 GMT


>> powered by the C-Cube chip.  They announce their method as being
>> different from and better than JPEG.  Their software also deal with JPEG

Highly likely.  JPEG does a global quantization, irregardless of the
local image content.  You can do much better, especially if you can
fit the image in memory, or at least take two or more passes through it.

Mark Adler
madler@tybalt.caltech.edu
Newsgroups: comp.compression,comp.compression.research,comp.multimedia,sci.image.processing,comp.graphics
From: stanley@skyking.OCE.ORST.EDU (John Stanley)
Subject: Re: Question: difference in viewed and printed images
Organization: Oregon State University, College of Oceanography
Date: Fri, 4 Sep 1992 02:40:47 GMT

In article <sjreeves.920903165024@fourier.ee.eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
>Notice that the original poster was referring to gray-scale images, so
>all this color discussion is irrelevant.  I've noticed the same difference
>between displaying and printing *any* gray-scale images (not just lossy-
>compressed).  I think the effect springs from the fact that a typical
>monitor inherently does a small amount of lowpass filtering, so that the 
>pixel boundaries are less noticeable on a monitor.  There may be other
>causes as well, but this is probably one of them.

The major problem is that the monitor is able to display gray levels,
while the printer does only black or white. It makes a marvelous attempt
at pretending to do gray by varying the numbers and positions of the
black dots it puts on the paper, but it is still only an approximation.

The standard PostScript printer has 300 dpi, but only reproduces 53
lines per inch and 33 levels of gray, by default. If you want full
resolution from the printer (300 dpi, you get only two shades: black and
white. There are several other "halftone screens" available, but the 
best number of grays is, as I recall, 39. 

For more information, look in this month's Radio Electronic's, the 
Hardware Hacker column.

A 2400 dpi printer should do much better than this, but it is still only
writing an approximation to gray. 

Newsgroups: comp.compression
From: dec@gtech.com (Dehe Cui)
Subject: Looking for LHarc Source
Keywords: data compression, LHarc
Organization: GTECH Corporation, West Greenwich, RI
Date: Fri, 28 Aug 1992 12:41:12 GMT

Hi!

   I am starting working on data compression project. I need some data
compression sources for the investigation. Some one told me that the LHarc
source is freely available and the author of LHarc, Haruyasu Yoshi, has
explicitly granted the right to use his program for any purpose, personal or
commercial. I wonder if you could tell me where I can get the source of the
LHarc algorithm.

   Thank you very much.

Dehe

+--------------------+--------------------+---------------------------+
|  G  T  E  C  H                     C  O  R  P  O  R  A  T  I  O  N  |
+--------------------+--------------------+---------------------------|
| Dehe Cui           |                    | Email: dec@soft.gtech.com |
| 55 Technology Way  |                    | Voice: (401)-392-1000     |
| West Greenwich, RI |                    |   Fax: (401)-392-0476     |
+--------------------+--------------------+---------------------------+


Newsgroups: comp.compression
From: huumala@tnclus.tele.nokia.fi
Subject: How to decompress .Z files?
Organization: Nokia Telecommunications.
Date: Fri, 4 Sep 1992 05:59:11 GMT

What program do you use to decompress .Z files?  Where can I get that program? 
I have tried to use both pkunzip and zoo on these files, but neither works. 

thanks Dean
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: INFO-ZIP congretulations!
Date: 4 Sep 92 13:39:52 GMT
Organization: Academic Computer Centre Utrecht

Impressive work. I have been torturing it a bit and looked with a magnification
glass through the sources. I can't say other than great work. Thanks!

For the freaks and those wanting to know. The max compression mode gets
almost the same ratio (on MS-DOS machine) as PKZIP 1.93a. And almost
means 0.5% worse. The speed is quite reasonable. And free, sources
included and portable of cource.

Nico E. de Vries
_ _
O O  USENET nevries@cc.ruu.nl  FIDO 2:281/708.1  COMPUSERVE "soon" ???? 
 o   This text reflects MY opinions, not that of my employer BITECH.      
\_/  This text is supplied 'AS IS', no waranties of any kind apply.      
     Don't waste your time on complaining about my hopeless typostyle.
Newsgroups: comp.compression,comp.dsp
From: enis@flower..bellcore.com (A. Enis Cetin)
Subject: Re: LPC10e /Ftp site
Summary: Vocoder document 
Keywords: NSA document
Reply-To: enis@flower.UUCP (xx)
Organization: Bellcore MRE
Date: Thu, 3 Sep 92 20:44:51 GMT

I am looking for 

D.P.Kemp, et. al., "LPC-10e Enhanced LPC-10 Voice coder, 
Phase 1 Report,"
National Security Agency, document number R163-84-01", 
March 4, 1985.

Is there an ftp site where this document can be obtained.

Thanks in advance.
Enis



Newsgroups: comp.compression
From: gmribeir@david.wheaton.edu (Glauber)
Subject: Where to find zip/unzip with encryption
Reply-To: gmribeir@david.wheaton.edu
Organization: (n.) Body of persons united for a specific purpose.
Date: Fri, 28 Aug 1992 18:01:09 GMT


I'm not sure if i understood everything that was posted about
where to find the new zip/unzip.

Specifically, is it possible to ftp the complete version,
including encryption, or just the crippled version? Are there any
sites (preferably in the US) carrying the full version?

I need both the sources and the msdos executables. If i can't get
the msdos executables, i can probably compile them myself.

Thank you.

						Glauber


-- 
Glauber Ribeiro - Wheaton College, IL  (USA)
                  glauber@david.wheaton.edu 
                  glauber@vpnet.chi.il.us
Newsgroups: comp.compression
From: eng40010@nusunix2.nus.sg (CHUA KEE LAM)
Subject: H.261 Codec
Organization: National University of Singapore
Date: Sun, 30 Aug 1992 11:43:15 GMT


	I am currently working on a project involving
the H.261 Codec (another name for it is px64).  I was
wondering if there are existing codes available somewhere.
As I am new to H.261, I would like also to know of any 
source of materials available.  Any help is appreciated.

	Thanks.

	Alex C.

(My email address is eng40010@nusunix.nus.sg)


Newsgroups: comp.compression,sci.image.processing
From: popat@image.mit.edu (Kris Popat)
Subject: Re: Best compression for 24 bit images
Organization: MIT Advanced Television Research Program
Date: Fri, 28 Aug 1992 19:08:27 GMT


> What is the best way to do lossless compression of 24 bit images? I am
> currently using 24 bit tiff with lzw and the pnmtotiff program
> (-predictor 2). JPEG is not lossless and can't be considered, the
> restored image must be pixel by pixel identical.

JPEG does have a lossless coding mode -- you might want to see how it
compares in performance with what you're doing now.

Not a whole lot of research has been done in lossless compression of
images, and of the work that has been done, the compression ratios are
not all that dramatic (e.g., 2.5:1 on average).  The most popular
techniques among researchers seem to be variations on bit-planing in
conjunction with adaptive binary entropy coding.

One of the limiting factors is camera noise -- which can require as
much as one bit per pixel (yes, really), and is inherently
uncompressible.  Thus the largest compression factors we can ever
expect to see are in the range of 8:1 for typical 8-bit monochrome
natural-scene images.  Any technique that consistently provides more
than 3.5:1 should be considered a real breakthrough.  Such a
breakthrough is likely to happen over the next few years, as there is
no fundamental reason why 4:1 or 5:1 can't be done with a
sophisticated enough algorithm.

Note that these numbers are for typical CCD cameras and typical
resolutions, e.g., 512x512, using natural scenes.  We could of course
get much higher compression ratios by starting with oversampled,
low-noise original images.

Kris Popat
MIT Rm. E15-355  Cambridge, MA  02139
From: exumfox@exu.ericsson.se (Mike Fox)
Newsgroups: comp.compression
Subject: unix compress Lempel-Ziv coding
Date: 31 Aug 92 20:31:15 GMT
Reply-To: exumfox@exu.ericsson.se
Organization: Ericsson Network Systems


I am looking for a way to transfer files from a Unix file
system to a proprietary file system that have been compressed
with unix "compress" (Sun OS).

The "man" page says the following:

DESCRIPTION
     compress reduces the size of the named files using  adaptive
     Lempel-Ziv coding. 

Does anyone know where I can find a description of this algorithm?

Thanks,

Mike    
Newsgroups: comp.compression
From: sc7@ukc.ac.uk (S.Chan)
Newsgroups: comp.compression,comp.compression.research,comp.multimedia,sci.image.processing,comp.graphics
Subject: Question: difference in viewed and printed images
Date: 3 Sep 92 17:06:19 GMT
Organization: Computing Lab, University of Kent at Canterbury, UK.

I have printed some decompressed images on hardcopy and they don't
look quite the same as that is shown on a monitor, specifically
the effects of noise, sharpness and blocking effects. (a 2400dpi
printer was used to print the 256-level grey scale images)

I suppose there is a great difference between viewing pictures on
screen and on paper. Does anyone have any experience in resolving
this kind of problem? I'm also interested to read materials
that have been published on this problem.

Thanks.

Chan
Newsgroups: comp.compression
From: Webbge@che01.ncsu.EDU (Greg Earl Webb)
Subject: Re: STACKER OR PC STORE OR ????????
Reply-To: Webbge@che01.ncsu.EDU (Greg Earl Webb)
Organization: North Carolina State University
Date: Fri, 4 Sep 1992 16:00:17 GMT

In article <1992Sep3.233953.6993@rei.com>, fox@rei.com (Fuzzy Fox) writes:
> rpb0804@zeus.tamu.edu (BATES, ROBERT PATRICK) writes:
> 
> >>I need more hard disk space but can't afford a larger hard disk at this 
> >>time.  Hence, I am looking at on the fly compression products.
> 
> >DON'T SCREW WITH STACKER 2.0!!!!!!!!!!!!!!!!!!!!!!!
> >That SOB almost took out some vital info on my hard drive last semester
> 
> I get tired of reading responses like this.  Stacker 2.0 is a solid
> product, one which I have pushed and prodded and poked and tried every
> way I could think of to bring it down.  I'm not just a PC user, I'm a PC
> torturer, and I could not make it fail unless what I did would have made
> DOS itself fail, too.
> 
> Stacker is a fine product which is nevertheless blamed first whenever
> some stupid user makes a mistake and loses some data.
> 

I will have to agree with the latter response.  Stacker is a very solid
peice of software.  I have had no problems with compatibility with other
software and have not lost any data in the year that I have owned it.

I think it should be pointed out to users of Stacker that an SCHECK should
be performed quite frequently to ensure the integrity of the fat tables
that stacker keeps.

I would be curious to see the original poster explain exactly what happened
to his data.  "That SOB almost took out some vital info ....." is not
much of a description of the software inadequacies.
Newsgroups: comp.compression
From: agoates@nyx.cs.du.edu (Alan Goates)
Subject: Where are these archives???
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Fri, 4 Sep 92 18:30:55 GMT


  I'm looking for C source for LZ, Huffman or LZHUF compression, does anyone
know where I could find such an animal?
  Thanks,
  AL
Newsgroups: comp.compression.research
From: subbu@octagon.cis.ohio-state.edu ()
Subject: JPEG software
Originator: subbu@octagon.cis.ohio-state.edu
Organization: The Ohio State University, Department of Computer and Information Science
Date: Sun, 30 Aug 1992 20:50:44 GMT



I am looking for public domain compression software (JPEG).  Could anyone 
suggest me whom I should contact etc.

Thanks a lot
From: spot@CS.CMU.EDU (Scott Draves)
Newsgroups: comp.compression.research
Subject: Re: Compression of pictures (e.g. star fields)
Date: 30 Aug 92 05:37:48 GMT
Organization: School of Computer Science, Carnegie Mellon University
Originator: spot@HOPELESS.MESS.CS.CMU.EDU

>>>>> On 27 Aug 92 02:53:43 GMT, phys169@csc.canterbury.ac.nz said:

mark> Is there a name for the method of compressing video signals
mark> where the distance before a certain amount of brightness change
mark> is stored, instead of the brightness at regular points?

this sounds equivalent to run length encoding (rle).  any survey of
compression should cover this.

-- 
			grenada
Scott Draves		panama
spot@cs.cmu.edu		iraq
From: goofy@diku.dk (Brian Jacobsen)
Newsgroups: comp.compression.research
Subject: JPEG
Keywords: JPEG hierarchical progressive DCT
Date: 28 Aug 92 09:53:18 GMT
Organization: Department of Computer Science, U of Copenhagen


Hi folks.
   We are three guys who are working on a report about JPEG. So far we 
have implemented sequentiel encoding/decoding for 8x8 blocks in grayscale 
(64 graytones) images. Now we are working with the unthankfull task to 
implement both progressive and hierarchical encoding/decoding still 8x8 
blocks in grayscale. To test our programs we need some progressive and
hierarchical encoded images. So if you happen to have a pile of such
images please Please PLEASE email us on the address below. 
   While we are here we might as well ask for integerbased cosine 
transformation algorithms. 




                               a 1000 thanx in advance and merry X-mas.

                                                 Niels, Michael, Brian
                                            (e-mail : goofy@freja.diku.dk)
Newsgroups: comp.compression.research
From: sh@cypress.com (Steve Haigh/VDSP)
Subject: ACCADEMIC CONSULTANCY SOUGHT, MPEG/Px64
Originator: sh@kahuna
Organization: Cypress Semiconductor/San Jose, CA
Distribution: na
Date: Tue, 25 Aug 1992 23:31:52 GMT

Cypress Semiconductor is developing a video/audio compression chip. We
are currently seeking a relationship with a University to broaden our
knowledge of and do research in the following:

MPEG 1 type smart encoding.
Px64 type smart encoding.
Motion estimation.
Video processor architecture.
Scalable MPEG decoding, i.e. receiving MPEG 1 bit stream, decoding
  only QCIF resolution.
Image filtering and pre/post processing.
Image stabilization.
Echo cancellation.

EE/CS departments active in video/audio processing are encouraged to
contact me:

Steve Haigh, Director Video DSP, sh@cypress.com.
Newsgroups: comp.compression.research