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