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]> 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]> 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]> 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]> 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] >> >> >> > > > -- > Jason Iversen > Production Technology Supervisor > Digital Domain > > > -- > Larry Gritz > [email protected] > > > -- Jason Iversen Production Technology Supervisor Digital Domain
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
