Maya IFF - depth info/map extraction ?

[nyue]

I have some IFF generated from Maya that has depth information which I can see using fcheck.

Is oiiotool able to convert such IFF files to e.g. OpenEXR, while retaining the depth channel ?

What would the command line options be like ?

Thank you in advanced.

[lgritz]

I would try

oiiotool in.iff -o out.exr

and see how well it does?

OIIO supports iff, but it's so infrequently encountered that I don't want to speculate too confidently about whether absolutely everything iff can do is handled correctly.

[lgritz]

The depth channel part is where I'm most uncertain about how well it's been tested.

[nyue]

Thank you @lgritz

oiiotool in.iff -o out.exr

was my first port of call but didn't get any depth/z channel. I was hoping that there was some special option I can specify to oiiotool to coax it into extracting them.

We will revisit our IFF writing/export, maybe there are some option [in Maya] to write out the z/depth into IFF so that oiiotool can pick it up.

[lgritz]

I can easily believe it just doesn't have support for depth channels because it never came up.
But if you want to send me a sample file (privately is ok, it will be confidential), I can take a look and see if it's an easy fix.

[nyue]

@lgritz sent.

Thank you in advanced.

[lgritz]

I took a look at this, and it looks like our IFF reader ignores the Z channel of an RGBAZ image, once it sees RGBA it doesn't consider z. Thus, the sample file you sent me identifies as just RGBA, despite having the bit set in the header that indicates that it has a Z channel, too. It looks like our reader will recognize an IFF file that was Z only... but I'm not confident that it would decode the pixels correctly, and I don't have a Z-only iff file to test that hypothesis.

I had hoped that maybe it would be a quick fix to get RGBAZ working, but now I'm convinced that it would actually be a substantial amount of work. While I'd happily accept a PR if somebody wanted to take this responsibility on, I can't justify doing it myself or officially putting it on the roadmap, for a format that is so rarely used. (As a data point: we've had the IFF reader for 14 years, and I think this is the first time anybody has noticed that it doesn't read depth channels. So the need must be fairly rare.) Sorry about that.

[lgritz]

@mikaelsundell was the original author of the IFF file support, tagging him in case he has any comments. There is truly no pressure to fix this, Mikael, but I wouldn't want to deny you the chance if this omission has been causing you to lose sleep for the last 14 years and the only reason you haven't picked it up again is because you thought nobody would use or appreciate it. :-)

[mikaelsundell]

😄 spot on! let me check it out tomorrow, will post an update shortly.

[lgritz]

Something to beware of if you're messing around with the iff reader code:

I think the only substantial modification made to this code since you wrote it 14 years ago is that I did a pass at one point to make it use IOProxy. Then I ran into some problems with that at work -- proof that this is still used! -- and restored the non-proxy version (there is both an iffinput.cpp and an iffinput-noproxy.cpp) to get me out of that jam until I could return to figure out what was up with the edge case where the proxy was failing tests. But I guess I never returned to it.

By default, we build the proxy one, though I think that at work, I use the non-proxy version. This must mean that either (a) the case that doesn't work with the proxy is quite rare, because I don't recall anybody else complaining about it or needing me to explain how to switch to the non-proxy version; or (b) the proxy one is very broken, but SPI is the only place relying on the iff reader. I honestly have no idea which one is more true.

IFF is a really odd legacy format. I don't think anything outputs it anymore except for Maya playblasts, and I'm not sure why it's still favored for that versus literally anything else.

[mikaelsundell]

Can you send me that IFF test file with the Z channel? It's been years, and I no longer know where my original test bench is or if I even had files with Z channels. My mistake - I see it's in the header.

[mikaelsundell]

Thanks for sharing the info about the IOProxy code. I'll see what happens when I start building/testing it.

[mikaelsundell]

@nyue @lgritz I have the test file now and will start work on this tomorrow.

[mikaelsundell]

Quick update, I've made some changes:

/Volumes/Build/pr/ms-IFF-250303/oiio/build/bin/Debug > ./oiiotool -v --info /Volumes/Build/pr/ms-IFF-250303/data/playblast.1001.iff 
Reading /Volumes/Build/pr/ms-IFF-250303/data/playblast.1001.iff
/Volumes/Build/pr/ms-IFF-250303/data/playblast.1001.iff : 1920 x 1080, 5 channel, uint8/uint8/uint8/uint8/float iff
    channel list: R (uint8), G (uint8), B (uint8), A (uint8), Z (float)
    tile size: 64 x 64
    Artist: "<artist>"
    compression: "rle"
    DateTime: "Wed Feb 26 13:32:50 2025"

The image specification is now up to date. I still need to do some additional work on the ZBUF channel. I'll start a PR once I have a basic version up and running.

main...mikaelsundell:oiio:ms-IFF-250303

It's a bit of reverse engineering with this format, but I’m hoping for the best and will provide an update shortly.

[lgritz]

Good news? I found two .iff files in my directory that have timestamps 3 days before I committed the change that partially reverted the iff handling to its pre-proxy version. I'll try to get a chance later today to give those a try with and without the ENABLE_IFF_IOPROXY build flag (I need to do some custom builds) and see if I can characterize for you what/where is failing.

[lgritz]

Oh dear, it also seems that in src/iff.imageio/CMakeList.txt, I also named the option "ENABLE_RLA_IOPROXY" instead of "ENABLE_IFF_IOPROXY". I blame lack of coffee on that day.

(When I build OIIO at SPI, I disable both of these. Apparently I discovered the name problem after the PR was merged, and never fixed it because I really did believe I would have the whole thing fixed right away and the option would go away.)

[mikaelsundell]

Great!
The ENABLE_IFF_IOPROXY flag will be a part of my PR. No problem.
So far so good, I'm now doing tests with RLE+FLOAT for ZBUF.

[mikaelsundell]

I now have most of what I need in place, will optimize the existing code and run some more tests, also found out how interpret the ZBUF float data/ -1/ z/ eye space to replicate what we typically see in fcheck in OpenImageIO. Need a few more days before PR.

[nyue]

@mikaelsundell Fantastic news. Thank you :-)

[mikaelsundell]

@nyue @lgritz Ok, here we go:
https://github.com/mikaelsundell/oiio/tree/ms-IFF-250303

I've now added a more solid implementation of z-buffers in IFF, we can now both input and output such files with RLE/ per channel encoding in native float. Validated a set of output files - both 8/16-bit and Z-buffer in FCheck, looks correct. Over the next couple of days I will ask some friends to do some additional tests. The new updated IFF format works in Nuke and FCheck. At least FCheck uses the standard Maya libraries so it should be a good benchmark.

All values are preserved in the depth map as discussed with Larry, to visualise such values you could do something like, (-1/z)/max in an Expression node in Nuke. The FCheck viewer uses something similar + compression of values to preset a nice visualisation in 0-1 range, so don't be surprised when testing IFF files outside FCheck.

I will add some more documentation and probably run into some CI issues I will fix, once complete it's ready for a PR!

[lgritz]

I'm marking this as closed, since the fix has been implemented and merged.