HDTenEightyP/NetNews huggingface dataset:
From: kerryh@zaphod.UUCP (Kerry Hataley)
Newsgroups: comp.compression,comp.compression.research
Subject: Average file and ratio?
Date: 28 Aug 92 17:55:52 GMT
Followup-To: comp.compression
Organization: Develcon Electronics Ltd., Saskatoon, SK, Canada

Hi,   
 	We are currently developing a compression link for remote
bridge's, and are looking for a 'STANDARD' file that is used to
measure compression ratio's.

	We are using Tiff for the best case, and a none repeating
file for the worse case, but what is an average file?

	As well what do you, the net, feel is good to great
compression ratio's for these average files, 2:1, 4:1 ????

Thanks for all responces
kerry

-- 
OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2 OS/2
^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^  Kerry Hataley ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^
   Email-=- zaphod!kerryh (UUCP) -==- zaphod!kerryh@access.usask.ca(Internet)
      The options and inquires express here are my own, and not my employer          
Xref: sparky comp.compression:3183 comp.compression.research:146 comp.multimedia:2588 sci.image.processing:605 comp.graphics:9426
From: sjreeves@eng.auburn.edu (Stan Reeves)
Newsgroups: comp.compression,comp.compression.research,comp.multimedia,sci.image.processing,comp.graphics
Subject: Re: Question: difference in viewed and printed images
Date: 3 Sep 92 21:50:25 GMT
Organization: Auburn University Engineering

In article <mack.715549997@deci> mack@deci.cs.umn.edu (Dan Mack) writes:
>In <1565@eagle.ukc.ac.uk> sc7@ukc.ac.uk (S.Chan) writes:
>
>>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)
>
>The problem  you are experiencing are due to the  imperfect science of
>gamut  mapping.  This  is  a hot topic in computer graphics  and falls
>under color theory.  There are lots of  papers to  read on  this.  For
>some introductory  reading you could look at the Foley-Vandam graphics
>book.

>[remainder of discussion on color deleted]

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.



--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
Newsgroups: comp.compression
From: sasrdt@shewhart.unx.sas.com (Randall D. Tobias)
Subject: Static dictionary compression
Originator: sasrdt@shewhart.unx.sas.com
Date: Fri, 28 Aug 1992 15:05:52 GMT
Organization: (none)


I'm interested in setting up a static dictionary compressor.  What
practical algorithms are available?  The topic gets pretty short
shrift in most texts, but it seems to me to be the method of choice
when you've got lots of little pieces to compress (in no particular
order).

-- 

Randy Tobias          SAS Institute Inc.     sasrdt@unx.sas.com
(919) 677-8000 x7933  SAS Campus Dr.         72450.2545@compuserve.com
(919) 677-8123 (Fax)  Cary, NC   27512-8000  norat@aol.com

 ... just my $(-exp(2*sqrt(-1)*arcos(0))/(((2**(2 + 1)) - 1)**2 + 1)).

Newsgroups: comp.compression
From: dathomps@vela.acs.oakland.edu (dathomps)
Subject: FAQ and Archives for comp.compression
Organization: Oakland University, Rochester MI.
Date: Wed, 26 Aug 1992 19:57:38 GMT

	What are some of the archives sites for this
	list (e.g. where is the FAQ).

	I need to get some files, and I now remember
	that they are on a site where the public domain
	PKZIP is -- I seem to remember Irvine.

	Anyway, I need to get the Message Digest Algorithm,
	and I remember that it is on one of these ftp sites.

	Anywhere I can get a list?
From: cthombor@theory.lcs.mit.edu (Clark D. Thomborson)
Newsgroups: comp.compression
Subject: Re: CCITT H.261 /Ftp site
Date: 4 Sep 92 14:56:04 GMT
	<gary.92Sep3145520@uranus.isr.recruit.co.jp>
Organization: MIT Lab for Computer Science


I just checked ftp.uu.net for doc/standards/ccitt.  An empty
directory.  I'm not surprised -- according to the login message from
the anonymous ftp server for digital.resource.org, the ITU has made a
ruling forbidding DEC from disseminating the CCITT standards
documents.  I have ordered hardcopy documents in the past from
Omnicom, Inc.  Perhaps Omnicom holds some sort of copyright or patent on
these things.

By the way, I just sent off the galleys for my IEEE Micro article on
V.42bis data compression.  It should appear in their October issue.

							Clark
--
							Clark
Newsgroups: comp.compression,comp.binaries.ibm.pc.archives
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: zip 1.9 and unzip 5.0, Unix versions, at garbo
Organization: California Institute of Technology, Pasadena
Date: Tue, 25 Aug 1992 21:06:53 GMT


The problem Timo found only occurs with the -l (that's an "ell") option
of zip for end-o-line conversion before zipping.  So if you don't use -l,
there's no problem.

A fix for that -l and another -l problem is forthcoming.  In any case,
you can also do end of line conversion with unzip, and that's been working
since the last release.

Mark Adler
madler@tybalt.caltech.edu
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: Where to find zip/unzip with encryption
Date: 30 Aug 92 10:01:19 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)

gmribeir@david.wheaton.edu (Glauber) asks about zip 1.9/unzip 5.0:

> 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 have tried to contact the administrator of wuarchive.wustl.edu
without success. Keith Petersen, the administrator of
wsmr-simtel20.army.mil, agreed to store the files but this
has not yet been done. I have put the (non crypt) sources on

  wuarchive.wustl.edu:/pub/zip19p1.zip
  wuarchive.wustl.edu:/pub/unzip50.tar.Z

and found that the msdos executables were already in

  wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/zip19p1x.zip
  wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/unzip50.exe

Note: zip19p1 means zip 1.9 patch level 1. It has been sent to the
comp.sources.misc moderator but it is not yet posted. Three important
bugs are corrected in this release.

The above files do not include encryption. I did not wish to
cause trouble on wuarchive by uploading zcrypt19.zip.
The encryption sources have been sent to the European comp.sources.misc
moderator in charge of posting encryption code, but they have not
yet been posted either. For the moment you can get them from

  ftp.win.tue.nl:/pub/compression/zip/zcrypt19.zip

I do not distribute MSDOS executables with encryption, you have
to build them yourself. The reason is that most archive sites do not
wish to store such executables.

Non US users, please do *not* get the encryption code from
a US site (if you happen to find one). European users can also
find the zip and unzip sources in

  garbo.uwasa.fi:/unix/arcers/zip19p1.zip
  garbo.uwasa.fi:/unix/arcers/unzip50.tar.Z (or unzip50.zip)

Remember that the encryption version is a little slower than the
standard version, and that the security is very dependent on the
password length. Do not use any password below 9 characters, it's
just too easy to crack by brute force. And don't use lower case letters
only...

Jean-loup Gailly
jloup@chorus.fr
Newsgroups: comp.compression,misc.jobs.offered
From: auyeung@areaplg2.corp.mot.com (Cheung Auyeung)
Subject: Research Engineer in Computer Architecture/Video Compression
Organization: Motorola, CCR&D, CORP, Schaumburg, IL
Date: Fri, 28 Aug 1992 19:16:45 GMT



   Research Engineer in Computer Architecture/Video Compression
   ============================================================
      

      			    Motorola
      	  Chicago Corporate Research & Development Center
      		   Digital Technology Laboratory
                1301 East Algonquin Road, Room 3127
                      Schaumburg, IL 60196
          


Motorola in Schaumburg (Suburb of Chicago), IL, has two (2)
prospective openings in the Digital Technology Laboratory to work
on visual communication. Motorola is a member of ANSI X3L3 for
Audio/Picture Coding and a member of CATS (Center for Advance
Television Studies).

The research engineers will be members of a project team responsible
for developing algorithms and IC architecture related to video
compression.  The first engineer will be responsible for video
compression computer architecture.  The second engineer will be
responsible for video compression algorithms.


Qualifications for Architecture Engineer (1 opening)
==================================================== 

Master or Ph.D. in a related discipline.  Experience in the field
is desirable but not required.  The applicants should have a strong
background in DSP architecture and general computer architecture.
Knowledge in the following fields are desirable:  

* Data Flow Architecture 
* RISC Architecture 
* VLIW Architecture
* Systolic Arrays 

* VLSI Synthesis Tools 
* Hardware Description Languages

* Discrete Cosine Transform 
* Motion Estimation 
* Huffman/Arithmetic Codes 


Qualifications for Algorithm Engineer (1 opening)
=================================================

Master or Ph.D. in a related discipline.  Experience in the field
is desirable but not required.  The applicants should have a strong
background in video/image coding algorithms. Knowledge in the 
following fields are desirable:  

* JPEG/MPEG/HDTV
* Rate Control
* Quantization
* Discrete Cosine Transform/Quadrature Mirror Filter Banks
* Postprocessing/Preprocessing
* Motion Estimation
* Huffman/Arithmetic Coding


Other Prospective openings
==========================

Master or Ph.D. in a related discipline.  Experience in the field
is essential.  The applicants should have a strong background in 
DSP architecture for video coding and/or video coding algorithms. 


Applications
============
Applications can be sent by mail to Steve Levine, Member of 
Technical Staff, or e-mail in  ASCII/Postscript to 
"stevel@areaplg2.corp.mot.com".
Newsgroups: comp.compression
From: lip@s1.gov (Loren I. Petrich)
Subject: Re: "Instant Gigabytes?"
Organization: LLNL
Date: Tue, 1 Sep 1992 17:58:20 GMT

In article <17vemcINNi44@agate.berkeley.edu> benrg@ocf.berkeley.edu (Ben Rudiak-Gould) writes:
>I suppose this has already been discussed to death in this group,
>but I'll post it anyway.  Feel free to flame me via Email.

	It is even in this newsgroup's FAQ.

>I just noticed this in the "Microbytes" column of the June 1992
>issue of Byte magazine.  It's titled "Instant Gigabytes?" and
>here are some excerpts:

@ WEB Technologies (Smyrna, GA) says it has developed a
@ utility that compresses files larger than 64 KB to about
@ one-sixteenth their original size.  Furthermore, WEB
@ Technologies says its DataFiles/16 program can compress
@ files that the program has already compressed. . . .
@ In fact, according to the company, virtually any amount
@ of data can be compressed to under 1024 bytes by using
@ DataFiles/16 to compress its own output miltiple times.
@ . . . According to Earl Bradley, WEB Technologies' vice
@ president of sales and marketing, the compression
@ algorithm used by DataFiles/16 is not subject to the
@ laws of information theory. . . .  The DOS version of
@ DataFiles/16 (Mac and SCO Unix versions are waiting in
@ the wings) was to have shipped in March.  The company
@ now claims that the product will ship by May 1.

	Shipping his year or next year???

	Violating the laws of information theory is like demonstrating
that 2 + 2 = 5. It's a mathematical impossibility.

	If they claim otherwise, then they should go public. At the
very least, they shold try to apply for a patent. If they don't, then
one can legitimately question the honesty of those who claim to have
this product.

>It sounds like an obvious hoax to me, but does anyone have any
>actual information about this?  Was DataFiles/16 in fact
>released?  Is it still being postponed?  Was the project
>cancelled?

Xref: sparky comp.compression:3113 alt.graphics.pixutils:2044 sci.image.processing:568
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression,alt.graphics.pixutils,sci.image.processing
Subject: Best compression for 24 bit images
Date: 28 Aug 92 13:35:52 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

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.

Note: please delete any newsgroups you feel would not be interested in
your reply, I covered all the places where I see discussion like thai.
-- 
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.
From: benrg@ocf.berkeley.edu (Ben Rudiak-Gould)
Newsgroups: comp.compression
Subject: "Instant Gigabytes?"
Date: 1 Sep 1992 09:55:24 GMT
Organization: U.C. Berkeley Open Computing Facility
NNTP-Posting-Host: tornado.berkeley.edu

I suppose this has already been discussed to death in this group,
but I'll post it anyway.  Feel free to flame me via Email.

I just noticed this in the "Microbytes" column of the June 1992
issue of Byte magazine.  It's titled "Instant Gigabytes?" and
here are some excerpts:

     WEB Technologies (Smyrna, GA) says it has developed a
     utility that compresses files larger than 64 KB to about
     one-sixteenth their original size.  Furthermore, WEB
     Technologies says its DataFiles/16 program can compress
     files that the program has already compressed. . . .
     In fact, according to the company, virtually any amount
     of data can be compressed to under 1024 bytes by using
     DataFiles/16 to compress its own output miltiple times.
     . . . According to Earl Bradley, WEB Technologies' vice
     president of sales and marketing, the compression
     algorithm used by DataFiles/16 is not subject to the
     laws of information theory. . . .  The DOS version of
     DataFiles/16 (Mac and SCO Unix versions are waiting in
     the wings) was to have shipped in March.  The company
     now claims that the product will ship by May 1.

It sounds like an obvious hoax to me, but does anyone have any
actual information about this?  Was DataFiles/16 in fact
released?  Is it still being postponed?  Was the project
cancelled?

Thanks for any enlightenment.

--
Ben Rudiak-Gould
benrg@ocf.berkeley.edu
From: B437807@vmtecqro.qro.itesm.mx (Huh?)
Newsgroups: comp.compression
Subject: Question: What is the Extension .cmp about??
Date: 26 Aug 92 18:50:12 GMT
Organization: Instituto Tecnologico de Monterrey, Campus Queretaro

Well, just asking, i wanted to download a file, but it is in .cmp format, so i
dont quite know what kinda compression it is, also dont know if it is for DOS,
Unix or Macintosh (i guess it should be for this last one), well, thats all, se
eya and thanks in advance,....Greets...On
Newsgroups: comp.compression,comp.multimedia
From: chrisa@research.canon.oz.au (Chris Amies)
Subject: Re: Need info on C-Cube CL550 JPEG chip.
Organization: Canon Information Systems Research Australia
Date: Wed, 2 Sep 1992 04:30:27 GMT

Contact C-Cube Microsystems directly:

Tel: +1 408 944 6300
Fax: +1 408 944 6314

You may also wish to enquire about the CL560 JPEG device.

Regards,

Chris Amies, Hardware/Software Engineer      | chrisa@research.canon.oz.au 
Canon Information Systems Research Australia | Phone +61-2-805-2000 
PO Box 313 NORTH RYDE NSW 2113               | Fax   +61-2-805-2929
Newsgroups: comp.compression
From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn)
Subject: Re: CCITT H.261 /Ftp site
Articlenum: 3351
Content-Type: text/plain
Keywords: CCITT Specification
X-Fonttbl: {\fonttbl}
Organization: CSD., University of Erlangen, Germany
Mime-Version: 1.0
Date: Thu, 3 Sep 1992 05:55:20 GMT

kalog@ntua.gr (Dimitris Kalogeras) writes:

>I have heard that there is a ftp site that stores a lot of the CCITT spec.

Anonymous Internet FTP sites with information about ISO standards:

ftp.uni-erlangen.de   portal/doc/ISO        collected USENET articles etc.
osi.ncsl.nist.gov
ftp.uu.net            doc/standards/ccitt   most CCITT standards (not official!)
                      networking/osi        ISODE
                      networking/x25
nic.ddn.mil           protocols             DoD and GOSIP related stuff
                      rfc                   RFC Repository
cs.ucl.ac.uk          src                   ISODE, PP, OSIMIS, ...
                      osi-ds                Internet X.500 documents
                      ietf-osi-oda          Internet ODA documents
aun.uninett.no        ietf/mhs-ds           X.500 based routing drafts
ftp.ifi.uio.no        pub/SGML              SGML/HyTime related things

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
Don't worry over what other people are thinking about you. ----------------
---------- They're too busy worrying over what you are thinking about them.
From: REW099@DJUKFA11.BITNET
Newsgroups: comp.compression
Subject: .Z / Compress under VM/CMS ...?
Date: 4 Sep 92 09:03:07 GMT
Organization: KFA  Forschungszentrum Juelich

Hello,
I hope that someone can give me help...

I already know that the
Compress/Decompress package is available from
vmd.cso.uiuc.edu (public.477)
I received it by FTP, but I didn't got it
running properly.
Who is using it without any troubles. It seems to
be the way that there is an error in the
COMPRESS MODULE.

Any suggestions ?

Please E-Mail to REW099@DJUKFA11.BITNET

-Stefan
From: benrg@ocf.berkeley.edu (Ben Rudiak-Gould)
Newsgroups: comp.compression
Subject: Apology (was Re: "Instant Gigabytes?")
Date: 2 Sep 1992 08:21:26 GMT
Organization: U. C. Berkeley Open Computing Facility
NNTP-Posting-Host: headcrash.berkeley.edu

** FLAME OFF **

In article <17vemcINNi44@agate.berkeley.edu>, I wrote:
> I suppose this has already been discussed to death in this group,
> but I'll post it anyway.  Feel free to flame me via Email.

Several people have taken me up on my offer.  I'd like to make a
public apology for posting my question without checking the FAQL
first.  No, I'm not new to the net (I've been on it for about three
years).  I just never dreamed that this question would be so
frequently asked that it would merit a position in the FAQL.
Obviously I was wrong (very wrong), and what's more, I broke one of
the most important rules of netiquette.  It won't happen again.

So, can we all be friends now? :-)

--
Ben Rudiak-Gould
benrg@ocf.berkeley.edu
"Human error can be prevented by avoiding the use of humans."

** FLAME ON **
Newsgroups: comp.compression,alt.graphics.pixutils,sci.image.processing
From: auyeung@areaplg2.corp.mot.com (Cheung Auyeung)
Subject: Job Offered in Video Compression
Organization: Motorola, CCR&D, CORP, Schaumburg, IL
Date: Thu, 3 Sep 1992 15:00:11 GMT



   Research Engineer in Computer Architecture/Video Compression
   ============================================================
      

      			    Motorola
      	  Chicago Corporate Research & Development Center
      		   Digital Technology Laboratory
                1301 East Algonquin Road, Room 3127
                      Schaumburg, IL 60196
          


Motorola in Schaumburg (Suburb of Chicago), IL, has two (2)
prospective openings in the Digital Technology Laboratory to work
on visual communication. Motorola is a member of ANSI X3L3 for
Audio/Picture Coding and a member of CATS (Center for Advance
Television Studies).

The research engineers will be members of a project team responsible
for developing algorithms and IC architecture related to video
compression.  The first engineer will be responsible for video
compression computer architecture.  The second engineer will be
responsible for video compression algorithms.


Qualifications for Architecture Engineer (1 opening)
==================================================== 

Master or Ph.D. in a related discipline.  Experience in the field
is desirable but not required.  The applicants should have a strong
background in DSP architecture and general computer architecture.
Knowledge in the following fields are desirable:  

* Data Flow Architecture 
* RISC Architecture 
* VLIW Architecture
* Systolic Arrays 

* VLSI Synthesis Tools 
* Hardware Description Languages

* Discrete Cosine Transform 
* Motion Estimation 
* Huffman/Arithmetic Codes 


Qualifications for Algorithm Engineer (1 opening)
=================================================

Master or Ph.D. in a related discipline.  Experience in the field
is desirable but not required.  The applicants should have a strong
background in video/image coding algorithms. Knowledge in the 
following fields are desirable:  

* JPEG/MPEG/HDTV
* Rate Control
* Quantization
* Discrete Cosine Transform/Quadrature Mirror Filter Banks
* Postprocessing/Preprocessing
* Motion Estimation
* Huffman/Arithmetic Coding


Other Prospective openings
==========================

Master or Ph.D. in a related discipline.  Experience in the field
is essential.  The applicants should have a strong background in 
DSP architecture for video coding and/or video coding algorithms. 


Applications
============
Applications can be sent by mail to Steve Levine, Member of 
Technical Staff, or e-mail in  ASCII/Postscript to 
"stevel@areaplg2.corp.mot.com".
Newsgroups: comp.compression,sci.image.processing
From: stgprao@st.unocal.COM (Richard Ottolini)
Subject: Re: Best compression for 24 bit images
Organization: Unocal Corporation
Date: Sun, 30 Aug 1992 20:10:44 GMT

In article <POPAT.92Aug28140827@image.mit.edu> popat@image.mit.edu (Kris Popat) writes:
>
>> 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.

Compression is a lot like sorting algorithms: if you have some a priori
information about the statistics of information you are trying to compress
you can choose a more efficient algorithm.  FAX people know what works well
on text doesn't necessarily work as well on graphics, and vice-versa.
Newsgroups: comp.compression,alt.graphics.pixutils,sci.image.processing