HDTenEightyP/NetNews huggingface dataset:
From: IRHANV00@UKCC.UKY.EDU
Subject: Re: Best compression for 24 bit images
Organization: University of Kentucky
Date: Fri, 28 Aug 1992 23:12:21 GMT

In article <1992Aug28.133552.16085@crd.ge.com>
davidsen@ariel.crd.GE.COM (william E Davidsen) 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.
>
>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.
 
There is a compression progrm out called HPACK which works wonders on image
files. This utility is available on many archives, including wuarchive. I have
seen compression using this utility on many image file formats which went from
about 20% to up to 60%! Everone knows this is remarkable for images. Try it out
for yourself. It is lossless (as far as I was able to discern). I compressed &
decompressed some image files, then compared the result to the original image
file and they were identical. The one thing I should mention, however, is that
in the version I have, the author states that this version is a prototype, so
bear that in mind.
                                              Forrest
Newsgroups: comp.compression
From: cts@cs.hut.fi (Charles Sederholm)
Subject: Re: H.261 Codec
Organization: Helsinki University of Technology, Finland
Date: Mon, 31 Aug 1992 10:12:13 GMT


In article <1992Aug30.114315.8406@nuscc.nus.sg> eng40010@nusunix2.nus.sg (CHUA KEE LAM) writes:

	   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)

==

I can direct you to at least two nice implementations of H.261:

- one for WAN use 64 kbit/s ... 2 Mbit/s 
(ISDN, pre-ISDN (IDA, Transcom, IDN64000...), leased line, Accunet, ...)
- one for use in Ethernet LANs (!) - no I'm not kidding... and it
works extremely well

Both implementations are based on PC-cards that fit into ISA/EISA
buses. So far only DOS drivers are available. The size (one resp. two
AT-bus cards) is the main difference to other implementations, that
usually are huge and expensive boxes. Another important point is that,
at least the first mentioned, is offered to developers and system
integrators on OEM basis.

(They are not made by the same company).

I don't think it's appropriate to put commercial release info here -
and my direct mail to you bounced - so if you ( or anyone else) would
like to know more, please send me your (fax/snailmail) adress - or a
corrected email adress (prefered).

Regards,

charles

--
Charles Sederholm
cts@cs.hut.fi       Phone (nat): 90-1390012      Fax (nat): 90-4513293
                          (int): +358-0-1390012      (int): +358-0-4513293
                    Institute of Industrial Automation; Room Y228
                    Helsinki University of Technology
                    Otakaari 1; SF-02150 Espoo; Finland





Newsgroups: comp.compression,comp.compression.research,comp.multimedia,sci.image.processing,comp.graphics
From: mack@deci.cs.umn.edu (Dan Mack)
Subject: Re: Question: difference in viewed and printed images
Organization: University of Minnesota
Date: Thu, 3 Sep 1992 19:53:17 GMT

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)

>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

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.

Monitors use the RGB color space and are capable of displaying a whole
range of colors within a certain 'gamut'.  Printers use CMY(k) and can
also display a  whole  range of colors from a different looking gamut.
As you might  guess, it's easy to display  red  on a monitor, but it's
not so easy to display red on printer using Cyan, Magenta and Yellow.

Anyway, this a little of what I recall from my computer graphics
class.  As far as I can remember, color theory doesn't involve much of
compression research so maybe ask the folks in comp.graphics.*

Dan
--
-- -- -- --- --- --- ---- ----  ___  ---- ----- ----- ----- ------ ------ -----
Dan Mack (mack@cray.com)       / | \   	  "We're not hitchiking anymore... ..
Sun/SGI Resource Group         \/_\/           We're riding!"  -Commander Hoek
Cray Research, Eagan MN   ----- ----- ----- ---- ---- ---- --- --- --- -- -- --
Newsgroups: comp.compression
From: teodor@proxxi.se (Teodor V{{n{nen (proxxi))
Subject: NEED JPEG/MPEG INFO
Organization: proxxi
Date: Sun, 30 Aug 1992 18:47:31 GMT

Hi there !

I would like the following information about JPEG / MPEG :

1)  Is there any book(s) that contains algorithms and/or formulas for 
    compression / uncompression of JPEG / MPEG images and contains
    other important info about ALL JPEG / MPEG levels ?

2)  How many manufacturers are there that manufacture or sell 
    JPEG / MPEG compression / uncompression chips?
    Please include adress, telephone No. and ev. prices.

3)  Is there any "?PEG" algorithm for compression / uncompression of
    sound ?  You can include names of other sound compresion systems,
    but in that case I would like to know if there are any:
    - books about the system that contains algorithms to (un)compress sound?
    - chips that compress / uncompress sound (I would like the name of the
      comany )?
    - other useful info about the compression method:

Thank you.

Mail me directly at E-Mail adress: teodor@proxxi.se    
( I don't read this newsgroup so often ).
        __ _
Teodor Vaananen

























































-- 
------------------------------------------------------------------------------
                                              __ _
teodor@proxxi.se                    ( Teodor Vaananen )
Ham Radio: SM0TVI (2m ONLY (In Stockholm (145.625 MHz (Rpt input 600 KHz down)
Newsgroups: comp.compression
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: "Instant Gigabytes?"
Organization: Metaflow Technologies Inc.
Date: Tue, 1 Sep 1992 19:58:45 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.
|> 
|> 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
 . . .
|> 
|> Thanks for any enlightenment.
|> 
|> --
|> Ben Rudiak-Gould
|> benrg@ocf.berkeley.edu

See the FAQ, please.  The punchline is that WEB Technologies recently
admitted that they are unable to produce the claimed product.  
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, CA  92037     Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.compression,comp.binaries.ibm.pc.archives
From: roelofs@pan.arc.nasa.gov (Cave Newt)
Subject: Re: zip 1.9 and unzip 5.0, Unix versions, at garbo
Organization: University of Chicago
Date: Wed, 26 Aug 92 05:54:22 GMT

madler@cco.caltech.edu (Mark Adler) writes:

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

Well, modulo the bug noted in the BUGS file. :-)  Unix/VMS <--> MSDOS
works fine, and Unix/VMS <--> Mac works, but Mac <--> MSDOS probably
doesn't, and MSDOS <--> MSDOS definitely doesn't (that is, don't use
UnZip's -a option on textfiles if they're already in MSDOS format).

To be rewritten for the next release...

Greg Roelofs
From: chauhand@sumax.seattleu.edu (Digvijay Chauhan )
Newsgroups: comp.compression
Subject: Info required on computation of NMR (Noise-to-Mask Ratio)
Keywords: NMR, masking flag, audio compression
Date: 2 Sep 92 18:08:03 GMT
Article-I.D.: sumax.4938
Organization: Seattle University, Seattle, WA

Hi,
I am looking for information on how to compute the NMR (Noise-to-Mask
Ratio) and the masking flag for evaluating the quality of an audio
compression algorithm.
Any pointers would be most appreciated.

Thanks,
Digvijay
--------------------------------
internet: chauhand@seattleu.edu
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Best compression technique & ratio for (ascii) text
Date: 3 Sep 92 10:26:33 GMT
Organization: Academic Computer Centre Utrecht

In <BtztDo.3oB@casper.cs.uct.ac.za> roland@sun-2.cs.uct.ac.za (Roland Paterson-Jones) writes:

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

As long as fast decompression is important the best solution for ASCII
compression seems to be the LZHUF method as used in PKZIP, ARJ, LHA etc.
This method compresses in two stages, the first one locates repeated
strings and replaces them with pointers, the second stage compresses
the output of the first stage with Huffman compression. Both compression
and decompression are fast. Decompression is even extremely fast. LZHUF
gets about 33% more compression than LZW (the LZHUF compressed file
is 33% smaller than the LZW compressed file).

For sources on this subject AR002 and InfoZIP are interesting (see FAQ
for locations etc).

A little slower at decompression but even more compression can be
achieved by replacing the Huffman component by an arithmetic compressor
like e.g. HPACK does.

For ultimate compression much slower compressors like Dynamic Markov
modellers are needed. There ratio is amazing, there slowness is even
more amazing.

>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


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.
From: colin@comms.ee.man.ac.uk (Colin Boyd)
Newsgroups: comp.compression
Subject: Looking for Ian Witten's Email address
Date: 1 Sep 92 17:19:37 GMT
Organization: Comms Research Group, EE Dept, Manchester University, UK.

Sorry for the intrusion. Subject says it all. I have his old address at
Calgary but believe he has moved to NZ. Thanks if you can help.

For those who do not know, Ian Witten is one of the authors of the excellent
book "Text Compression" by Bell, Cleary and Witten, Prentice Hall, 1990.

--
Colin Boyd (colin@comms.ee.man.ac.uk)
Tel: +44 61 275 4562 (Direct line) Fax: +44 61 275 4512
From: zeke@esosun.UUCP (James Dehnert)
Newsgroups: comp.compression
Subject: MPEG info
Date: 1 Sep 92 22:07:42 GMT
Reply-To: zeke@esosun.css.gov.UUCP ()
Organization: Science Applications International Corp., San Diego


  I have been able to find all the info i could ever want about jpeg,
but I have yet to discover anything on mpeg available on the net.  
  Does any one know where I can find any info on mpeg?

  Thanks,
	Zeke
Newsgroups: comp.compression
From: grabenst@umbc4.umbc.edu (Mr. Michael Grabenstein; ACS (GUEST))
Subject: compression code
Organization: Univ. of MD, Baltimore County
Date: Fri, 4 Sep 1992 16:31:22 GMT

	If I write an archiving program where could I go to
get a PD compression code? (or algorithym?) And what are the
legal problems I might incurr? And since these are probably in
a faq somewhere, where is it?
	What and where are some good free compression routines?
I would be archiving a broad array of file types, so routines 
designed around a specific file type are of little to no use 
to me.
	Thanks, I am kinda new in this sub :-).


Later,
	Mike
	ZMEG@AACC.bitnet
	or grabenst@umbc3.umbc.edu
}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{
The universe -- The ultimate fractal. 
	--Personal theroy
Newsgroups: comp.compression
From: rpb0804@zeus.tamu.edu (BATES, ROBERT PATRICK)
Subject: Re: STACKER OR PC STORE OR ????????
News-Software: VAX/VMS VNEWS 1.41    
Organization: Texas A&M University, Academic Computing Services
Date: Thu, 3 Sep 1992 05:26:00 GMT

In article <i10.1@cs-acad-lan.Lakeheadu.Ca>, i10@cs-acad-lan.Lakeheadu.Ca 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.  I've heard a 
>lot about STACKER but relatively nothing about the newcommer PC STORE (I 
>think that's what it's called).  A comparison of these two products would 
>greatly be appreciated, as well as any information on alternative products.
> 
>Thanks a million
> 
>Dan Sullivan

DON'T SCREW WITH STACKER 2.0!!!!!!!!!!!!!!!!!!!!!!!
That SOB almost took out some vital info on my hard drive last semester, and 
restricted drive access to some of my software (I forget which ones...).  Sure, 
it gave me nearly 2x the space after compression, but it just wasn't worth it.  
I figured that between losing important data and shelling out $350 for my 
ST3144A, the IDE drive was a far better deal... As for the other program, I 
don't know about it... The only one I've heard of otherwise is SUPERSTORE on 
DR-DOS 6, and some people have complained about it, too.

Good luck, and have fun!

==============================================================================
Robert Bates                        Disclaimer:
rpb0804@zeus.tamu.edu                   "I make no claims..."
Texas A & M University
==============================================================================
From: i10@cs-acad-lan.Lakeheadu.Ca
Newsgroups: comp.compression
Subject: STACKER OR PC STORE OR ????????
Date: 2 Sep 1992 17:23:18 GMT
Organization: Lakehead University

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.  I've heard a 
lot about STACKER but relatively nothing about the newcommer PC STORE (I 
think that's what it's called).  A comparison of these two products would 
greatly be appreciated, as well as any information on alternative products.

Thanks a million

Dan Sullivan
Newsgroups: comp.compression,comp.compression.research,comp.multimedia,sci.image.processing,comp.graphics
From: sjreeves@eng.auburn.edu (Stan Reeves)
Subject: Re: Question: difference in viewed and printed images
Organization: Auburn University Engineering
Date: Fri, 4 Sep 1992 13:41:40 GMT

In article <Bu18s1.IJt@news.orst.edu> stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
>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.
>
>A 2400 dpi printer should do much better than this, but it is still only
>writing an approximation to gray. 

That is correct, and it needed to be mentioned.  I'm so used to the concept
of halftones that I failed to mention the obvious.  One other important 
point --- the quality of the printed image will depend on the size of a
pixel relative to dots per inch.  Even a 300 dpi printer should be able to
achieve 256 gray levels if the pixels are large enough.  (Of course, you
may have to stand all the way across the room to view the picture!  :-)



--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Re: STACKER OR PC STORE OR ????????
Date: Thu, 3 Sep 1992 23:39:53 GMT
Organization: Recognition Equipment, Inc.

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.

-- 
#ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
#define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
#define  FALSE  1   |
#endif              |         How's my posting?  Call 1-800-ALT-FLAME
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: Tue, 1 Sep 1992 00:09:01 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.

Newsgroups: comp.compression
From: gmribeir@david.wheaton.edu (Glauber)
Subject: Zip 1.9 and Borland C 2.0
Reply-To: gmribeir@david.wheaton.edu
Organization: (n.) Body of persons united for a specific purpose.
Date: Mon, 31 Aug 1992 23:43:26 GMT


I had a bad time trying to compile zip19p1 with Borland C 2.0
I didn't have any problem with unzip, because it included "prj"
files for borland c. Zip has a makefile. The makefile works, it
compiles, but when i try to run the compiled program i get error
messages like:

none matched: !#%$%^$@^$  <- garbage text

and it never works.

Has anybody been successful in compiling with Borland C 2.0?

What have you done?

Could you email me the .prj file, if you made one?

The purpose of trying to compile the program myself is getting a
version with the encryption code. If anyone has such a version,
or knows where i could get one, could you email me? Don't post
the information, because people are affraid of irritating Uncle
Sam (who doesn't want encryption code to be distributed outside
the US, even code that hasn't been created in the US). 


Thank you very much,


						Glauber



-- 
Glauber Ribeiro - Wheaton College, IL  (USA)
                  glauber@david.wheaton.edu 
                  glauber@vpnet.chi.il.us
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: MS-DOS ZIP 1.9 - How much memory needed?
Date: 1 Sep 92 11:53:30 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)

Jim Reisert <reisert@mast.enet.dec.com> runs out of memory
with zip 1.9 on MSDOS.

You can significantly reduce the memory requirements if you compile
zip with -DSMALL_MEM. This will reduce a little the compression speed
and may have a very small effect on the compression ratio. The zip
files produced are of course still compatible with pkunzip 1.93a and
unzip 5.0. You can try also -DMEDIUM_MEM (intermediate between SMALL_MEM
and the default which uses more memory).

If you are seriously short of memory, you can also reduce the window
size, for example by compiling zip with -DWSIZE=8192.  The zip files
will still be compatible with pkunzip 1.93a and unzip 5.0, but this
will of course reduce the compression ratio.

zip was designed to be portable, and runs on a variety of architectures
from 16 bit machines to 64 bit Crays.  I ported zip to MSDOS, but I do
not wish to make it an MSDOS specific program. In particular, I do not
intend to take advantage of EMS memory. I should tune the behaviour of
zip dynamically, depending on the available memory size, but for the
moment I prefer to spend time improving the compression algorithm.
(The sizes of the hash table, string match buffers and IO buffers are
for the moment determined statically and should be dynamic.)

Jean-loup Gailly
jloup@chorus.fr

PS: make sure to use zip19p1.zip, not zip19.zip. The patch level 1
    version includes important bug fixes.
Newsgroups: comp.compression
From: reisert@sttng.mlo.dec.com (Jim Reisert)
Subject: Re: OS/2 compression
Reply-To: reisert@sttng.mlo.dec.com (Jim Reisert)
Organization: Digital Equipment Corporation -- Maynard, MA
Date: Tue, 25 Aug 92 20:32:25 GMT



 # Along that vein, has anybody heard of any announcement for a
 # PKZip for OS/2?

There is a PKware port of PKZIP 1.01 (I think).  I think you can find
it on ftp-os2.nmsu.edu in the pub/os2/all/archivers directory.

- Jim

--
James J. Reisert                Internet:  reisert@sttng.enet.dec.com
Digital Equipment Corp.         UUCP:      ...decwrl!sttng.enet!reisert
146 Main Street			Voice:     508-493-5747
Maynard, MA  01754		FAX:       508-493-0395