Software developer hat on.
The issue with everybody choosing a different extension, or of having
a plethora of extensions for different types of data that can be
stored in compliant OpenEXR, is that it's a pain in the behind for
apps that want to use the file extension as a clue for what format it is.
For example, consider an application that has a "file open" dialog
that when choosing a texture file will highlight image files, and it
knows about ".tif", ".exr", ".jpg", and so on. If somebody decides
that in their studio they want deep exr files to have the extension
".dxr", and exr files that have some some deep parts and some non-deep
parts to be ".cxr" (complex), and stereo frames to be ".sxr", and
MIPmapped exr's to have ".mxr" to distinguish them from flat exr's --
this could go on forever -- well, that file dialog is going to annoy
the crap out of people.
So I give +1 for having standardized file extensions correspond
one-to-one with file formats, NOT multiple extensions for different
corner cases of the same format.
-- lg
On Jul 19, 2012, at 10:45 AM, Jeff Clifford wrote:
Hi,
Yep - I'd echo what Peter says below.
The idea of the extension for us is purely to allow people working to
see if there is deep data or not i.e. .dxr/.zxr would indicate that
there is some deep data in the image. However any extension should
indeed be an /optional/ alternative for those who don't have the same
pipeline requirements (as it is with .sxr/.mxr).
One of our concerns for us is that by just using .exr for all types
is that people can't quickly see if a particular shot is using our
deep pipeline or not. We're also not keen on the overhead of opening
and header checking to decide whether deep data is within or not when
there are a huge number of files. However, I understand people's
argument how in principle just .exr should be used as it supports all
the different types of data within.
Bizarrely, this reminds me of the first meeting about OpenEXR at
Siggraph (2002/3? - Apologies Florian I can't remember exactly) where
one of the issues debated was the fact that .tif could be used to
store such HDR data instead of a new file format/extension. One of
the key arguments against that was that the problem with .tif files
is that you don't know what type of image data they actually contain
- and now it looks we may be coming full circle!?
For us here we do want to use a different file extension to
distinguish OpenEXR files that contain deep data for pipeline reasons
and like Blochi said in his post this is the opportunity to do it -
it will be harder to do it at a later date. Maybe the Open Source
VFX BoF meeting at Siggraph can be used to come to some consensus! -
not sure if the beer will help or not ;-)
Thanks,
Jeff.
On 19/07/12 07:51, Peter Hillman wrote:
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
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
address@hidden <mailto:address@hidden>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
address@hidden <mailto:address@hidden>
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel