Interesting. I take back what I said, this isn't quite a closed case. I think "z" and "depth" are widely understood to be (B) (even if not always implemented as such by every last renderer), though this does not generalize to all possible transformations. For a spherical projection, say, it does seem better to store distance, but it would be very confusing to call it "Z". (One might argue that it should have been distance from the start, "d-buffer", not "z-buffer", so as to generalize, but that's water under the bridge at this point.)
The EXR spec is pretty clear that deep files need a "Z" channel. What happens for a different projection. Or, for example, is a "deep" latlong environment map allowed? To the extent that anyone cares, I would propose one of the following solutions: 1. Change the spec to allow "Z" -OR- "distance" (and "distanceBack?"), and nonstandard projections should have that channel rather than Z. 2. Keep the name "Z" always but dictate that for any projection that can be specified by a 4x4 matrix, "Z" means depth, but for non-matrix-based projections, it means distance. On Jun 3, 2014, at 12:32 PM, Jonathan Litt <jonathan.l...@yahoo.com> wrote: > For what it's worth, V-Ray also uses type A) for its standard z-depth buffer. > I inquired about this a long time ago and they had a reasonably logical > answer: B) only works for standard camera projections, but it doesn't work > for other projection types such as spherical and cylindrical. So they went > with A) for consistency. They could probably be convinced to add an option to > use B) for regular cameras, but it was easy enough to write a conversion > expression in Nuke and we didn't bother pursuing it further. It's also easy > to generate a "camera space P" AOV and get B) from that. Also, they do use B) > for the native depth channels in deep exr 2.0 files, which seems an admission > that the old way is just legacy at this point. > > My $.02: no harm in asking 3delight to add an option for this. > > > > On Friday, May 30, 2014 12:21 PM, Larry Gritz <l...@larrygritz.com> wrote: > > > "depth" (aka "Z") always means your choice B. That's true for every textbook, > file format, or renderer, from OpenGL z-buffers to RenderMan shadow map files. > > I can't speak for 3delight, but if your interpretation is correct, they are > just wrong (and incompatible with other renderers they try hard to be > compatible with), or have chosen a very strange naming convention that is > different than the rest of the computer graphics field. > > > > On May 29, 2014, at 6:34 PM, Daniel Dresser <dani...@image-engine.com> wrote: > >> I'm not exactly sure what the best way of wording this question is, which >> may be why I haven't turned up many answers in my searching. Hopefully >> someone here can suggest the best terminology and/or point me to an answer. >> >> Assuming that we want to store depth in an image using unnormalized world >> space distance units, there are two main ways we could do this: >> A) Distance from the point location of the camera (ie. if the camera is >> facing directly at a flat plane, the depth value is highest at the corners >> and lowest in the middle ) >> B) Distance from the image plane (ie. if the camera is facing directly at a >> flat plane, the depth value is constant ) >> >> The depth channel in an OpenEXR image is by convention named Z, which >> suggests interpretation B), where depth is orthogonal to the pixel X/Y >> location. >> >> I tried looking through the document "Interpreting OpenEXR Deep Pixels" for >> any sort of suggestion one way or another, but all I could find was: >> "Each of these samples is associated with a depth, or distance from the >> viewer". I'm not sure how to parse this - it's either defining depth as >> "distance from the viewer", which suggests A), or it is saying you could use >> either A) or B). >> >> Is there a convention for this in OpenEXR? The two renderers I currently >> have convenient access to are Mantra, which does B), and 3delight, which >> does A). I'm wondering whether I should try and pressure 3delight to switch >> to B), or whether our pipeline needs to support and convert between both. >> It shouldn't be hard to convert back and forth, but it's one more confusing >> thing that can go subtly wrong when moving data between renderers. >> >> -Daniel >> > > -- > Larry Gritz > l...@larrygritz.com > > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > -- Larry Gritz l...@larrygritz.com
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
