Re: [Openexr-devel] congratulations and thanks, but...

[Drew Hess]

Hi Dana,

All 3 of your observations are correct.

It's true, OpenEXR does not support tiling.  It's scanline-oriented only.  
We don't do file-based tiling here at ILM, we do it at the application 
level (if at all), so it's never been an issue for us.

It doesn't don't do different compressors per channel, either.  Again, 
we've just never had the need.

I'll see about scheduling some time to add these features, since others
have requested them, too.  They're not trivial changes, so it may take
awhile.  Of course, part of the point of open sourcing the format is to
get more developers, so if anyone out there wants to give either one of
these a shot, feel free :)

Regarding multiple images per file, what's the advantage of that versus 
something simple like putting multiple images in a tar file?


On a related note, since you're considering adding OpenEXR support to 
Renderman, we already have an OpenEXR display driver for Renderman, as you 
can imagine, and we're working to make it available with the rest of our 
OpenEXR software distribution.  Bill Anderson is copied on this email; 
he's the guy looking into it from our side.  Hopefully you can leverage 
off the work we've already done if you decide to incorporate OpenEXR into 
official Pixar releases of Renderman (and we hope you do!).

Talk to Bill if you're interested in pursuing that.

thanks for the comments

-dwh-



On Thu, 23 Jan 2003, Dana Batali wrote:

> Congratulations and thanks to ILM and NVidia for the promotion of HDR 
> images and the contribution of OpenEXR!  We're considering adding 
> support for it to Pixar's RenderMan but, in a brief scan through the 
> description on the web site, I've identified a few important 
> (critical?) limitations:
> 
> 1. the format doesn't appear to support image tiles.
> Can this be true?  If so, I suggest that this is an important flaw that 
> should be corrected at the earliest possible moment.  Specifically, the 
> format appears to be exclusively scan line oriented.  For many 
> applications it is more convenient and efficient to store data in 
> regular rectangular "tiles".  For example, both TIFF and Maya's IFF 
> formats support tiles.
> 
> 2. the format doesn't appear to support multiple images.
> The idea here it may be useful to store a related collection of images 
> within a single file. Each image has it's own resolution and 
> independent channel specs. We need to store image pyramids in a single 
> file.  There are numerous other situations where this feature is 
> required.
> 
> 3. the format doesn't appear to support different compressors for 
> different channels.
> Kudos for allowing arbitrary numbers and combination of channels per 
> image! Given this potential mix of data types (and even image contents 
> (imagery versus alpha, for example)) you'll be able to get smaller 
> files by supporting per-channel compression types.
> 
> These are the off-the-top-of-my-head reservations about this new file 
> format. The new 16bit floats and the associated compression 
> methodologies are superior to anything publicly available that I'm 
> aware of.  The arbitrary channel count is also very desirable.   But 
> the limitations outlined above aren't present in TIFF and Maya's IFF 
> and might impede the widespread adoption of this format.
> 
> I hope someone can tell me I'm missing something?
> 
> Thanks,
> Dana Batali
> RenderMan Products
> Pixar Animation Studios
> 
> 
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
>