Re: Unit scale for Z values
Thorsten Kaufmann <[email protected]> Fri, 15 Jan 2016 08:28:24 +0000
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
I think this would be a very good thing to do! --- Thorsten Kaufmann Production Pipeline Architect Mackevision Medien Design GmbH Forststra?e 7 70174 Stuttgart T +49 711 93 30 48 661 F +49 711 93 30 48 90 M +49 151 19 55 55 02 [email protected] www.mackevision.com Gesch?ftsf?hrer: Armin Pohl, Joachim Lincke, Jens Pohl HRB 243735 Amtsgericht Stuttgart --- VFX: Game of Thrones, Season 5 - VFX making of reel<https://vimeo.com/133433110>. TWITTER | ADOBE BEHANCE: Follow us on Twitter<https://twitter.com/Mackevision> and Adobe Behance<https://www.behance.net/mackevision>. From: openexr-devel-bounces+thorsten.kaufmann=mackevision.de@nongnu.org [mailto:openexr-devel-bounces+thorsten.kaufmann=mackevision.de@nongnu.org] On Behalf Of Nicholas Yue Sent: Freitag, 15. Januar 2016 07:06 To: Jason Iversen <[email protected]>; Larry Gritz <[email protected]> Cc: [email protected] Subject: Re: [Openexr-devel] Unit scale for Z values Just thinking out loud... Does it make sense to have something akin to RFC for such things as part of the VFX Platform (i.e. VFX RFC) as a way to get everyone on the same page so that even if it is a multi-year process, things don't get lost along the way as people change projects, companies etc. Cheers On 2016-01-15 1:56 PM, Jason Iversen wrote: Yeah, I do realise that asking the library itself to do this is a rather big responsibility and it might pose more questions than it answers. What I was hoping to avoid is the giant process of recommending a standard metadata key, and then requesting 3rd party vendors to respect this key upon write and do the thing upon read - which you may appreciate could be a multi-year process with spotty coverage all the way. I was hoping to get the issue addressed at the source. Thanks, Jason On Thu, Jan 14, 2016 at 4:19 PM, Larry Gritz <[email protected]<mailto:[email protected]>> wrote: OIIO 1.6.9 has the -mulc command, but it doesn't work properly with deep images -- that was fixed/added (um, now that you mention it, likely at your request) to the master at the time when I was trying to freeze 1.6 for a release. It seems to be working and safe, so I'll backport it to 1.6, in case it's helpful. Seems to me that making the IlmImf library itself try to be too smart about unit conversion and scale things under the covers might create as many problems as it solves, but I think it's a really good suggestion for apps (like Houdini or Maya) to apply a scale when writing depth channels -- after all, they know what units they are computing in. Another thing that may be good practice is to recommend a particular metadata name that reveals what units the depths are in ("DepthUnit" -> "meter" or whatever) and then presumably a really smart Nuke deep merge node might apply appropriate scales to make sure the operand images are in the same space, if they both have documented units but don't match. -- lg On Jan 14, 2016, at 4:02 PM, Jason Iversen <[email protected]<mailto:[email protected]>> wrote: Hi Larry, Thanks, and yes - I was one of the people who at least chorused with the request to be able to apply a z-scale within oiiotool. We just installed 1.6.9 here; does that have the -mulc feature? My question is definitely aimed at the idea of support for automatic conformance to try to aid interchange without incurring pipelining - ie, tracking of originating scale and destination scale, and generating intermediates. Thanks, Jason PS. I have the same question poised for Alembic :) On Thu, Jan 14, 2016 at 11:13 AM, Larry Gritz <[email protected]<mailto:[email protected]>> wrote: I'm not sure if this addresses your question directly (which seemed to be more about automatic conformance to a unit scale upon read/write?), but as far as converting the values of a deep file that already exists: If you know that the z's are in decimeters and you want to convert to meters, and you know the channels of the file (let's say that you know that there are two channels, "A" and "Z"), you can do oiiotool decimeters.exr -mulc 1.0,10.0 -o meters.exr Basically just multiplying every alpha value by 1.0 (keeping it the same) and multiplying every Z value by 10.0 (converting decimeters to meters). Sorry, I just checked and the deep support for "-mulc" is a recent addition, at this moment is in the "master" branch only. But I can backport it to a stable release branch if people need it. > On Jan 13, 2016, at 12:27 PM, Jason Iversen <[email protected]<mailto:[email protected]>> wrote: > > Hi all, > > Is there any mechanism in place, or planned, or rejected(!), for adjusting (deep) Z values to match a unit scale? In environments where you interchange deep EXR2's between packages which are working in different unit scales (eg. Maya in decimeters and Houdini in meters) you would want to convert to the unit scale to the hosted application upon read. I'd imagine you'd do this be comparing it to a unit-scale stored in metadata. > > Regards, > Jason > > > -- > Jason Iversen > Production Technology Supervisor > Digital Domain > -- Larry Gritz [email protected]<mailto:[email protected]> -- Jason Iversen Production Technology Supervisor Digital Domain -- Larry Gritz [email protected]<mailto:[email protected]> -- Jason Iversen Production Technology Supervisor Digital Domain _______________________________________________ Openexr-devel mailing list [email protected]<mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/openexr-devel -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows https://ca.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel