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
|