HDTenEightyP/NetNews huggingface dataset:
From: lip@s1.gov (Loren I. Petrich)
Subject: What are Good Examples of Tolerable Degradation?
Organization: LLNL
Date: Wed, 16 Dec 1992 17:58:48 GMT

	I am curious about how much work has been done to determine
what is the least unpleasant-looking image degradation.
Image-compression software/hardware can then be optimized to produce
that kind of degradation if an image has to be seriously degraded to
keep the compressed volume down.

	I got my idea on what one might shoot for as I was reading
some railroad books which featured some excellent photography. Diesel
locomotives produce clear (most of the time!) and hot exhaust, and
looking through produces noticeable blurring. However, at least in the
pictures I saw, there was plenty of area not in the line of sight of
the exhaust, which provided good control areas.

	Any other "natural" examples?

-- 
/Loren Petrich, the Master Blaster
/lip@s1.gov
From: alphag@terapin.com (Charles Ying)
Newsgroups: comp.compression.research
Subject: Re: Version 4 of free JPEG software released
Date: 17 Dec 92 03:19:37 GMT
Organization: BBS

That is very nice, I am looking forward to seeing the program and will report
any bugs that our testing group finds.
Newsgroups: comp.compression.research
From: oauld@ponder.csci.unt.edu (orion okotu auld)
Subject: Re: Delta Record Agorithm
Organization: University of North Texas
Date: Wed, 16 Dec 1992 05:42:13 GMT

In <1glp5cINN1nm@usenet.INS.CWRU.Edu> al045@cleveland.Freenet.Edu (Gergely Tapolyai) writes:


>Setting:  A Database, where changes on a record must be kept, i.e.
>          a history of changes by storing records as an archive
>          before it changes.
>Problem:  Space limitation.  Records can be as large as 1MByte.
>          
>Solution:  Well, that is what I am looking for.  I have thought
>           of compression, keeping delta records, and finaly
>           I came uppon reverse delta records.

>Now the only thing I need is an algorithm for it.  

>Anyone out there can point me to the right direction?

I think the standard difference algorithm is the Miller-Myers algo.
It's fairly straightforward.  The article is called "An O(ND) Difference
Algorithm and its Variations" but I can't recall where it's written up; I
think somewhere in Communications of the ACM.  A more readable version
exists somewhere in Software Engineering; you might try flipping through
some indices.  Hope this helps.

                            --Orion
-- 
      Orion Auld           |Oh, Lord, won't you buy me a 486
"We are only fabulous      |My friends all use Vaxes, but they make me sick
 beasts, after all."       |I want to run Windows; it needs to run quick
 -- John Ashberry          |So Lord, won't you buy me a 486

-- 
      Orion Auld           |Oh, Lord, won't you buy me a 486
"We are only fabulous      |My friends all use Vaxes, but they make me sick
 beasts, after all."       |I want to run Windows; it needs to run quick
 -- John Ashberry          |So Lord, won't you buy me a 486
From: al045@cleveland.Freenet.Edu (Gergely Tapolyai)
Newsgroups: comp.compression.research
Subject: Delta Record Agorithm
Date: 15 Dec 1992 23:19:08 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


Setting:  A Database, where changes on a record must be kept, i.e.
          a history of changes by storing records as an archive
          before it changes.
Problem:  Space limitation.  Records can be as large as 1MByte.
          
Solution:  Well, that is what I am looking for.  I have thought
           of compression, keeping delta records, and finaly
           I came uppon reverse delta records.

Now the only thing I need is an algorithm for it.  

Anyone out there can point me to the right direction?

Thank you.
-- 
TAPOLYAI, Gergely                al045@cleveland.freenet.edu
                                 Cleveland, Ohio U.S.A.
From: al045@cleveland.Freenet.Edu (Gergely Tapolyai)
Newsgroups: comp.compression.research
Subject: Delta Record, Found. Thanks.
Date: 18 Dec 1992 16:54:24 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc4.ins.cwru.edu


Thank you for all of your notes.
The quickest solution came from J. Eliot B. Moss of Carnegie
Mellon U.
He suggested to simply XOR the records, then remove the zero
results.
So I simply XOR-ed the current record with the new record, 
producing a new record, then applied RLE against that record.
The size is quite small, and it is relatively fast.

Thank you for all your help.
-- 
TAPOLYAI, Gergely                al045@cleveland.freenet.edu
                                 Cleveland, Ohio U.S.A.
From: M.S.Webb@newcastle.ac.uk (bill)
Newsgroups: comp.compression.research
Subject: Re: single chip solution for hardware compression
Keywords: DCT compression image
Date: 14 Dec 92 11:54:49 GMT
Followup-To: Steven Collins
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU.


Steve Collins(scollins@uswest.com) writes:
> Anybody aware of a single chip solution for
> lossless ahrdware compression?

Although I don't know of a single chip solution, there are a couple 
of useful devices you may like to take a look at.
These are the Inmos IMSA121, and the SGS-Thomson STV3208.
Both of these perform the Discrete Cosine Transform in 8x8 blocks,
and for information on this I refer you to the paper
"Image compression using a discrete cosine image processor"
   by D J Bailey, and N Birch of Inmos

as well as the "Image Processing DataBook" by SGS-Thomson.

If you are unfamiliar with the DCT (Discrete Cosine Transform), I refer 
you to Transactions of the IEE, for papers on the subject.

If you need more information on the two devices I have mentioned,
then try

Documentation Dept.,
SGS-THOMSON MICROELECTRONICS LTD,
Planar House,
Parkway,
Globe Park,
MARLOW,
Bucks,
SL7 1YL
Telephone:+44628 890800
Telex    :847458
Fax      :+44628 890391


If you need any more help I shall try to give you some pointers, but 
I must say that I am just learning at the moment myself
(Study Project)


Mark Webb
(n023y@newton.ncl.ac.uk)
====  /   //     ==M.S.Webb==aka bill======================================
     /_ '//     |                        | 'Over and over she said those   |
    / |////_/   | n023y@newton.ncl.ac.uk |words,'til he could take no more'|
=  /_////__/.    ==========================================================
From: rstewart@ccwf.cc.utexas.edu (Robert Stewart)
Newsgroups: comp.compression.research
Subject: Re: single chip solution for hardware compression
Keywords: DCT compression image
Date: 17 Dec 92 23:38:37 GMT
Organization: The University of Texas at Austin, Austin TX

Steve Collins(scollins@uswest.com) writes:
> Anybody aware of a single chip solution for
> lossless ahrdware compression?

Look on page 16 of the Nov. 23, 1992 EE Times. I believe that there was a
short News Brief on such a chip from IBM. I can't tell you for sure,
because I cut out the article and gave it to a colleague who was also
looking for such a beast. If he still has the article, I will post again.

Robert Stewart
rstewart@ccwf.cc.utexas.edu
From: cre1@ns1.cc.lehigh.edu (CHRISTOPHER R. EMERSON)
Newsgroups: comp.compression
Subject: Motion Compensation?
Date: 14 Dec 92 16:13:16 GMT
Organization: Lehigh University

Can anyone tell me (is this in a FAQ?) in plain english, what motion
compensation is, how it is done and what it does for you?  I've heard it
mentioned in many papers, but I guess everyone assumes that you know what they
are talking about.  Any help would be appreciated.  Thanks.

Chris

cre1@lehigh.edu
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: How much memory does MW compression really need?
Date: 14 Dec 92 16:04:45 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)

David West <dhw@plex-1.ann-arbor.mi.us> writes:

> I've compiled Dan Bernstein's implementation of Miller-Wegman compression  
> ("sqz" from comp.sources.somethingorother).

comp.sources.unix, Volume 21, Issue 1, 6 Feb 90.

> The included comments say that it's "even more of a memory hog than
> Compress".  Well, compress runs in 400K, but sqz (with no other tasks
> running) thrashes and then dies on my Unix box (6MB real memory, 5MB
> swap space) trying to compress a 100K file.  Anyone know how much
> memory is comfortable for it?  Or is something else the problem?

On the file book2 from the Calgary corpus, squeeze requires 5M of
virtual memory and uses about 4M of physical memory (obtained with
"ps -v" on a SparcStation SLC with 8M of physical memory). By comparison,
zip 1.9 uses about 0.5M of physical memory, runs 4 to 7 times as fast
(elapsed time on an idle machine) and compresses better than squeeze:

         original  compress   squeeze     zip -5   zip -1

size     610,856   250,759    230,862    206,771   217,341
user                4.840u    18.350u    13.030u    8.040u
system              0.600s     4.140s     0.500s    0.390s
elapsed           0:05.93e   1:08.69e   0:15.08e  0:09.39e

Because of the higher memory usage, squeeze pages much more. This
explains the higher ratio elapsed time/cpu time.

Jean-loup Gailly
jloup@chorus.fr
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: Fixed point of the lzw compression alg.
Date: 16 Dec 92 08:57:43 GMT
Reply-To: jloup@chorus.fr (Jean-Loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France

Doug Jones <jones@cs.uiowa.edu> writes:

> Therefore, the shortest possible fixed point for LZW (ignoring end
> of file coding) will be something like:
>    ABCDEFGAB
> with a letter substitution that is very carefully chosen.

No. The shortest possible fixed point for LZW is the empty string.
Since you correctly ignored the three byte magic cookie added by
'compress', the output of the LZW algorithm is also an empty string.

Jean-loup Gailly
jloup@chorus.fr
Newsgroups: comp.compression
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Fixed point of the lzw compression alg.
Date: Tue, 15 Dec 1992 17:23:09 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <1992Dec15.165902.3227@news.uiowa.edu>,
by williams@herky.cs.uiowa.edu (Kent Williams):

> From ren@function.mps.ohio-state.edu (Liming Ren):
>
>> Is there a fixed point for lzw?

A really interesting question, but in a realm akin to "pure math" in that
I can't see a single reason that the answer could be useful to anyone.
(And I say this as someone who's looked seriously at fixed points of
macro assembly languages and linking loaders!)

> Taking the Unix Compress.  You start out with ...
> 
> 	<NO PREDECESSOR>N
> 
> for N in 0..256.  The code for <NO PREDECESSOR>N is N, but the code
> will be output at nine bits of precision. ...

This gives us the key we need to begin constructing a fixed point for
LZW, but keep in mind that UNIX compress puts a three byte magic cookie
on the front of the compressed file.  Ignoring this magic cookie, we can
make the following observation:

Input  XXXXXXXX < a single byte input file

Output XXXXXXXX < the LZW compressed result
              0

Input  XXXXXXXX < a two byte input file
       YYYYYYYY

Output XXXXXXXX < the LZW compressed output
       YYYYYYY0
             0Y

From this, we conclude that if there is a fixed point, the second
character must have an even code in binary (the LSB must be zero).

Furthermore, each new byte that occurs (before a string is found
that is actually compressible) adds one bit to the output, so there
must eventually be a compressible string in the sequence to take away
a bit.

Conclusion.  7 new characters add 7 bits to the string.  If the 8th
and 9th characters are a repeat of a previous digraph in the string,
they will add a single 9 bit lump for two characters, thus making the
total input string length equal to the total output string length.

Therefore, the shortest possible fixed point for LZW (ignoring end
of file coding) will be something like:

   ABCDEFGAB

with a letter substitution that is very carefully chosen.

					Doug Jones
					jones@cs.uiowa.edu
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: Floppy-sized Zipping (was: when Zip is a LOT better ...)
Date: 11 Dec 1992 20:58:24 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


>> There is.  For ZIP, there is a program called "ZIP Chunker" for MS-DOS
>> which will take a large ZIP file and break it into floppy-sized chunks,
>> where each chunk is still a full and complete ZIP file.

Info-zip's Zip comes with a program that does the same thing called
"zipsplit".  It will also produce an index file, with the space for
that file deducted from the first disk so it can be written there.

It too requires that you have space for the unsplit zip file, and
will not split entries across zip files in order to make full and
complete zip files, as above.  This latter restriction makes it of
dubious use for backups, since you can easily have a zip entry
larger than your media size.  The (still in a gaseous state but
slowly condensing) new PKZIP 2.x will define a way to split zip entries
across zip files, and Infozip will implement it.

zipsplit would be useful for making a multi-disk distribution.

Mark Adler
madler@cco.caltech.edu
Xref: sparky comp.compression:4138 comp.lang.pascal:7429
Newsgroups: comp.compression,comp.lang.pascal
Subject: LZW or Run-length compression source code
From: <TAMGC@CUNYVM.BITNET>
Date: Sunday, 13 Dec 1992 15:12:32 EST
Organization: City University of New York/ University Computer Center

A program I wrote in Pascal,generates a binary output file  (File of byte),
which contains a lot of consecutive 0's and 1's. I would like to compress
this file using LZW or run-length coding. Does anybody know where I can
find source code in Pascal to do this compression/decomression for me?

It can also be a compiled object code which I can incorporate in my
program.



I thank you for your help..

Tamer Avcilar
Xref: sparky comp.compression:4168 comp.compression.research:347
From: abunawas@eeyore.stcloud.msus.edu (Adel)
Newsgroups: comp.compression,comp.compression.research
Subject: Needed: Books on compression methods.
Date: 16 Dec 92 18:56:47 GMT
Organization: St. Cloud State Univ., MN

Hello;
I would like the titles (author names and publisher) of some good
books that deal with compression and describe the following
compression methods:
	1) Modified Huffman (CCITT Group 3 1D)
	2) Modified Run (CCITT Group 3 2D)
	3) CCITT Group 4

Please reply to  abunawas@eeyore.stcloud.msus.edu.

Thank you.

Adel M. Abunawass, Ph.D.	E-Mail: abunawas@eeyore.stcloud.msus.edu
Computer Science Dept.			mfama@uxa.ecn.bgu.edu
Saint Cloud State University
Saint Cloud, MN 56301
612-654-5222
-- 
-- 
Adel M. Abunawas,Pd.D.   Mundanely     |       "Teachers are supposed to
Humengous Among US       Socially      |        teach you *HOW* to learn
Adel                     Generally     |        not *WHAT* to learn."   
Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Re: File Format Hell: Difference Between PKZIP 1.1, 1.93a, and 2.0?
Date: Fri, 11 Dec 1992 20:58:38 GMT
Organization: Recognition Equipment, Inc.

westes@netcom.com (Will Estes) writes:

>My goal is to have an easily exchanged file format between DOS and UNIX.
>Can I get to that goal by using ZIP 1.9 and UNZIP 5.0 on UNIX and 
>PKZIP 1.93a on DOS?

Throw away PKUNZIP and just run UnZip on DOS, and everything will run
just fine.  The only reason I can think of to keep PKUNZIP around is
that you might have registered it.

-- 
#ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       fuzzy@netcom.com
#define  TRUE   0  |
#define  FALSE  1  |  "You have been recruited by the Star League to defend
#endif             |     the Frontier against Xur and the Kodan Armada."
Newsgroups: comp.compression,alt.security.pgp
From: gmribeir@david.wheaton.edu (Glauber)
Subject: Possible HPACK x PGP screwup
Keywords: beware, becareful, behappy, merry christmas
Reply-To: glauber%david.wheaton.edu@tellab5.tellabs.com
Organization: SETEC ASTRONOMY
Date: Fri, 18 Dec 1992 00:10:37 GMT


I think there may be a problem with the utility that
converts PGP secret keys for use with hpack (KEYCVT.EXE). I
emailed Peter Gutmann about this, and will post the result
when he responds.

This is the scoop: PGP secret keys need to be converted
before they may be used by hpack. Gutmann says he has to add
some material to the key because of copyright problems, or
something like this. I did the conversion, and HPACK is
working fine with the converted key, but now PGP DOESN'T
WORK ANYMORE! :-( :-( :-(

I get the following error message:

-----------START SCREEN CAPTURE--------------

e:\>pgp -eas temp.tmp                                                     
Pretty Good Privacy 2.1 - Public-key encryption for the masses.           
(c) 1990-1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92    
Date: 1992/12/17 13:42 GMT                                                
                                                                          
A secret key is required to make a signature.                             
You specified no user ID to select your secret key,                       
so the default user ID and key will be the most recently                  
added key on your secret keyring.                                         
                                                                          
Unsupported packet format - you need a newer version of PGP for this file.
                                                                          
Could not read key from file 'C:\CRYP\secring.pgp'.                       
Signature error                                                           
                                                                          
For a usage summary, type:  pgp -h                                        
For more detailed help, consult the PGP User's Guide.                     

----------END SCREEN CAPTURE--------------------------------------



Of course, the backup i had of the key didn't work (doesn't
this always happen?)

If there is no way to revert whatever KEYCVT does, i'm screwed.

Moral: 1) keep more than one backup of your key
       2) if you use KEYCVT.EXE, set the output file to
          a different name and check to see if PGP still works.


Any help on this topic is appreciated. Note that
theoretically something else may have corrupted my key, but
i really can't think of any possibility. Besides, HPACK
works nice and fine (but PGP doesn't) so it really looks
like KEYCVT was the bad guy here.


						Glauber

-- 
Glauber Ribeiro
glauber@david.wheaton.edu
glauber%david.wheaton.edu@tellab5.tellabs.com
Newsgroups: comp.compression,comp.compression.research,comp.graphics,alt.graphics.pixutils,alt.binaries.pictures.utilities
From: tgl+@cs.cmu.edu (Tom Lane)
Subject: Version 4 of free JPEG software released
Followup-To: comp.compression
Keywords: JPEG, image compression
Reply-To: jpeg-info@uunet.uu.net
Organization: School of Computer Science, Carnegie Mellon
Date: Sun, 13 Dec 1992 23:10:22 GMT

The Independent JPEG Group is proud to announce the fourth public release
of our free JPEG image compression software.

The C source code, documentation, and test files are available for anonymous
FTP from FTP.UU.NET (137.39.1.9), file graphics/jpeg/jpegsrc.v4.tar.Z.
The package will shortly be available on CompuServe, in the GRAPHSUPPORT
forum (GO PICS), library 15, as jpsrc4.zip.  We intend to post the source
code in comp.sources.misc and executables in appropriate binaries groups.


The distributed code provides conversion between JPEG "JFIF" format and
image files in PBMPLUS PPM/PGM, Utah RLE, Truevision Targa, and GIF file
formats.  The core compression and decompression modules can easily be
reused in other programs, such as image viewers.  The package is highly
portable C code; we have tested it on many machines ranging from PCs to
Crays.

Important improvements over version 3 include:

* Significant speedups.  The basic JPEG compression and decompression
  operations are typically about a factor of 2 faster than v3.  (Your
  mileage will vary depending on CPU type and C compiler.)

* Improved image quality, due to more accurate DCT and resampling
  algorithms.

* Error recovery capability has been added to the decompressor, so that
  it can cope with damaged JPEG files.  While damage to the compressed
  data will scramble the output image, the effects of damage can be
  confined to small areas of the image if the file was originally created
  with "restart" markers.  Even severe damage will only result in loss of
  the damaged restart segments; the rest of the image can still be recovered.

* Redesigned command line switches provide access to more JPEG parameter
  settings, including restart marker generation in the compressor.

* There is an option for smoothing the input image before JPEG compression.
  This helps a lot when converting dithered GIFs to JPEG.

* Portability is even better than v3.


We are releasing this software for both noncommercial and commercial use.
Companies are welcome to use it as the basis for JPEG-related products.
We do not ask a royalty, although we do ask for an acknowledgement in
product literature (see the README file in the distribution for details).
We hope to make this software industrial-quality --- although, as with
anything that's free, we offer no warranty and accept no liability.

Please direct any questions about this software to jpeg-info@uunet.uu.net.

-- 
			Dr. Thomas G. Lane
			organizer, Independent JPEG Group
Internet: tgl@cs.cmu.edu	BITNET: tgl%cs.cmu.edu@cmuccvma
From: kbw@po.CWRU.Edu (Kevin B. Williams)
Newsgroups: comp.compression
Subject: pkunzip or unzip 1.93
Date: 15 Dec 1992 08:22:18 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: kbw@po.CWRU.Edu (Kevin B. Williams)
NNTP-Posting-Host: slc12.ins.cwru.edu


I've found a zipper pkz19p1x.zip  that is compatable with a file I have in
1.93 format, but I can't find the unzipper for this format.  Can someone
please point me in the right direction?

Kevdog
email replies please
Newsgroups: comp.compression
From: umws@pool.sunyit.edu (Michael Seeley)
Subject: Sliding Window Compression.
Organization: State University of New York -- Institute of Technology
Date: Fri, 18 Dec 1992 01:56:03 GMT



	I am looking for information on sliding window compression.
        How this works by examples or refer me to books.
-- 
e-mail umws@sunyit.edu		appleorengespeachesgrapfruitlemonslimes
Newsgroups: comp.unix.aux,comp.sys.mac,comp.sys.mac.misc,comp.sys.mac.hardware,comp.sys.mac.system
From: hjwulfso@unix.amherst.edu (Harris Wulfson)
Subject: Re: A/UX compaitable systems? (was Re: AUX with MAC IIvx why not?)
Followup-To: comp.unix.aux,comp.sys.mac,comp.sys.mac.misc,comp.sys.mac.hardware,comp.sys.mac.system
Organization: Amherst College
X-Newsreader: TIN [version 1.1 PL7]
Date: Sun, 20 Dec 1992 18:35:19 GMT

Michael J. Thibodeau (mike@ra.cs.umb.edu) wrote:

} responded before when I asked about which system to purchase. At the time the
} IIvx seemed to be the correct choice, but now...  

Hmmm.  Think I've heard this line before...I think a musician on the net
(Joe from Berklee) said it 'cause the vx has MIDI problems. I said it to 
myself, too, and I'm pretty certain now that I'm getting a Duo. It seems
the vx is a disappointment to a lot of people... 
--
Harris Wulfson
hjwulfson@unix.amherst.edu
  
  /  /                               _
 /==/ __  __  __  ' _     /   )     // /) _   _   __
/  / /_|_/ /_/ /_/_/_)   (_/_/ /_/_//_//_/_)_(_)_/ /_
                                     //