Compression of .igi

[OnoSendai]

Bear in mind that the compression ratio will probably depend heavily on the scene, and how converged the render is.

[Deus]

ofcourse. Still i'd rather have features that do something rather than save some diskspace. I rather have an easy to parse format than something that requires you to use ZLib to parse it.

[Kram1032]

Fourth: Du hast auch nicht die Weisheit mit Löffeln gefressen.

(I answer in german, as this is written in geman:))
Was hat das damit zu tun? Niemand hat Weisheit mit den Löffeln gegessen... (außer vielleicht in irgendeinem kranken Versuchslabor... o.O )

______
25% smalling the scene isn't that less at 50Mb...
every third scene, you save one scene
so you can have 4/3 the amount of scenes than if you'd use not compressed scenes... -> 133,333...%

Most of the ideas, that you claimed to be useless, wont give better renderresults, that's true, but they'd add comfort, speedity (optimisation) and user friendlyness... which is very important, especially for new users, too

[mrCarnivore]

Sorry Carnivore, but i am with deus.
First: maybe its your paper, but the content isnt really great at all (meaning the algorithm=useless, probably just a result of some publish or perish in action).

No, it's not my paper and I'm not specificly liking it. I found it after about 2 minutes searcihng the net with google.
Why do you think it's useless? I think the approach is not bad at all.

Second: Image compression algorithms are _margially_ better than general algorithms (look at maximumcompression, for example)

If you follow my argumentation in the above post, they should (in theory at least) be noticably better than non-image-specific compression algorithms.
If there's a flaw in my argumentation (don't just say "in theory" is the flaw) then slap it into my face.

Third: They will fail horribly at floating point images. Really horrible. And even more on Indio-style ones.

If they fail, they only do beacuse they were designed to handle other data. It's not a problem per se that happens in all image compression algorithms.

Fourth: Du hast auch nicht die Weisheit mit Löffeln gefressen.

No, I don't think specifically high about myself (in contrast to Deus). I like to give an argumentation when I want to prove a point and not just state that I know it is like this or that...

yeah. 25% reduction = pointless. Next useless feature please.

It might be pointless of Ono wasted his time trying to implement a compression algorithm to get 25% reduction instead of adding more useful features to indigo, I agree. But it is not useless if he got the working code from somebody else and ust had to integrate it into his code...

I think you are confusing not-worth-the-work with has-got-negative-effect-on-the-whole-software!

[mrCarnivore]

EDIT: I am gonna be real real nice right now. Carnivore you seem to be dying to co-develop indigo. I suggest you start with doing something you want yourself. Why dont you start by creating an API that can generate indigo xml... then you do two birds with one stone.

No I'm not "dying to co-develop indigo", I was just offering my help. If it's not needed, that's ok for me.

Last time I checked, offers for help and trying to get attention were different things, maybe not where you come from...

[Kram1032]

...but from where I come from, it is

[Deus]

So much attitude

Ill save my http-post quota for your next "idea"

You are a sweet guy Carnivore. Have a nice day.

[eman7613]

hmm ... with winrar i can pack them so that they are ~75% of the filesize of the original .igi file.

love winrar

[zsouthboy]

Wow, this thread took a turn for the worse quickly.

Here are my thoughts:

I don't care about the .igi filesizes on my disk - I've got probably 2 TB amongst all my crap here, 50 megs is a pittiance.

However, having less data go over my network makes it faster. Period.
That, to me, is useful. Trading some CPU time for network time almost always makes sense.