And now for something... completely pointless.

Take a look at the attachment. The trace marked "original" is just some 
random data I made up. [It's the output of a random number generator fed 
through a band-pass FIR filter with a wide pass-band.] This trace 
basically consists of 256 double-precision numbers.

I then took this data, compressed it using the Fractal Transform 
(yielding 32 positive integers and 64 double-precision floats), and then 
decompressed it again.

As you can see, the two signals correlate reasonably closely. As you can 
*also* see, they're not exactly identical by any stretch. Hmm... I think 
my program is buggy. :-S

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Attachments:
Download 'compress1.png' (22 KB)

Preview of image 'compress1.png'

Invisible wrote:
> And now for something... completely pointless.
> 
> Take a look at the attachment. The trace marked "original" is just some 
> random data I made up. [It's the output of a random number generator fed 
> through a band-pass FIR filter with a wide pass-band.] This trace 
> basically consists of 256 double-precision numbers.
> 
> I then took this data, compressed it using the Fractal Transform 
> (yielding 32 positive integers and 64 double-precision floats), and then 
> decompressed it again.
> 
> As you can see, the two signals correlate reasonably closely. As you can 
> *also* see, they're not exactly identical by any stretch. Hmm... I think 
> my program is buggy. :-S
> 
> 
> ------------------------------------------------------------------------
> 
it looks to me as if the volume got turned down slightly.


Tom

Post a reply to this message

Invisible wrote:
> And now for something... completely pointless.
> 
> Take a look at the attachment. The trace marked "original" is just some 
> random data I made up. [It's the output of a random number generator fed 
> through a band-pass FIR filter with a wide pass-band.] This trace 
> basically consists of 256 double-precision numbers.
> 
> I then took this data, compressed it using the Fractal Transform 
> (yielding 32 positive integers and 64 double-precision floats), and then 
> decompressed it again.
> 
> As you can see, the two signals correlate reasonably closely. As you can 
> *also* see, they're not exactly identical by any stretch. Hmm... I think 
> my program is buggy. :-S
> 
As this Fractal Transform is not lossless, what exactly is your problem?
Other than that it is apparently the wrong compression technique for 
this kind of signal of course.

Post a reply to this message

>> As you can see, the two signals correlate reasonably closely. As you 
>> can *also* see, they're not exactly identical by any stretch. Hmm... I 
>> think my program is buggy. :-S
>>
> As this Fractal Transform is not lossless, what exactly is your problem?

I was hoping for a closer fit than that.

Mind you, I started out applying this to image data. Only problem is 
that the decompressed image bears *no resemblance* to the original. I 
don't know what I've done wrong, but it's clearly horrifically broken. 
So I thought I'd try the simpler 1-dimenional 1-channel case. And as you 
can see, it more or less works...

> Other than that it is apparently the wrong compression technique for 
> this kind of signal of course.

Or rather, I couldn't find a good signal to test it with. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Tom Austin wrote:

> it looks to me as if the volume got turned down slightly.

Yes - I couldn't help noticing that one...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

I tried changing the block size from 8 samples to 4 samples. The fit is 
now closer, yet the overshoots and undershoots are more extreme.

I also tried changing it to 2 samples, but then the whole thing just 
malfunctions horribly.

Just for fun, I also tried 16 samples per block. This also produces a 
"reasonable" fit, though not as good as 8 or 4.

So it seems that smaller block sizes produce a better fit [yet with less 
compression]. No real surprises there then.

I'm now going to experiment with different similarity metrics, to see 
what difference that makes...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> I'm now going to experiment with different similarity metrics, to see 
> what difference that makes...

Well, actually it turns out that which metric you use makes a pretty 
small difference to the result - and overall, simple signal correlation 
seems to work just about as well as any elaborate system I can come up with.

(Total deviation squared comes out identical to signal correlation. 
Total absolute deviation is slightly different, with more overshoot. And 
signal derivative correlation comes out more "noisy".)

Oh well - I guess this is the closest fit I'm going to get...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

andrel wrote:

> As this Fractal Transform is not lossless, what exactly is your problem?
> Other than that it is apparently the wrong compression technique for 
> this kind of signal of course.

Well, I've run a few signals through my program, and they all seemed to 
work kinda OK. But just now I threw together a simple fractal noise 
generator. (Midpoint displacement method.) And then I ran that through 
the program, and WOAH! Something has gone terribly wrong here...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Attachments:
Download 'compress2.png' (56 KB)

Preview of image 'compress2.png'

It reminds me of when I first heard of the Mandelbrot set in the late 80's.
My first try on my 48k ZX spectrum resulted in a rather skew Mandelbrot set.
Then I realised I had been adding a -1 in the recursion, that shouldn't be
there... :-P


--
- Nekar X -

Post a reply to this message

Nekar wrote:
> It reminds me of when I first heard of the Mandelbrot set in the late 80's.
> My first try on my 48k ZX spectrum resulted in a rather skew Mandelbrot set.
> Then I realised I had been adding a -1 in the recursion, that shouldn't be
> there... :-P

Yeah, implementing an algorithm for the very first time is always way 
hard. Especially if you don't have a working reference implementation to 
go from! :-S [And let's face it, those are usually in C.]

Spare a thought for me when I wrote my first ray tracer! All I had was 
the POV-Ray user manual. From that, I eventually figured out that you 
can find the intersections between a ray and a sphere by solving a set 
of simultaneous equations. And then, I managed to work out that since 
the ray equation is parametric, if you *substitute* it into the sphere 
equation, you get an equation in only 1 unknown. And then I had to shift 
algebra around to discover the final form of this equation. And then I 
spent 4 BONEHEAD hours trying to work out how to solve this equation. 
(After which, obviously, I remembered that "oh yeah, there's a formula 
for that". DUH!)

And then I went upstairs and implemented it in Borland TurboPascal 5.5 
for DOS, in 16-colour VGA glory. And it freakin' worked! First damn 
time. I was amazed...

Yeah, it's much better if you have a reference implementation!

[Of course, today you do. Warp has kindly added one to the POV-Ray 
manual. But I should emphasise that wasn't there back when I worked all 
this out the hard way. Damn, if only you could get meddles or something...]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message