I added in the exchange ( in Compositing ) a useless DSO that allows Houdini to read Schmaya IFF format ops: Too fresh to go to the beach. It is only available for Linux, but as said if someone wants the code to compile it for Windows, I will give it away. Also I can add routines to write IFF.. but we dont want that, do we?
Take the DSO and put it in the DSO/fb directory and you will need to edit and the following lines to

FBfiles:

#__IFF Alias Maya
iff

and

FBformats

// Alias IFF Maya images
fb/IMG_iff.so

Great, thanks monkey-butt.

(Now that's fun to say)

Thanks monkey_butt.
And it isn't useless, is very useful for all of us that have to share work with theMaya guys.

Indeed, nice to see some have the time to do things like this… useless at the first sight but usefull at the end.

Its very useful! Thanks! Writer is also expected since quite often you have to render for Shake. Iffs are best choice for it. No reason to rise war against Apple/Alias on that field. It's worse for H. then for them.

windows version… why not, so please add these few lines to your code

cheers,
SYmek

I hear tiff files work fine with Shake.

it's a matter of speed of disk operations, Shake is soooo fast with its internal iff format… quite important for compositors. If you work on shake, work on iffs. 30%faster reading a file (then tiff with lzw) x 20 layers in 2K… this makes different.


cheers,
symek

I'll admit I haven't used iff's for many, many years(loved that alpha channel being only supported in a separate file from rgb! ), but one huge advantage with tif and some other formats is that it can be tiled - only loading portions of the image when doing > vid res. I'm unsure if iff is capable of that, but what a huge difference that makes! The only reason iff is faster is because it's RLE(run length encoded), meaning the compression is brain-dead simple and virtually has no hit on cpu. It *has* no other option AFAIK. You can easily mimic that in tif by using no compression, and combined with the tiling, it outperforms many other formats.

3DEqualizer has, IMHO, the best damned mem management on Linux that I've seen in an app, and how it manages long film res sequences is a dream when working with tif. It just *deals* with it. Everyone could stand to set that as their high bar.

Sorry for fragmenting the thread…

Cheers,

J.C.

Well I will post this week the new version containing the “write” routine, need some testing. Also I will try to get the Windows version compiled or someone may have to do it for me. And yes, the compression of IFF is dead simple.

SYmek, have you ever tried what JC suggested? Using non-compressed .tiff's.

I see some misunderstanding here: Shake Iff's format - freely licenced for Alias Maya (Shake developer wrote Maya's flipbook) - has nothing to do with old fashon amiga iffs… it's different file format. It supports arbitrary number of channels, 8,16,32bits per channels, it can be compressed (by adding gz extension after *.iff ) it starts form lower left corner (important issue) and finaly… yes, it fully supports TILING. Shake can also save in it aditional information like its own DOD paramiters.

But of course tiff rulez! This is my choice also, whenever going out of Shake.


cheers,
SYmek


PS Edward, I almost never use lzw,rle etc. , I know that compression will slow down reading a file. But even without it, filein routine can be good or bad coded. Have you ever tried Silicon Grail RAYZ? The fastest viewer ever seen! As you know everything starts from simple C headers and librares…

I've found that the fastest file formats are the ones that balance disk bandwidth and CPU utilization (for decompressing). Large files are limited by your drive burst bandwidth (for RAIDs, not as much of a problem) and network bandwidth (if remotely stored). On the other hand, heavily compressed files are bottlenecked by the CPU. That's why RLE works well for mattes & cutouts, and LZW'ed TIFF's are sometimes bogged down by the CPU. It can be tricky to find the right balance for any given machine, though.

truth, truth…