Yes, they should be at the center of the pixel and the lat/long should not
wrap, thanks! The error is at most 0.003. That might be good enough for my
cases. When I do
maketx --envlatl --prman ...
Will PRman recognize it as an OpenExr env map? So, I can just do a RSL
environment and compare that with what I am get from the OIIO environment in my
RSL Plugin?
color result = environment("latlongenv.exr", D, D, D, D, "blur", 0.0, "filter",
"box", "lerp", 0.0, "sample", 1.0);
Ryan
On Friday, November 15, 2013 12:38 PM, Larry Gritz <[email protected]> wrote:
I believe you are encoding the values incorrectly, by not taking into account
that the samples should be at pixel centers. Also, you are repeatedly adding
to the longitude and latitude rather than properly lerping, and depending on
the resolution, I can imagine that creating a bit of roundoff error. Ooh, and
after each row, you are just letting the longitude "wrap" instead of starting
at zero. That can't be good (roundoff).
If your longitude ranges from -pi to pi, and latitude from -pi/2 to pi/2, what
you actually want is this:
for h in range(height):
v = (h+0.5) / height
lat = (-pi/2) * (1-v) + (pi/2) * v
cos_lat = math.cos(lat)
sin_lat = math.sin(lat)
for w in range(width):
u = (w+0.5) / width
lon = -pi * (1-u) + pi * u
cos_lon = math.cos(lon)
sin_lon = math.sin(lon)
...
So everything is 1/2 pixel off (and a differently-oriented 1/2 pixel off from
the other image orientation!), plus multiple sources of roundoff errors.
See how much that fixes things.
If still not enough, then as a next step I would explore what differences, if
any, there are between your txmake call, versus
maketx --envlatl --prman ...
(maketx can be coaxed into creating maps that can be read by PRMan. This way,
at least we are comparing the two modes of maketx, independently of whether
txmake is doing anything weird.)
On Nov 14, 2013, at 2:53 PM, ryan heniser <[email protected]> wrote:
We are going from exr files to lat-long env tex files (via txmake) and exr to
lat-long env exr files (via maketx) respectively. The only difference being in
the way we encode the data in the original exr files. I am attaching the python
script as an example.
>
>
>
>Ryan
>
>
>
>
>On Thursday, November 14, 2013 9:13 PM, Larry Gritz <[email protected]>
>wrote:
>
>Are you aware of the differences in the spatial representation of OpenEXR
>versus the usual convention that PRMan and OIIO use with TIFF textures?
>
>
>In other words, are you quite sure that this is a OIIO vs PRMan difference
>rather than a TIFF versus OpenEXR difference in the layout of the data?
>
>
>
>
>
>On Nov 13, 2013, at 11:00 PM, ryan heniser <[email protected]> wrote:
>
>Hi Larry,
>>
>>Thanks for the quick response. We have spherical harmonic coefficients stored
>>in Pixar's env maps. I am trying to swap us to use OpenExr's env maps (via
>>OpenImageIO in a RSL Plugin ). This will allow us to control the caching of
>>this LUT separate from PRMan's texture cache. When I read in the two maps,
>>the values differ by as much as 0.1. I am pretty sure I have accounted for
>>the difference in env map encoding between the two. I wrote a little python
>>script to create the unit sphere for the two encodings. Rendering with the
>>two unit sphere maps also gives me at least 0.03 in error. Increasing the
>>resolution decreases it to some extent. I am pretty sure I am point sampling
>>the tex file too. But, I am checking with the PRMan folks to make sure.
>>
>>Would you expect so much
error between the two? Any ideas on where I may be going wrong?
>>
>>Thanks,
>>Ryan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On Thursday, November 14, 2013 6:58 PM, Larry Gritz <[email protected]>
>>wrote:
>>
>>Yeah, that looks like it should do it. Between the zero derivatives and the
>>width==0, and the InterpClosest (to prevent true interpolation), you ought to
>>be point sampling.
>>
>>
>>Is this not working as expected? What happens?
>>
>>
>>
>>
>>On Nov 13, 2013, at 9:53 PM, ryan heniser <[email protected]> wrote:
>>
>>How do I point sample a env map with an environment call? I thought it would
>>be something like
>>>
>>>// Initialize texture options for point sampling
>>>gTexOpts.nchannels = 3;
>>>gTexOpts.firstchannel = 0;
>>>gTexOpts.swrap = TextureOpt::WrapPeriodic;
>>>gTexOpts.twrap = TextureOpt::WrapClamp;
>>>gTexOpts.samples = 1;
>>>gTexOpts.mipmode = TextureOpt::MipModeNoMIP;
>>>gTexOpts.interpmode = TextureOpt::InterpClosest; // Force closest texel
>>>gTexOpts.conservative_filter = false;
>>>gTexOpts.sblur = 0;
>>>gTexOpts.tblur = 0;
>>>gTexOpts.swidth = 0;
>>>gTexOpts.twidth =
0;
>>>
>>>
>>>const Imath::V3f zero(0,0,0);
>>>
>>>bool ok = gTexSys->environment(filename, gTexOpts, r, zero, zero, test);
>>>
>>>
>>>Ryan
>>>_______________________________________________
>>>
>>>
>>
>>--
>>Larry Gritz
>>[email protected]
>>
>>
>>
>>
>>
>>
>
>--
>Larry Gritz
>[email protected]
>
>
>
>
>
><makeUnitSphereLatLongEnvExrAndPixar.py>
--
Larry Gritz
[email protected]_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
