HDTenEightyP/NetNews huggingface dataset:
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: fractal image compression
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Fri, 28 Aug 92 19:27:43 GMT

In article <794.1004.uupcb@satalink.com>
	bert.tyler@satalink.com (Bert Tyler) writes:
>RT>How do you know that your stuff doesn't violate the patents held by
>RT>Iterated Systems, Inc.?  How does your method compare with their
>RT>patented method?  Apparently, they have patented both the compress
>RT>stage and the decompress stage.
>
>Confusion reigns.  I was always under the impression that you
>couldn't patent anything without explaining exactly how it works
>(that's part of the patent application), and the Iterated systems
>has consistently refused to explain the details of their technology.

No, they have consistently refused to give away their technical edge
to competitors.  This is not the same thing as explaining how the
technology works.  Barnsley has published two new books: _Fractal Image
Compression_ and _The Fractal Transform_, which explain the details of
the the method (although I'm sure you'd be hard-pressed to achieve
comparable performance to ISI's products).

Also, despite your remarks about patents above, ISI has obtained
patents "worldwide" (according to Barnsley at a press conference held
in July at this year's SIGGRAPH in Chicago).  He has obtained patents
on both the compress and decompress stage, so the code mentioned in
the previous post could be covered by the patent.  Since I have
neither read the code (only binaries are available) nor have I read
the patent, I can't say for sure.  There is no doubt that the patents
exist, though.

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
From: chrisg@cbmvax.commodore.com (Chris Green)
Newsgroups: alt.fractals
Subject: Re: fracting for amiga?
Date: 2 Sep 92 11:23:56 GMT
Reply-To: chrisg@cbmvax.commodore.com (Chris Green)
Organization: Commodore, West Chester, PA

In article <1992Aug31.175212.7839@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes:
>As long as the 256 color assumption isn't too firmly imbedded in the
>code.  My understanding is that this is all over the place.  

	If it is, than the X version is a giant leap backward in that regard,
since the PC version supports 16 colors, mono, etc.
-- 
*-------------------------------------------*---------------------------*
|Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
|                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
|My opinions are my own, and do not         - icantforgettheimpression  o
|necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
|"A screaming comes across the sky..."      - backofmyhead              d
*-------------------------------------------*---------------------------*
From: shirriff@sprite.berkeley.edu (Ken Shirriff)
Newsgroups: alt.fractals
Subject: Re: fracting for amiga?
Date: 1 Sep 1992 05:31:03 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: hijack.berkeley.edu

In article <1992Sep1.044928.19703@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes:
>Is it "easy" to up fractint's max color count from 256?

Fractint allows 24-bit color output in "Targa" form.  I didn't add any of
this to xfractint because I don't have a 24-bit color display to implement
it on.  However, there are no fundamental reasons xfractint couldn't have
24-bit color; it would "just" be a matter of modifying the Targa routines
to use the appropriate X functions.

If you want to up the max color count from 256 to, say, 512, rather than
going to 24-bits, things would break.  In particular, the color map is an
array of 8-bit chars, as are some other important things.

Ken Shirriff			shirriff@sprite.Berkeley.EDU
Xref: sparky alt.fractals:1367 comp.compression:3096
From: fisher@inls1.ucsd.edu (Yuval Fisher)
Newsgroups: alt.fractals,comp.compression
Subject: fractal image compression, yet again - oy
Date: 26 Aug 1992 18:44:47 GMT
Organization: Institute for Nonlinear Science
NNTP-Posting-Host: inls1.ucsd.edu
Summary: Archive update


The latest fractal image compression stuff is available in a 
new directory (/pub/inls-ucsd/fractal-2.0) on lyapunov.ucsd.edu 
(132.239.86.10), accesible by anonymous ftp. The README file contains 
information about the directory contents, which are, roughly, 
PC and sparc executable decompression code, images, and an article 
explaining the method. 

The old fractals directory (/pub/inls-ucsd/fractal_image_processing),
is completely superceded by the new directory, so I recommend ignoring
it (unless you want to compare progress). The images in the new directory 
are not definitive, in the sense that they were not optimally compressed - 
but they are okay. 

Next update: new format with better compressed images and color. In about 2
weeks.

Yuval Fisher											yfisher@ucsd.edu
INLS 0402
University of California, San Diego
La Jolla, CA 92093

Newsgroups: alt.fractals
From: bx304@cleveland.Freenet.Edu (Jeff Epler)
Subject: Plans for Fractint
Reply-To: bx304@cleveland.Freenet.Edu (Jeff Epler)
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Fri, 28 Aug 92 05:00:23 GMT



(Doubtless this ought to be posted on Compu$erve, where the majority of
fractint authors reside, but oh well..)

Are you guys working on 18.0 yet?  (I ask, fully expecting that you
are..)

What additions are you working on?  
New fractal types?  
Innovative speedups?
 (Whatever happened to the ideas used in Fractal Witchcraft, anyhow?)
Other stuff that I can't even think of?

Any idea when we'll be seeing the next version (17.21? 17.3? 18.0?)

I've got one thing to ask, while I'm here -- Has anyone but me been
annoyed at the integer limit to the slope in continuous potential
images?  This limit seems to make usage of the method impossible at
anything more than a moderate zoom.


-- 
|Jeff Epler               Additions Welcome           c(-8 ;-) >{8-) |
| :) (=( =-] (-= Celebrating the variety of faces =-> :^) {-= |-) (: |
| >X^P 8-[                                       __ Lincoln, Nebraska|
|   						 \/ IRC Synger       |
Newsgroups: alt.fractals
From: jmolinari@hamp.hampshire.edu
Subject: fracting for amiga?
Organization: Hampshire College
Date: Mon, 31 Aug 1992 13:58:02 GMT

	I expect that is this is not only futile, but that it will also be
laughed right out of the newsgroup....  What the hell...

		Is there a version of fractint for the Amiga?  :-)

			Thank you for bearing with me.

Newsgroups: alt.fractals
From: stgprao@st.unocal.COM (Richard Ottolini)
Subject: Re: Correlation Dimension
Organization: Unocal Corporation
Date: Tue, 1 Sep 1992 14:47:25 GMT

In article <1SEP199208000925@tm0006.lerc.nasa.gov> hjf5405@tm0006.lerc.nasa.gov (James Fincannon) writes:
>I'm trying to understand how to use the formula for the
>correlation dimension.  It is 
>Cd= lim (log (# of points within R)/log (R))
>    R>>0
>
>R is the Euclidean distance, but do I calculate R with 
>respect to 0,0,0 or to some sort of centroid of the 
>data or what?  Any help is appreciated. Thanks.

Try all two point combinations, sort them in length order, and measure the
slope of log count vs. log distance.  If it is a large dataset, you don't
need to measure ALL pairs, but a reasonable stochastic sampling of them.
From: edgar@function.mps.ohio-state.edu (Gerald Edgar)
Newsgroups: alt.fractals,comp.compression
Subject: Re: fractal image compression, yet again - oy
Date: 31 Aug 1992 09:02:56 -0400
Organization: The Ohio State University, Dept. of Math.
NNTP-Posting-Host: function.mps.ohio-state.edu

In article <17gjevINN4rv@network.ucsd.edu> fisher@inls1.ucsd.edu (Yuval Fisher) writes:
>
>The latest fractal image compression stuff is available in a 
>new directory (/pub/inls-ucsd/fractal-2.0) on lyapunov.ucsd.edu 
>(132.239.86.10), accesible by anonymous ftp. The README file contains 
>information about the directory contents, which are, roughly, 
>PC and sparc executable decompression code, images, and an article 
>explaining the method. 
>

I did some experiments with this.  Since we are limited to the files
provided, these comparisons are far from definitive.

The original file lena is 256x256 pixels, 8 bits of gray-scale information
for each pixel.  Thus it is 64K bytes.  [An 800-byte Sun raster header
is not counted in this.]  The compressed file lena.trn is 4K, about
1/16 the size.  There is some degradation in the image quality.
I used the original to make some compressed files using other compression
methods for comparison.

I made GIF compressions, first with 8 bits per
pixel (lossless), then 7 bits, 6 bits, and so on.  In my judgment, the
file lena.trn had quality between the 4-bit and 5-bit GIFs.  Those GIFs
were 25K and 35K in size.  [By the way, the lossless GIF was 74K, larger than
the original!]

I made JPEG compressions, at various quality levels.  In my judgment,
the quality of lena.trn was equal to that of a JPEG of about 16K in
size.

Based on these very limited tests, for the same quality, the .trn file
was 1/8 the size of a GIF and 1/4 the size of a JPEG.

Enlarging the picture also shows something interesting.  When a picture
is larger than the original data, of course there are extraneous things
that appear.  When the original is enlarged to 1024x1024 in the conventional
way, the extraneous things are "jaggies" or "pixelization": the picture
consists of 4x4 solid-color blocks.  When the .trn file is decoded to size
1024x1024, there are extraneous details of another kind: They reminded me
a bit of what you see when you examine a painting very closely--little
swatches like brush-strokes.


-- 
  Gerald A. Edgar                Internet:  edgar@mps.ohio-state.edu
  Department of Mathematics      Bitnet:    EDGAR@OHSTPY
  The Ohio State University      telephone: 614-292-0395 (Office)
  Columbus, OH 43210             -292-4975 (Math. Dept.) -292-1479 (Dept. Fax)
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: fractal image compression, yet again - oy
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Fri, 28 Aug 92 19:32:31 GMT

In article <1992Aug28.134037.16291@crd.ge.com>
	davidsen@crd.ge.com (bill davidsen) writes:
>You
>are clearly granted the right to use patented ideas in the process of
>research. Since non-commercial code shared for the purpose of technology
>exchange is permitted, there is no problem with sharing of ideas.
>
>  Note: I'm not a lawyer, that's my paraphrase of what a lawyer told me.

Since the original poster is only making binaries, not sources,
available, I am under the impression that they are attempting to make
some sort of commercial venture from this.  Otherwise, why not
publish the source?  I can't exchange technology with an executable.
Anytime I see binaries-only distribution of programs on the network, I
immediately think of someone attempting to make a buck.  Usually this
is for programs that will eventually become shareware and/or
commercial products.

If you start marketing a commercially competing fractal compressor in
any visible sort of way, I would expect to get a response from ISI's
lawyers.  They are very serious about retaining their competitive edge
and are extremely aware of patent infringements.

I'm not saying I agree or disagree with this approach, but it surely
seems to be the one they are taking.

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
Newsgroups: alt.fractals
From: 10642749@eng2.eng.monash.edu.au (MARTIN OLBRICH)
Subject: Looking for Chaos
Organization: Faculty of Engineering, Monash University 
Date: Thu, 3 Sep 1992 08:40:37 GMT

Hi!  I have some turbulence data taken for the purpose of using it for 
statistical analysis. This data comprises 5 sets of 4096 data values, 
with each value being the velocity at a point, sampled at 6000 Hz. Each 
of the five sets is further downwind from the turbulence source. Having 
analysed this data using the guessian distribution and its associated 
mathematics, I am interested to see if I can find any chaotic behaviour, 
since turbulence is allegedly chaotic. 

To date I have tried to plot Velocity(n) vs V(n+1), and then a 3D 
progression ie. blah vs V(n+2). When this didn't work I plotted V(n) vs     
d/dtV(n) using central difference, and then into 3D with d^2/dt^2V(n). None 
of this worked. I then tried a bastardised Poincare section (a thicker 
slice in  order to retain a larger number of points) on each of the above 
data sets, still with nothing  more than a slightly correlated blob (ie, an 
elliptical blotch instead of a circular patch).

Am I doing something Wrong??? Am I barking up the wrong tree? I suppose I'm 
looking for an attractor of some sort..is there none to be found using these 
methods, or do I just have too many degrees of freedom? If anyone has any 
clues, please help.

I know that aliasing is present in the data (about 200 Hz worth at the 
top end of the spectrum).. would this be a significant problem?

Have a Nice Day
Marty.
Newsgroups: alt.fractals
From: Scott.Maxwell@bbs.oit.unc.edu (Scott Maxwell)
Subject: Re: fracting for amiga?
Organization: Extended Bulletin Board Service
Date: Tue, 1 Sep 1992 13:40:50 GMT

In article <17u30hINNaha@agate.berkeley.edu> shirriff@sprite.berkeley.edu (Ken Shirriff) writes:

>If anyone is serious about doing an Amiga port (or a Macintosh port for that
>matter), I'm happy to help them out and explain what needs to be done.
>(Summary: you need to rewrite unixscr.c to do pixel reads, pixel writes,
>handle mouse movement, set the colormap, draw lines, get input characters,
>and draw text.  I've done the nasty part of figuring out the Intel assembler.)

Which reminds me. Somewhere I have the Intel assembler code translated
into MC68000. (I didn't do it, and I can only distribute the code with the
proviso that it not be used on Macintoshes -- those are the terms under
which I got it.)

>Ken Shirriff				shirriff@sprite.Berkeley.EDU

--
Scott Maxwell (Scott.Maxwell@bbs.oit.unc.edu)
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80
From: bert.tyler@satalink.com (Bert Tyler)
Newsgroups: alt.fractals
Subject: Re: 227-byte Mandelbrot p
Date: 26 Aug 92 09:49:00 GMT
Reply-To: bert.tyler@satalink.com (Bert Tyler)
Organization: Datamax/Satalink Connection * Ivyland, PA (215) 443-9434

>I missed the first tiny Mandelbrot program (134 bytes I think?) But
>did get the second. The second one will not uudecode properly.
>UUDECODE 4.2 give me an illegal character on line 34 message.

SL>I now have the 134 byte (or whatever) version. Thanks to Sam Laur. I
SL>have two message confirming the fact that Bert's version is corrupted

Yet Another reason why I shouldn't have attempted to send that
UUencoded file to the Internet via this non-standard BBS connection.
Something in the food chain must have to decided to "help" and reformat
the message somehow.  (sigh).  Now I'm not entirely certain how
to send it (other than not publicly).

(Actually, that routine didn't really bring anything new to the ballpark
anyway.  I've been thinking that it would be more useful if it was
repackaged as a C-callable assembler routine that would calculate 
the bailout iteration of the Mandelbrot fractal at a single point
('iter = mandel32(xlong, ylong, maxit)') so that more folks could
actually get some use out of it.  Waddya think?)


                   Bert Tyler   (bert.tyler@satalink.com)
---
 . DeLuxe./386 1.25 #343sa . Did you expect mere proof to sway my opinion?
                                                                                                       
Xref: sparky alt.fractals:1378 comp.compression:3114
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: alt.fractals,comp.compression
Subject: Re: fractal image compression, yet again - oy
Date: 28 Aug 92 13:40:37 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Aug26.232029.7742@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
| In article <17gjevINN4rv@network.ucsd.edu>
| 	fisher@inls1.ucsd.edu (Yuval Fisher) writes:
| >Next update: new format with better compressed images and color. In about 2
| >weeks.
| 
| How do you know that your stuff doesn't violate the patents held by
| Iterated Systems, Inc.?  How does your method compare with their
| patented method?  

  The answer is "it doesn't matter." This was discussed some time ago
when the compact compressor came out, clearly using patented ideas. You
are clearly granted the right to use patented ideas in the process of
research. Since non-commercial code shared for the purpose of technology
exchange is permitted, there is no problem with sharing of ideas.

  Note: I'm not a lawyer, that's my paraphrase of what a lawyer told me.

-- 
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.
Newsgroups: alt.fractals
From: jhoracek@cwis.unomaha.edu (Jason Horacek)
Subject: Re: Latest Fractint
Organization: University of Nebraska at Omaha
Date: Fri, 4 Sep 1992 17:07:10 GMT

       You can indeed find the latest version of Fractint (17.2) on 
wuarchive.wustl.edu under mirrors/msdos/graphics frain172.zip.   It will
assuredly blow your version 12 right off the hard drive.  (insert
voluminous compliments to the many codifiers who have made fractint
into the obsession-inspiring beast that it is for many of us!)

       Jason Horacek

-- 
Jason Horacek
JHoracek@odin.unomaha.edu

Xref: sparky alt.fractals:1391 comp.compression:3144
From: pgr@pierrot.comlab (Partially Grown Rhododendron)
Newsgroups: alt.fractals,comp.compression
Subject: Re: fractal image compression, yet again - oy
Date: 31 Aug 92 21:14:02 GMT
Reply-To: pgr@prg.ox.ac.uk (Partially Grown Rhododendron)
Organization: Oxford University Computing Laboratory, UK
Originator: pgr@pierrot.comlab

In <17t5a0INNdb5@function.mps.ohio-state.edu>, Gerald Edgar
				<edgar@function.mps.ohio-state.edu> writes:
[about fractal-2.0 by Yuval Fisher]
> I did some experiments with this.  Since we are limited to the files
> provided, these comparisons are far from definitive.
[about tests on the lena image]

	original	65536
	lena.trn	3807

[...]
> I made JPEG compressions, at various quality levels.  In my judgment,
> the quality of lena.trn was equal to that of a JPEG of about 16K in
> size.
> Based on these very limited tests, for the same quality, the .trn file
> was 1/8 the size of a GIF and 1/4 the size of a JPEG.

Since it wasn't clear from this how the JPEG was created, I decided to
have a quick check myself -- here are the JFIF file sizes for a handful
of quality factors.

Note:  these were created with `cjpeg -o' (i.e., optimized Huffman
tables) and from a Portable Greymap version of the original raster
(to guarantee that cjpeg created a greyscale JPEG file).  These figures
favour JPEG a little more, I think, although byte-for-byte I think the
fractal compressor has it on quality...

	lena-q5.jpg	 1494		lena-q10.jpg	 2520
	lena-q15.jpg	 3360		lena-q20.jpg	 4064
	lena-q25.jpg	 4728		lena-q30.jpg	 5306
	lena-q35.jpg	 5890		lena-q40.jpg	 6390
	lena-q45.jpg	 6889		lena-q50.jpg	 7401
	lena-q55.jpg	 7886		lena-q60.jpg	 8471
	lena-q65.jpg	 9220		lena-q70.jpg	10217
	lena-q75.jpg	11309		lena-q80.jpg	13067
	lena-q85.jpg	15293		lena-q90.jpg	19525
	lena-q95.jpg	28349		lena-q100.jpg	44287

I'd say that quality 40 was appreciably better than the .trn file;
quality 35 is very close, and quality 30 shows rather more artifacts
than the .trn, *but* also shows detail which the .trn has blurred.
This would suggest the ratio is more like 1.5 to 1 for JPEG to .trn.
Certainly, the 16k JPEG (quality 85) is practically indistinguishable
from the original and considerably better than the .trn file...

(My guess is that the original test was (i) done without optimization
of the huffman tables (which makes about 10% difference to file size),
and (ii) done without forcing the JPEG file to be pure greyscale.)

Of course, without more samples these results are pretty meaningless :-}

phil
--
phil richards -- pgr@prg.ox.ac.uk -- programming research group -- oxford -- uk
Newsgroups: alt.fractals
From: Scott.Maxwell@bbs.oit.unc.edu (Scott Maxwell)
Subject: Re: fracting for amiga?
Organization: Extended Bulletin Board Service
Date: Mon, 31 Aug 1992 21:08:36 GMT

In article <1992Aug31.175212.7839@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes:
>In article <twegner.715272562@mwunix>
>	twegner@mwunix.mitre.org (Timothy Wegner) writes:
>>>		Is there a version of fractint for the Amiga?  :-)
>> [ Could be accomplished. ]

>As long as the 256 color assumption isn't too firmly imbedded in the
>code.  My understanding is that this is all over the place.  The amiga
>has a 6-bit plane mode, but not an 8-bit plane mode.  To get more than
>64 colors, you have to use HAM (hold and modify) mode, which is not
>easy to program.

Well, there are some ways to get around this. The Amiga port could use the
SAGE graphics system or some such thing, enabling those who have advanced
color boards (like me) to run the thing. Anyway, it can't be that hard to
get around the 8-bitplane assumption -- EGA and CGA cards can be used with
Fractint, after all. And if it really matters, the Amiga's operating
system can handle the 8 bitplanes, the hardware just can't display it all
at once (due to limited bandwidth, or so I understand).

In short: it can be done. I can't wait for someone else to do it ... :-)

>						-- Rich
>	Repeal the personal income tax; vote Libertarian in 1992.
                                        ^^^^^^^^^^^^^^^^^^^^^^^^ ditto.

--
Scott Maxwell (Scott.Maxwell@bbs.oit.unc.edu)
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80
Xref: sparky alt.fractals:1400 news.answers:2757
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: fracting for amiga?
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Mon, 31 Aug 92 17:52:12 GMT

In article <twegner.715272562@mwunix>
	twegner@mwunix.mitre.org (Timothy Wegner) writes:
>>		Is there a version of fractint for the Amiga?  :-)
>
>Ken Shirriff has done about 90% of the porting job by making a C only
>version for UNIX and Xwindows. Starting with the X version (available
>via FTP from sprite.berkeley.edu) an expert programmer could probably
>do the port for Amiga quickly.

As long as the 256 color assumption isn't too firmly imbedded in the
code.  My understanding is that this is all over the place.  The amiga
has a 6-bit plane mode, but not an 8-bit plane mode.  To get more than
64 colors, you have to use HAM (hold and modify) mode, which is not
easy to program.

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer