HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.compression

lawyer@maple.circa.ufl.edu writes:
>In article <92296.120654U36167@uicvm.uic.edu>, U36167@uicvm.uic.edu writes:
>
>>How do you decompress a tar.Z unix file on a PC.  I am at my wits
>>end in dealin g with this, and any help would be greatly
>>appreciated.
>
>Use the LHARC utility decompression progam.

This won't work.  Check the FAQ for an explanation of all of this.
----------
					Eric Backus
					ericb@hplsla.hp.com
Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Re: compressing gif files
Date: Thu, 12 Nov 1992 06:01:53 GMT
Organization: Recognition Equipment, Inc.

What type of compression is GIFBLAST doing, anyway?  It seems to me that
some saving could be realized by re-encoding the graphic data using a
more state-of-the-art compression engine, such as LZH instead of LZW.
Is this all that it's doing?

-- 
#ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       fuzzy@netcom.com
#define  TRUE   0  |
#define  FALSE  1  |     "History doesn't repeat itself, but it rhymes."
#endif             |                                   -- Mark Twain
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: bitmap compression
Date: 7 Nov 92 16:46:38 GMT
Organization: Academic Computer Centre Utrecht

Somehow the origioal mail didn't arive at my site (happens often)
therefor I reply to a reply.

>umfehr06@ccu.umanitoba.ca (John Fehr) writes:

>>I'm currently looking for compression algorithms to compress weather charts.
>>These charts contain about 95% white pixels, and 5% black pixels.  I've
>>already thought of using GIF, but the files only shrink down to ~100k.
>>(Originally ~1meg uncompressed.)  I've also thought of using arithmetic
>>coding.  Does anyone have any suggestions as to other compression methods?
>>  Thanx for your help,
>>    John


Your problem is excactly the same as compressing FAX messages. FAX also
is a lot of white with some black now and then. What you should do
is a two step tranformation. First you define a dictionary of variable
length strings. This should be like:

A = 1
B = 11
C = 0
D = 00
E = 000
F = 0000
G = 000000
H = 000000000
etc.
Some experimenting to get the optimal set might be needed. Looking at
the FAX compression specs (CCITT) might help.

The first step of compressing is transforming the file into these symbols.
You try to get as low as possible symbols. This is not very hard to do:
Count the length of a string and encoding it in these symbols.

These symbols can then be encoded with Huffman a standard compression
algo. Depending on wanted speed and consistency of the data you can
use static or dynamic Huffman compression.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
From: jls11@po.CWRU.Edu (John L. Spetz)
Newsgroups: comp.compression
Subject: Unzip50 bug??
Date: 12 Nov 92 23:00:14 GMT
Reply-To: jls11@po.CWRU.Edu (John L. Spetz)
Organization: Case Western Reserve University, Cleveland, OH (USA)
NNTP-Posting-Host: slc5.ins.cwru.edu


I recently tried to unzip a zip1.9 generated archive located on a floppy
disk which had bad sectors in areas used by the archive.  I was aware of
the disk problems, but tried to unzip whatever could be saved to my
286's hard drive.  Problem is when unzip50 reached the bad sectors it
just kept reading until some temp file on the hard drive had exhausted
all the free space.  At this point the program crashed and I had to run
Disk Doctor to get back some lost sectors that had been generated.  I
tried again using pkunzip193a and was able to retrieve all files not
affected by the bad sectors.

I was using the precompiled executables from wuarchive, and was
wondering whether the problem lies in the code of unzip50, or whether 
some library routine from compiler x may be at fault.
From: mapimhn@gdr.bath.ac.uk (I M H Nadiadi)
Newsgroups: comp.compression
Subject: Re: Need C source for fractal compression
Date: 5 Nov 92 09:10:20 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: Jack.Doff@f262.n633.z3.fidonet.org (Jack Doff)
Newsgroups: comp.compression
Subject: Lossy Compression
Date: Tue, 03 Nov 1992 19:51:01 +1100

Hi there,

I'm working on some data sampling hardware, but need to be able to
transmit the 16Kbit/s data stream along a 9600 b/s modem link... So I
need some way to simply compress the 2kbyte/s (which looks to simply be
fairly repetitive. ie. large strings of 1's and 0's) down by at least
4:1

Any suggestions?


AtDhVaAnNkCsE

Have a better one,
        Curt Slanger

  SLMR 2.1a  Why?  Why not?
 * Origin: The Infinity Links BBS  (3:633/262)
Newsgroups: comp.compression
From: thenglid@linda.lidac.liu.se (Thomas Engstrom)
Subject: Re: compression of small files
Keywords: small files 1024 bytes
Organization: Computer Service Centre, University of Linkoping
Date: Thu, 12 Nov 1992 08:40:29 GMT

jef0@cbnewsj.cb.att.com (john.e.fetchko) writes:


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

On a machine that allocates disk blocks in 1024 bytes blocks or more,
there would be waste of time to compress "small files". The same goes
for files smaller than 512 bytes on a machine with 512 bytes blocks.



Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: bug in PKLite 1.15??
Organization: University of Vaasa, Finland
Date: Wed, 11 Nov 1992 05:33:29 GMT

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!

Have you considered contacting PKWare.  Their email address can be
found in 
 14420 Oct 21 20:57 garbo.uwasa.fi:/pc/pd2/author11.zip

But I am not sure what the response to feedback to that adress will
be. 

..................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland

Xref: sparky comp.compression:3834 comp.binaries.ibm.pc.wanted:7228
From: MEB117@psuvm.psu.edu (Matthew E. Bernold)
Newsgroups: comp.compression,comp.binaries.ibm.pc.wanted
Subject: ARJ password cracker.
Date: 13 Nov 92 23:43:26 GMT
Organization: Penn State Star Trek club
X-Star-Trek-Quote: He's Dead Jim.
X-School: Penn State University
X-Nickname: <<APOCALYPSE>>, Lord of Destruction

My friend made a MAJOR boo-boo (tm) eariler on today.  He accidentally lost
his "little black book" where he kept among other things the passwords to
his .ARJed archives.  He has some of the files, but for most of them, the
only copy he has left is in the archive, and he can't get to them.  I know
I've read about password crackers for WordPerfect documents, and .ZIP files.
Is there such a beast for .ARJ files?

Thanx,

       Matthew E. Bernold             MEB117@PSUVM.PSU.EDU
         <<APOCALYPSE>>                  meb@haydn.psu.edu
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: information about compression
Date: 9 Nov 92 17:07:00 GMT
Organization: Academic Computer Centre Utrecht

In <marfleet.721272910@manning> marfleet@cs.UAlberta.CA (Marfleet Kent E) writes:

>Hi,  I'm interested in learning about compression 
>algorithms, how they work etc. 
>Could someone tell me what books would be good to read
>on the subject?  

A good place to start is the comp.compression FAQ.

Locating the comp.compression FAQ:
 * The FAQ is posted often to comp.compression and should also be available
   on news.answers as "comp.compression Frequently Asked Questions".
 * The FAQ is also available by anonymous ftp on rtfm.mit.edu [18.72.1.58]
   in directory /pub/usenet/news.answers/compression-faq, files part1 and part2.
 * If you don't have FTP access, you can get the FAQ by a mail
   server.  Send an email message to mail-server@pit-manager.mit.edu
   containing the command "help" (no quotes) for more information.
 * If all above REALLY fails, request the files from nevries@cc.ruu.nl 

>Kent

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
Organization: School of Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.compression
Date: Thu, 12 Nov 1992 00:31:13 -0500 
From: Andrew Lewis Tepper <at15+@andrew.cmu.edu>
Subject: How I won $10

A couple years ago I bet a friend that I could write a program to read
his mind. Specifically, the computer would write "I predict you will
type 0", or "I predict you will type 1". We would cover the screen up
with a post-it note to prevent cheating. To win $10, the program would
have to score 55% or better.

My algorithm looked at past patterns of 1,2,3,etc bit sequences, and
made it's prediction based on that. The computer got 569 out of 1000,
and I won. Now, he was really trying to be "random". If you don't try
too hard, the computer will often get 70-75%. My question is, is there a
compression scheme that uses this technique? In certain kinds of data,
bits could often be represented by (nearly) _zero_ bits of compressed
data! Perhaps just a number that said "go on guessing for 136 bits".
What kind of results do such algorithms achieve, if they in fact do
exist?

Andy

Newsgroups: comp.compression
From: umfehr06@ccu.umanitoba.ca (John Fehr)
Subject: bitmap compression
Organization: University of Manitoba, Winnipeg, Canada
Date: Thu, 5 Nov 1992 19:12:44 GMT

I'm currently looking for compression algorithms to compress weather charts.
These charts contain about 95% white pixels, and 5% black pixels.  I've
already thought of using GIF, but the files only shrink down to ~100k.
(Originally ~1meg uncompressed.)  I've also thought of using arithmetic
coding.  Does anyone have any suggestions as to other compression methods?
  Thanx for your help,
    John


-- 
-----------------------------------------------------
-  John Fehr                        -    DoD#505    -
-  umfehr06@ccu.umanitoba.ca        -    GPz550     -
-  umfehr06@silver.cs.umanitoba.ca  -  A3000 kicks! -
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: tar.Z
Organization: University of Vaasa, Finland
Date: Sun, 8 Nov 1992 05:58:16 GMT

In article <147850002@hplsla.hp.com> ericb@hplsla.hp.com (Eric Backus) writes:
>lawyer@maple.circa.ufl.edu writes:
>>In article <92296.120654U36167@uicvm.uic.edu>, U36167@uicvm.uic.edu writes:
>>>How do you decompress a tar.Z unix file on a PC.  I am at my wits
:
>>Use the LHARC utility decompression progam.

When I first saw this I thought that this is some kind of a prank on
the poser of the question. 

>This won't work.  Check the FAQ for an explanation of all of this.

  44641 Oct  2 20:14 garbo.uwasa.fi:/pc/doc-net/faqc9210.zip
 115799 Sep 20 08:35 garbo.uwasa.fi:/pc/ts/tsfaq30.zip

"If you do not know how to go about getting this material, users are
welcome to email me for the prerecorded garbo.uwasa.fi instructions
(long, circa 29Kb).  North American users are referred to the Garbo
mirror on wuarchive.wustl.edu.  Australian users are referred to the
archie.au mirror.  For the Asian users there is the NCTUCCCA.edu.tw
mirror.  The mirrors may lag occasionally, or might not have all the
files.  If you do not receive my reply within five days, please ask
your own site's system manager to construct a returnable mail path
for you". 

..................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland
Newsgroups: comp.compression
From: frank@truevision.com (Frank Loffel)
Subject: Looking for lossless audio compression
Organization: Truevision Inc., Indianapolis, IN
Date: Wed, 11 Nov 1992 23:48:40 GMT

Hello

I'm looking for literature describing algorithms for lossless audio 
compression. The signal is 16 bits stereo at 44.1 kHz. I'm looking
at implementing the algorithm on a DSP for realtime execution.

Given that the compression has to be lossless, a modest compression ratio
is acceptable.

Maybe some of the DSP vendors (TI, Motorola) publish such algorithms?

Any references are most welcome. Thanks.

-- 
-- Frank Loffel, Truevision, Inc, uunet!epicb!frank frank@truevision.com :-) --
-- "Shut up and pleasure me!" - Peg Bundy
Newsgroups: comp.compression
From: a7657@mindlink.bc.ca (Stephen H. Kawamoto)
Subject: Re: Lossy Compression
Organization: MIND LINK! - British Columbia, Canada
Date: Thu, 12 Nov 1992 23:32:10 GMT

Wouldn't it just be easy to implement MNP5 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?\
From: zappe@mikro.ee.tu-berlin.de (Harald Zappe)
Newsgroups: comp.compression
Subject: Re: SQZ compression
Date: 6 Nov 1992 01:01:31 GMT
Organization: ZRZ/TU-Berlin
Distribution: comp
NNTP-Posting-Host: mikro.ee.tu-berlin.de

In <3287@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

>In <1992Nov2.133953.15692@vax5.cit.cornell.edu> mmy@vax5.cit.cornell.edu writes:

>>It seems that SQZ is able to compress slightly better than PKZIP 1.93 or ARJ
>>2.30, does anyone know what kind of compression it uses? And how is it able to
>>outperform PKZIP/ARJ in terms of compression ratio?

>There are two "tricks" SQZ uses. First one is it takes more time to look
>for matches. Second one is that its directory structure is smaller than
>than of PKZIP and ARJ (e.g. no extra central directory). Beyond this
>SQZ does not differ much from ARJ or PKZIP.


Because of this you CAN get better results with ARJ. In the special case of
MOD-files (header+song+div. samples) I knew that ARJ produced the best results
with a Huffman Buffer Size of 3KB (arj option -jh3072). SQZ was worse than
ARJ, but only in this special case.

Harald

 
#----------------------------------------------------------------------------

zappe@mikro.ee.tu-berlin.de      | |
zappe@sony1.sietec.de            |-+-
zappe@idefix.sietec.de           | |/
                                   /
                                  /__
From: abirenbo@rigel.cel.scg.hac.com (Aaron Birenboim)
Newsgroups: comp.compression
Subject: Math Question
Date: 14 Nov 92 01:38:56 GMT
Organization: Hughes Aircraft Colorado Engineering Labs


While working on an optimization problem related to compression
I bumped into the following nasty little problem :

   evaluate:

                {           [(i+1)q                                      }
             d  {           [                                            }
            --- {  Integral [      (x - (i + 0.5) q)^2 * exp(-c * x) dx  }
             dq {           [                                            }
                {           [i*q                                         }

  I have evaluated the integral..... and it is terribly nasty.  Even if I
didn't goof on the evaluation, i would surely goof on the differentiation.

  c and i are constants.  I'm trying to minimize error for q.

  I seem to remember some terribly nasty formulas for handling the
differentiation before evaluating any integral.

  I think it involved the bounds, derivitives of the bounds, the integrand
and the derivitave of the integrand.

  My memory comes from a dim recolection of some stuff covered
by Dr. Sawchuk at USC (southern cal) in a class on random variables
based on the book by papoulis.  I cannot find it mentioned in papoulis...
i think is was ONLY in Sawchuk's notes (which i cannot find).

  any advise, help, or refrences are welcome.

  If i knew the NAME of this theorem, I might be able to look it up.

     thanks in advance,

--
Aaron Birenboim         |
birenb@hac2arpa.hac.com |
                        |
H (303) 871-8271        |
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: best method for compressing text files
Date: 10 Nov 92 22:14:55 GMT
Organization: Academic Computer Centre Utrecht

In <Nov.10.00.59.59.1992.29852@gandalf.rutgers.edu> deatz@gandalf.rutgers.edu (Gregory H Deatz) writes:

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

If you want the best there are three options. Higher order arithmetic
compression (Nelson wrote some of those). Ashford compression (C source
included in my LDS_10 package I uploaded to garbo.uwasa.fi (still not
available :-()). And SAKDC from Ross Wiliams (he wrote some book on this).

SAKDC is the best one, Ashford comes close and is freely available.

Notice you get what you asked for, these are VERY slow.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

"The IBM PC is still waiting for a version of the CP/M OS.", G.M. Vose, 1982.
Newsgroups: comp.compression.research
From: umws@pool.info.sunyit.edu (Michael Seeley)
Subject: Re: Need C source for fractal compression
Organization: State University of New York -- Institute of Technology
Date: Fri, 6 Nov 1992 00:21:09 GMT

In article <Bx70nz.32p@dcs.ed.ac.uk> cdw@dcs.ed.ac.uk (Christopher Walton) writes:
>And me as well !
>
>Chris Walton (cdw@dcs.ed.ac.uk)

If someone does get a hold of a copy, I would like one.


-- 
"Villains!" I shrieked, "dissembled no more!     | 	E-Mail
I admit the deed!-tear up the planks!--here,     |
here!--it is the beating of his hideous heart!"  |   umws@sunyit.edu
=-=-=-=-=-=-=-=  Edgar Allan Poe  =-=-=-=-=-=-=-=|
Newsgroups: comp.compression.research
Subject: Grayscale image MYSTERY technique....
From: pollarda@physc1.byu.edu
Date: 6 Nov 92 10:17:51 -0700
Distribution: world
Organization: Brigham Young University


A while back, (6 months?) I saw a posting on a new grayscale
image compression technique that was developed in Canada.  It was
reported to have quite good compression performance and was supposed
to appear in an upcoming issue of BYTE.

Well, I have not seen it come out (is it possible I am just blind) X-)
and I am _very_ interested in finding some more information on the 
technique. Unfortunely, I didn't keep a copy of the original post :-(

Does anyone have information on this?

I believe the guy who was doing it was named Nelson but, I may be wrong.

Thanx in advance for any replies.

Art
pollarda@xray.byu.edu
From: kmurali2@uoft02.utoledo.edu
Newsgroups: comp.compression.research
Subject: Help-Adaptive Huffman Code
Date: 9 Nov 92 15:14:59 EST
Organization: University of Toledo, Computer Services


Hi Netters,

I am planning to use Adaptive Huffman Coding for images. Hopefully It will 
compress the Bit Per Pixel more than Huffman code. 

Is there any source or place that I can get the algorithm for adaptive 
Huffman code?

Please send a note to my e-mail address.

Thank you,
Murali.k 
Newsgroups: comp.compression.research
From: bedros@loon.cs.umn.edu (Saad Bedros 625 7542)
Subject: Question about Quantization in the DCT domain
Organization: University of Minnesota, Minneapolis, CSci dept.
Date: Fri, 6 Nov 1992 15:11:48 GMT


working in quantization for the DCT coefficients, I know I can apply
MAX quantizer for the ac coefficients with a laplacian source,
But for the DC term, a uniform quantization is best.
What is the best approach for quantizing the DC term:
 1- calculate the min and max, then quantizing using 8 bits after
     normalization. in this case, the min and max should be transmitted.
 2- find a global max for the DC, normalize then quantize. I know in JPEG
    they use 16 as a quantization level.

What is the advantage to set the range between -128,128 instead 0,255
before taking the DCT ? ( I think that is what they do in JPEG)

By the way, I was looking for a DCT in matlab, and I got one, not fast
but not slow if somebody is intersted.

Saad Bedros
U of Minnesota
From: mou@nova2.stanford.edu (Alex Mou)
Newsgroups: comp.compression.research
Subject: Re: Question about Quantization in the DCT domain
Date: 11 Nov 1992 05:41:30 GMT
Organization: Stanford University
NNTP-Posting-Host: nova2.stanford.edu

In article <1992Nov6.151148.7943@news2.cis.umn.edu> bedros@loon.cs.umn.edu (Saad Bedros 625 7542) writes:
>
>working in quantization for the DCT coefficients, I know I can apply
>MAX quantizer for the ac coefficients with a laplacian source,
>But for the DC term, a uniform quantization is best.
>What is the best approach for quantizing the DC term:
> 1- calculate the min and max, then quantizing using 8 bits after
>     normalization. in this case, the min and max should be transmitted.
> 2- find a global max for the DC, normalize then quantize. I know in JPEG
>    they use 16 as a quantization level.

From a hardware implementation point of view, finding a global max may
need quite an amount of memories to accomodate all transformed blocks.
This is the drawback I see in the second method.

>
>What is the advantage to set the range between -128,128 instead 0,255
>before taking the DCT ? ( I think that is what they do in JPEG)
>

The advantage is to simplify H/W implementation.
Hardware implementation usually uses 2's complement representation of 
numbers. That is the cause.

>By the way, I was looking for a DCT in matlab, and I got one, not fast
>but not slow if somebody is intersted.
>
>Saad Bedros
>U of Minnesota