On Sun, 31 Oct 2004 16:27:45 +0000, Andrew the Orchid <voi### [at] devnull>
wrote:

>> From looking at the code, I'll guess it reads the strings
>> with a hex-coded file (sort of like uuencode, binhex, or
>> mime) in them.  This is output as a "pseudo binary" file,
>> with each one or zero being written as asn ascii zero or
>> ascii one, separated by commas.  This is turn is read
>> back in and read through what looks like a fixed huffman
>> tree decompressor[1] which yeilds a file containing the
>> actual povray scene file.
>
>Yups, that is indeed *exactly* what it does.
>

cool!  :D

>(Would have used canonical Huffman rather than explicitly storing the 
>codebook - but the code to recompute the codebook is larger than the 
>codebook itself, so...)
>
>It's not uuencode or BASE-64 or anything... just plain vanila hexdecimal 
>8-D Would probably take up less space if I changed it to BASE-64... (Uh, 
>I mean, it would *definitely* take up less space... but not sure about 
>the decode part!)
>
>> Now I'm going to render it and see.  :)
>
>Heh. Hope you have a fast PC...
>

I yi yi!  I had to give it up.  I'm guessing the
media is what slows it down.

>Seriously... the hex -> binary decode is almost instant. The Huffman 
>decompression takes ~30 seconds or so. And the image itself takes 
>*forever*...
>

I used had to abort the render after an hour.  Wayyyy
to slow.

<snippage>

>I actually tried to write a version that uses arithmatic coding. In 
>fact, it works. Expect... Sometimes - just sometimes - the decoder 
>utterly looses synchronisation with the encoder, and I can't figure out 
>why. :'(
>

you wrote an arithmetic coder as a pov-ray script?
Ow.  That musta hurt.  I have one in c and that was
a PITA to get working.



-- 
to all the companies who wait until a large user base becomes
dependant on their freeware, then shafting said happy campers with
mandatory payment for continued usage. I spit on your grave.

Post a reply to this message