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 <l...@larrygritz.com
<mailto:l...@larrygritz.com>> 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 <jiver...@d2.com
<mailto:jiver...@d2.com>> 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 <l...@larrygritz.com
<mailto:l...@larrygritz.com>> 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
<jiver...@d2.com <mailto:jiver...@d2.com>> 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
l...@larrygritz.com <mailto:l...@larrygritz.com>
--
Jason Iversen
Production Technology Supervisor
Digital Domain
--
Larry Gritz
l...@larrygritz.com <mailto:l...@larrygritz.com>
--
Jason Iversen
Production Technology Supervisor
Digital Domain
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
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
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
