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 l...@larrygritz.com _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
