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

[Peter Hillman]

Not surprisingly, I agree with Richard!

Some users will want to use a different extension to indicate the file 
should be treated as deep.
For example, regular images called .exrs load into photoshop when 
clicked and deep images load into exrdisplay when clicked. Or, more 
pertinently for us, Nuke creates DeepRead nodes or Read nodes as 
appropriate from a single picker.

If there's no recommended extension, or a recommendation saying "you 
must call all your files .exrs", those folks will invent their own 
regardless, and vendors will be asked to implement a whole slew of 
extensions for different clients.

There's little need to have different extensions for mono and stereo, 
since code that can handle deep should be stereo aware from the 
beginning, and users would use the same tool for both mono and stereo. 
Information about mono or stereo should be in the filename as an 
indication to the user as to what to do (e.g. prefix the name with L, R 
or S); the extension should be used as an indication to the software as 
to what to do.

That said, it might still be worth having an agreed standard for 
extensions which distinguish stereo from mono, for people who really 
need it, so we limit the number of extensions there too.

I'm not suggesting we should specify that all deep exrs should always 
have some other extension, just that we specify a single one as an 
optional alternative, and suggest vendors support reading and writing 
deep exrs which have either .exr or the agreed other extension.

Personally, I'm not too fond of the idea of "dxr" or "dexr" because it 
isn't distinctive enough from "exr" in verbal communication.
Try saying this quickly  (ideally in a dark and crowded meeting room 
with important clients present for true authenticity):
"Have you rendered the dxr or the exr?"
Now try this:
"Have you rendered the odz or the exr?"





On 19/07/12 10:39, Richard Addison-Wood wrote:
> As I understand the impetus for having recommendations for the file 
> name extensions, I am thinking that it might make sense to make the 
> following suggestions:
>
> If, within your pipeline, you wish to use the file name extension of 
> an OpenEXR image file to indicate that it has deep data, you may wish 
> to consider using .dexr (for mono with deep data), .dsxr (for stereo 
> with deep data), or .dmxr (for other multi-channel with deep data).
>
> Alternatively, if you only want to distinguish between deep and 
> non-deep, consider using .dexr when there is any deep data.
>
> If, within your pipeline, you wish to use other means for 
> distinguishing the form of the data in an OpenEXR image file, consider 
> using .exr across the board.
>
> On 07/19/12 07:35, Jonathan Litt wrote:
> > If an extension were going to be recommended along the lines of 
> > "sxr", there would also need to be some guidance as to when to use 
> > the extension at all. Given the alembic-like nature of 2.0 format 
> > files, does a deep extension mean there is exactly one deep image, or 
> > no non-deep images, or that the data is "primarily" deep data? Should 
> > stereo deep images be .dsxr? What should an application reading a 2.0 
> > file expect differently if the file has a deep extension? So now 
> > there will be three extensions for the same file format that all just 
> > serve as hints, but that make no difference to reader programs? Of 
> > course not all readers will be able to process deep data, but they 
> > still need to be able to handle the fact that they could get a .exr 
> > file containing deep images that they need to ignore. I like .sxr, 
> > but it works because it has a much more narrow definition of what is 
> > contained in the file.
> >
> > I say welcome to the new world of 2.0 where .exr might mean anything, 
> > and put whatever info you want about the contents into the file name 
> > or directory name. :) Soon enough (if not already at some places) 
> > most data except at the very end of the pipe is going to be deep 
> > anyway, so if a new extension is used then practically nothing will 
> > be called .exr, which seems like it kind of defeats the purpose.
> >
> > -Jonathan
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel