HDTenEightyP/NetNews huggingface dataset:
From: mapimhn@gdr.bath.ac.uk (I M H Nadiadi)
Newsgroups: comp.compression.research
Subject: Re: Need C source for fractal compression
Date: 5 Nov 92 09:07:00 GMT
Organization: School of Mathematics, University of Bath, UK


I would also like the source for any IFS fractal compression
algorithm.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Iqbal M. Nadiadi        Computer Vision Research
 imn@uk.ac.bath.maths    Computing Group
 Tel: +44 (0)225 826183  University of Bath
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: cdw@dcs.ed.ac.uk (Christopher Walton)
Newsgroups: comp.compression.research
Subject: C source for Fractal compression ?
Date: 10 Nov 92 15:27:35 GMT
Organization: Department of Computer Science, University of Edinburgh

Has anyone got any C source for fractal compression or are we all
just crying out in vain? Please send me some if you do!

Thanks - Chris (cdw@dcs.ed.ac.uk)
         "all in the name of ..."
Newsgroups: comp.compression.research
From: hhc@athena.mit.edu (Hong-Hsiang Chen)
Subject: Re: C source for Fractal compression ?
Organization: Massachusetts Institute of Technology
Date: Thu, 12 Nov 1992 01:33:37 GMT

In article <BxIAy0.3Mu@dcs.ed.ac.uk> cdw@dcs.ed.ac.uk (Christopher Walton) writes:
>Has anyone got any C source for fractal compression or are we all
>just crying out in vain? Please send me some if you do!
>
crying out in vain, methinks...
>Thanks - Chris (cdw@dcs.ed.ac.uk)
>         "all in the name of ..."
the only working group doing anything about fractal compression as far as
I know are the originators, Barnsley et. al.... (correct me if I'm wrong)...

don't think they're up to releasing source code though, heh... they've got
a company (Iterated Systems) to cash in on their research stuff...

however, don't bet on anything substantial coming up...in the past 5 years,
nothing much has been done, though I've heard here and there about some sort
of compression standard and commercial software based on it...

_BUT_ the kicker is that fractal compression is not the holy grail nor panacea
they thought it would be ... even Barnsley's fantastic figures that got
everybody excited in the first place used algorithms that were hand-fudged -
the Collage Theorem doesn't work too well with computers...

anyway, the image quality leaves a lot to be desired... 

the decompression routines are easy to code...

it's the compression one that's a bitch and a half - i.e. the collage theorem
and buddies... blecch...

don't look for any freebies here guys...first person to make it really work
gets all the dough...

though IMHO it'll take more than a long while.

Sean. fractal compression? like beating someone with the mandelbrot set?



--
-----
Sean Chen.  hhc@athena.mit.edu
"Nunc in scutella iaceo,/et volitare nequeo,/dentes fredentes video./Miser!"
  Olim lacus colueram, _Carmina Burana_
From: phalke@paul.rutgers.edu (V. Phalke)
Newsgroups: comp.compression.research
Subject: Looking for PPMC
Keywords: prediction by partial match
Date: 12 Nov 92 06:31:14 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I am looking for (preferably C ) the code of PPMC algo. Refer [Bell, 
Cleary, Witten -- Text Compression 1990 pp 152].

Also known as Bell-Cleary-Witten-Moffat algorithm. It uses blending
algorithms for generating an optimal arithmetic coding.

I contacted the authors but so far am `code'-less.

Thanks ...

Vidyadhar Phalke
phalke@paul.rutgers.edu================================================

p.s. If anybody is interested look at its performance in Thomborton's
paper in Oct 92 IEEE Micro.
From: z_youngwd@ccsvax.sfasu.edu
Newsgroups: comp.compression.research
Subject: POSTING C source for Fractal compression for anon ftp
Summary: C source finally posted
Keywords: fractal compression
Date: 12 Nov 92 21:55:53 GMT
Article-I.D.: ccsvax.1992Nov12.155553.1798
Organization: Stephen F. Austin State University

---

I am going to post some _old_ source for fractal image compression.

If you get Yuval Fisher's paper /pub/inls-ucsd/fractal-2.0.tar 
at lyapunov.ucsd.edu and read it while examining the source, it
should be decipherable.

The file will be a zip, frcomp.zip containing both compression
and decompression code.  It is located for anonymous ftp in
/tmp/frcomp.zip @ ftp.uu.net


You will need a C compiler that can handle arrays of size 256x256 char.
I used DJGPP, DJ Delorie's port of GCC to MSDOS.  You also need a math
coprocessor and a 386 or higher if you are on the MSDOS platform.
Images are byte for byte 256x256x256 shades of gray... 65536 bytes.
That is all.

Wayne Young
z_youngwd@ccsvax.sfasu.edu
Newsgroups: comp.compression.research
From: matwesx@gsusgi2.gsu.edu (William E. Sadler)
Subject: Need C source for JPEG routine.
Keywords: JPEG source
Organization: Georgia State University
Date: Fri, 6 Nov 1992 19:58:16 GMT

I am in need of some source code either in C or C++ for a functional JPEG
routine.  Any help will be appreciated!


-- 
/**************************************************************************/
/* William E. Sadler          |       Internet: matwesx@gsusgi2.gsu.edu   */
/* 717 Stephenson Ridge       |               : acmwes@gsusgi2.gsu.edu    */
/* Stone Mountain, GA  30087  |               : 71005.1241@compuserve.com */
/* (404) 413-1957             |            CI$: 71005,1241                */
/*------------------------------------------------------------------------*/
/* Who beat their swords into plowshares, will plow for those who don't   */
/**************************************************************************/
Newsgroups: comp.compression.research
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: compress for VM host wanted
Organization: Warsaw University Physics Dept.
Date: Thu, 12 Nov 1992 17:02:24 GMT

Does anyone know where to get source of unix-compress-compatible
program which can be compiled and used on mainframe IBM ?
I tried compile the unix compress source - and get several screens
of error messages. And I don't have the VM C compiler docs here,
since I don't know what are differences between VM and standard C
and cannot fix these errors myself.
Thanks in advance for any reply, if possible by mail, too.
(I don't read NetNews frequently and may miss reply in NN)
Xref: sparky comp.compression.research:267 comp.compression:3803
From: newsmgr@doc.bmd.trw.com
Newsgroups: comp.compression.research,comp.compression
Subject: Masters Thesis in Parallel Image Compression
Date: 11 Nov 92 07:39:57 MST

Hi all,

I've been working on a master's thesis in computer science on the topic of
parallel image compression.  While I have direction I've moving in I seem to be
a bit behind in finding articles about this area.  I have found maybe 4 but
could sure use some help if any of you might have some handy.  I'll gladly take
pointers also to any alogrithms if any.

Thanks for your help,

Jeff VanderDoes

jvander@oz.bmd.trw.com
From: bell@ufp.enet.dec.com
Newsgroups: comp.compression
Subject: How well do random files crunch?
Date: 13 Nov 92 13:54:37 GMT
Reply-To: bell@ufp.enet.dec.com ()
Organization: Digital Equipment Corporation



Ok, let's talk about random files.  Say I produce a file filled with
random bytes, based on a fairly equal-distribution function.

So the probability for any given character to occur is 1/256, no matter
the file length (because it's an even distribution).

Does anyone have any statistics, or guesses about the compression
obtainable by some of the more popular schemes (like LZH or LZW)?

How about for a parabolic distribution?  I mean (since I'm not that good
with statistics) that it's more likely to get a high or low number, that
one close to 0.5.  Do you think that would make any difference?

I guess one could say I've come up with a random number generator that's
not equally distributed (I like that), and I'd like some input on the
theory behind compressing "random" files.

Mike

P.S. Thanks for any help.
From: renegade@csd4.csd.uwm.edu (Jun Hamaoka)
Newsgroups: comp.compression
Subject: Re: bug in PKLite 1.15??
Date: 11 Nov 1992 21:29:18 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.7.4

In article <1992Nov11.053329.21043@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>In article <92315.194932GILLA@QUCDN.QueensU.CA> "Arnold G. Gill" <GILLA@QUCDN.QueensU.CA> writes:
>>     I just picked up version 1.15 of PKLite and converted all of my
>>compressed .COM files to the newer version.  (Don't ask why, it's just a
>>thing that I do.)  Anyway, it seems that none of the programs out there
>>that check for executable compressions are able to detect version 1.15 of
>>PKLite of .COM files, including the CHK4LITE that PKWare includes in the
>>PKLite distribution!
>

This is a bug that is known to PKWARE.  Apparently there was a last minute
change that shifted the appearance of the PKLITE "header" by a few bytes,
causing CHK4LITE to be unable to recognize it properly.

Note that the PKLITE program itself WILL recognize it properly, it is only
the CHK4LITE program that is affected.  So this is not exactly a fatal 
flaw.


Xref: sparky comp.compression:3818 comp.sys.mac.apps:17127
Organization: Valencia University (Universitat de Valencia) SPAIN
Date: Thursday, 12 Nov 1992 10:50:13 EST
From: Werenfried Spit <SPIT@EVALUN11.BITNET>
Newsgroups: comp.compression,comp.sys.mac.apps
Subject: zip1.9/unzip5.0 mac executables sought

Hello,

In the FAQ I found a reference to zip1.9/unzip5.0 for the Macintosh. I got
the files, but it were only sources. Is there a kind soul who has compiled
these and could send me the executables? (I do not have a C compiler now).
Thanks.
------------------------------------------------------------------------
Werenfried Spit                         tel: +34-6-386 4551
  Departamento de Fsica Terica        spit@vm.ci.uv.es
  Universidad de Valencia               spit@evalun11.bitnet
Organization: Queen's University at Kingston
Date: Tue, 10 Nov 1992 19:49:32 EDT
From: "Arnold G. Gill" <GILLA@QUCDN.QueensU.CA>
Newsgroups: comp.compression
Subject: bug in PKLite 1.15??

     I just picked up version 1.15 of PKLite and converted all of my
compressed .COM files to the newer version.  (Don't ask why, it's just a
thing that I do.)  Anyway, it seems that none of the programs out there
that check for executable compressions are able to detect version 1.15 of
PKLite of .COM files, including the CHK4LITE that PKWare includes in the
PKLite distribution!

     So what is going on?  The detectors I use (CHK4COMP and CHK4LITE) have
no problem with the .EXE files, just the .COM files.  Just to make things
stranger, PKLite itself is able to detect whether a .COM file has been
compressed by itself.  Also, I have noticed that version 1.15 compresses
the identical .COM file to 2 bytes more than version 1.14.  No idea if this
is related.  Any ideas?

     This is not machine or TSR dependant.  I tried it on an AT and XT, with
a full set of TSRs and with a blank memory.

 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|  Arnold Gill                        |   - If I hadn't wanted it heard,      |
|  Queen's University at Kingston     |         I wouldn't have said it.      |
|  InterNet:  gilla@qucdn.queensu.ca  |   - Astrophysician in training        |
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.compression
From: ohumukin@spectra.com (Kawika Ohumukini)
Subject: Voice data and Stacker
Organization: Spectragraphics Corporation
Date: Wed, 11 Nov 92 01:17:03 GMT

Hi,

I am new to this group and I know very little about compression 
beyond using them and noting file sizes.

What I will be buying is a voice mail card that samples at 1.25K/s
and stores data at 2.5Kbytes/s.
I will be using stacker 2.0 and am wondering what kind of compression 
I can expect?

I don't want to have to manually compress/uncompress data files
as that would require intervention, but if file compression is sufficient
to warrant it I will.

Any tips or suggestions greatly appreciated.

Kawika 
Newsgroups: comp.compression
From: jef0@cbnewsj.cb.att.com (john.e.fetchko)
Subject: compression of small files
Organization: AT&T
Date: Wed, 11 Nov 1992 21:05:09 GMT
Keywords: small files 1024 bytes


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 ?


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


Newsgroups: comp.compression
From: roland@sun-2.cs.uct.ac.za (Roland Paterson-Jones)
Subject: Re: JPEG/MPEG compression in hardware???
Organization: Computer Science Department, University of Cape Town
X-Newsreader: Tin 1.1 PL5
Date: Tue, 10 Nov 1992 07:11:28 GMT

brycerw@brandonu.ca wrote:
: A few months back, I read about a Motorola chip that has compression algorithms
: (JPEG or MPEG) in hardware, for (de)compression somewhere on the net.  This
: may have been a rumor.  Can anyone confirm/deny this?
: 
: And if the chip does exist, what are its requirements, speeds, inputs, outputs,
: etc.?  I'd be wanting to tie it into an Amiga.
: 
: --Rob

We're doing a project here which will involve JPEG compression hardware on
3/486 machines. Does anyone know what's available here?

Mail or postage will be appreciated.

--
Roland P-Jones			aka roland@uctcs.cs.uct.ac.za
University of Cape Town		 or roland@sun-2.cs.uct.ac.za
South Africa
From: deatz@gandalf.rutgers.edu (Gregory H Deatz)
Newsgroups: comp.compression
Subject: best method for compressing text files
Date: 10 Nov 92 05:59:59 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I know that this question has been posted to the group before, but I am looking for a compression method (preferably extremely portable code) that is best
in compression (*not* speed) for text files exclusively (or not). PostScript
files tend to be extremely cumbersome, and pkzip just doesn't do the job to
make it feasible to transfer most ps files between a dos machine and a unix
machine when the modem speed is 2400 bps.

I'd like to have some code or two identical packages: one for unix, one for
msdos, so that a 500K text file will be considerably smaller than 500K, i.e.
<< 100K. Does anyone have an answer for me either negative or positive? Speed
is of no concern to compress the files when it will most likely take much less
time than the 20-30 minutes for file transfer with pkzip techniques, and it
is also time consuming to generate the ps files from wp51.

I would rather that you *post* your replies to the newsgroup; however, if this
is cumbersome to the group, feel free and reply by e-mail.
From: ytsai@clyde.ICS.UCI.EDU
Subject: (none)
Newsgroups: comp.compression
Date: 5 Nov 92 06:12:06 GMT

Hi,

	I am looking for a software to decompress .LZH files on MS-DOS, where
can I find it?
	Is there a software which can compress a file as much as 70-80% (and
the compressed file should be self-extractable).

	Thank you very much for your pointers. Please email your response to

		ytsai@clyde.ics.uci.edu

Thanx
Youhua Tsai
Newsgroups: comp.compression
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: How well do random files crunch?
Date: Fri, 13 Nov 1992 15:16:07 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <1992Nov13.135437.19044@decuac.dec.com>,
by bell@ufp.enet.dec.com ():
> 
> So the probability for any given character to occur is 1/256, no matter
> the file length (because it's an even distribution).

	Don't expect any compression.  In fact, expect some expansion
	with any compression algorithm that's not theoretically optimal.
> 
> How about for a parabolic distribution?  I mean (since I'm not that good
> with statistics) that it's more likely to get a high or low number, that
> one close to 0.5.  Do you think that would make any difference?

	If different characters have significantly different
	probabilities, expect some compression with just about any
	decent compression algorithm.  If the likelyhood of different
	characters depends in any way on the context in which that
	character is found, expect to gain from higher-order source
	models.

	For example, you can construct strings where all letters are
	equally likely, but where the letters A-M are always followed
	by the letters N-Z and vicea versa.  In such a "language",
	A simple Huffman code won't manage to compress anything, but
	both LZW and context dependant Huffman coding will compress
	the files fairly well.

					Doug Jones
					jones@cs.uiowa.edu
Newsgroups: comp.compression
From: 303JKJAN%VAX9K.DNET@NCHUD1.NCHU.EDU.TW (jinn-ke jan)
Subject: Re: Compression + Standards = Trouble?
Organization: Dept. of Applied Math. Nat'l Chung Hsing University
Date: Thu, 5 Nov 1992 14:56:35 GMT

In article <Bwy39p.HxK@news.cso.uiuc.edu> jy10033@ehsn20.cen.uiuc.edu (Joshua M Yelon) writes:
>From: jy10033@ehsn20.cen.uiuc.edu (Joshua M Yelon)
>Subject: Compression + Standards = Trouble?
>Date: Fri, 30 Oct 1992 17:29:45 GMT
>There's been a big discussion under comp.os.linux about which
>compressor to use...  most people think that we should use compress,
>since everybody has "uncompress", but not everybody has unzip
>or melt.
>
>I was a little bothered, though, that we were tied to an obsolete
>compression program simply because "uncompress" is the only one
>available as part of the standard unix distribution.  Of course,
>we could try to convince vendors to start putting unzip or melt
>into their distributions, but by the time we succeeded, those
>would be just as obsolete.
>
>I therefore started trying to design an obsolesence-proof compression
>standard.  It seems to me that the only way to achieve this is by
>using self-extracting archives.  Any compressor can use any newfangled
>compression scheme it wants, without fear that somebody won't be able
>to process the result, as long as the archive is self-extracting.
>
>However, self-extracting archives typically have problems of their own:
>
>    * they include decompression code, which involves overhead,
>    * they are executable binaries, and can transmit viruses,
>    * the included decompression-code is typically machine-dependent. 
>
>All of these can be solved by writing the decompression code in
>some machine-independent p-code, with no dangerous instructions
>(thereby preventing viruses), and a special instruction for doing
>lempel-ziv decompression (which can be used as a one-line decompression
>program for those cases when the overhead isn't worthwhile).
>
>Unfortunately, a pcode interpreter might be slow, compared to
>decompression code written in assembly language.  Potential solution:
>don't write a pcode interpreter, write a pcode compiler.  Have it
>cache the compiled versions of decompression headers that it's seen
>before.
>
>What I'd like to know is, what am I forgetting?
>
  Might be the executable binaries are OK., since the technique of software
 authentication may be used for preventing viruses. For details please refer
 to (1). Okamoto,E and Masumoto, H(1990):ID_Based authentication systems for
 computer virus detection, Electronics Letters, Vol.26, No. 15, July 1990.
 (2). Harn, L. et al(1992): A software authentication systems for the 
   prevention of computer viruses, Proceedings of ACM 1992 computer science
   conference, March 1992.
 J. K. Jan.
Newsgroups: comp.compression
From: gerd@p.igp.ethz.ch (Hans-Gerd Maas)
Subject: realtime compression boards?
Keywords: JPEG, MPEG
Reply-To: gerd@p.igp.ethz.ch
Organization: Swiss Federal Institute of Technology Zurich
 Institute of Geodesy and Photogrammetry
 CH-8093 Zurich    (Switzerland)
Date: Mon, 9 Nov 1992 16:06:35 GMT


Hi, 

I am searching for possibility of storing short image sequences (10 ... 30 sec)
of 3 or 4 synchronized CCD cameras to the harddisk of a SUN (S-Bus) or a PC. As
realtime disks and image sequence RAM are rather expensive, my idea was to use
a board doing JPEG or MPEG compression in realtime and writing the compressed
data to the harddisk.

My questions are:
1.) Where do I get realtime JPEG/MPEG compression boards?
2.) Who has got experiences with such boards?
3.) Is there any possibility of having two or more boards in one host? 
    Does it make sense to use an RGB JPEG compression board and 'cheating' it
    by supplying data of 3 synchronized camaras simultaneously?

Hans-Gerd

Newsgroups: comp.compression
From: a7657@mindlink.bc.ca (Stephen H. Kawamoto)
Subject: Re: Masters Thesis in Parallel Image Compression
Organization: MIND LINK! - British Columbia, Canada
Date: Wed, 11 Nov 1992 18:58:38 GMT

ask jloup@chorus.fr for the comp.compression FAQ's or just ask on the topic.
there may be a related FAQ on parallel image compression


--
PGP 384/D7484F Stephen Kawamoto

a7657@mindlink.bc.ca.


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


begin 666 sign1a.pcx
M"@4!`0`````K`3L`+`$\`````/___P``````````````````````````````
M```````````````````````````!)@``````````````````````````````
M``````````````````````````````````````````````````#E_\'PY?_!
M\.7_P?#E_\'PY?_!\.7_P?#$_\'/X/_!\,3_P<_@_\'PQ/_!Q\W_/]+_P?#$
M_\''S?\
Newsgroups: comp.compression
From: bhh@loki.cs.wayne.edu (Bhaskar Holur)
Subject: Need image/video sequence and info on simulation of MPEG
Keywords: JPEG, book review
Organization: Wayne State University
Date: Mon, 9 Nov 1992 01:19:19 GMT

Hi, I am doing a project on video compression using the latest
International standard (draft), the MPEG algorithm.  Rather, I am
first making a thorough study of the MPEG techniques and as time
permits try to make a software simulation of the building blocks
of the MPEG encoder. I am working on a Sun Sparc 4 workstation.

I am a Computer Science grad student in Wayne State University, Detroit.

MPEG means MOVING PICTURES EXPERT GROUP of the joint ISO-IEC committee
which is developing a world-wide video coding standard (at 1.5 Mbit/s).
The other group is the JPEG for still image compression. 

The purpose of this letter is for asking for help in the following 
directions.  Anybody out there have any sources?

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.

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)

3.  Any info on software implementation techniques or algorithms
    for MPEG simulation.  Since the simulation of the whole encoder
    is quite a involved and big project, I was thinking of starting
    with the important building blocks, like Motion Estimator, for
    the MPEG.  

Actually, last semester I could simulate the still image compression
standard, the JPEG, since it is much easier than MPEG moving-picture
compression.

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

So, I appreciate any help regarding the above directions.
At least you could send me any sources you know!

Thanks a lot,
Bascar.


Newsgroups: comp.compression