Re: [Openexr-devel] Established deep data file extension?

[Larry Gritz]

That's an interesting example.  I'm not sure the situation is analogous -- zip 
is an extremely generic container format, and so there are a couple cases where 
apps use a different extension when the container's contents adhere to data and 
layout conventions specific to those apps.

But fair enough, I'll roll with it for now.  A plausible argument could be made 
that deep files are a completely different beast than regular images, despite 
using OpenEXR as a common container.  I can understand wanting a different 
extension for that (though I would recommend dictating the extension rules in 
the OpenEXR spec itself).

The part that throws me, though, is what to do about multi-part OpenEXR files 
that combine deep and non-deep parts.  Or should that be disallowed?



On Jul 19, 2012, at 10:07 PM, Peter Hillman wrote:

> Hmm. Open Document Format and Apple Keynote files are actually zip archives, 
> but I'm quite grateful they aren't just called ".zip" files. Even though Open 
> Office's file dialog annoys the crap out of me, at least I'm looking at 
> OpenOffice's dialog, not some archiver tool's dialog. Maybe having .odt .ods 
> and .odp for different flavours of ODF is too much, but better than them all 
> being .zip.
> 
> With *my* software developer hat on, I know there'll have to be code that 
> does different things for deep and non-deep files. I'd rather not have to 
> write something that second guesses some unenforced naming convention or path 
> location. I certainly don't want to spend my life emailing users telling them 
> they're doing it wrong. I'd prefer to write something automatic based on the 
> file extension. Best of all, I'd like tools to work properly out of the box, 
> so I don't need to write anything.
> 
> In any case, it seems weta and dneg are going down the route of using some 
> extension other than ".exr" for "files which are meant to be opened as deep 
> images". Now's the chance to define what that is, so we only end with one 
> alternate extension. The argument about if and where that alternative should 
> be used is a different discussion, isn't it?
> 
> Peter

--
Larry Gritz
address@hidden