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

[Jonathan Litt]

On Jul 19, 2012, at 10:38 PM, Larry Gritz wrote:
> The part that throws me, though, is what to do about multi-part OpenEXR files 
> that combine deep and non-deep parts.

Exactly, and I don't think that's going to be a corner case. I think mixed 
files will start showing up with increasing frequency, not to mention 
multi-part exr files in general. The 2.0 format opens up a world of 
possibilities both with and without deep data: hi-res and proxy res images in 
the same file, 3D renders with a stash of their source HDR image, RAW (if 
Openexr RAW ever finds footing) and debayered images in the same file, etc.. 
Custom extensions risk giving a false sense of security and could possibly end 
up being even more confusing. File extension != asset management.

On Jul 21, 2012, at 2:22 AM, Jon Wadelton wrote:
> That being said the file chooser can't currently work out whether to create a 
> DeepRead or regular Read if the filename just has an .exr extension.  A 
> different file extension would help us here to create the correct read 
> without having to open up the file and peek at the headers.

Given the nature of 2.0 a user might want to read 2D data from a seemingly deep 
exr file or deep data from a .exr file, so the extension still doesn't ensure 
full correctness in this case.

This leads me to think that if a deep extension does end up being recommended 
it should be for files that contain nothing but deep images. That would at 
least narrow the usage and allow certain assumptions to be a little bit safe. 
(Although there still might be stereo, multiple deep images, etc., so not that 
safe.) My vote would be for ".dexr", given the ".dxr" clash. Nuke already uses 
".dtex" for prman deep files anyway, and that's four characters. I don't think 
auditory confusion is going to be a concern in practice, especially if it's 
"dee-exr". At DD people usually just say "is this using deep?", with apologies 
to the grammarians in the crowd. :)

I still stand in the no-recommended-extension column but if it's gonna happen 
anyway that's my vote.

> Longer term Nuke may want to do something cleverer when opening exr files in 
> general.  It could for instance loop through all the parts within the file 
> and produce different DeepReads or Reads per part instead of just assuming 
> there is one type of data per file.

Yes! This is the exact kind of thing I'm referring to. Hopefully more shorter 
term than longer term. :)

-Jonathan