I meant
maketx --envlatl --prman input.exr --format tiff -o output.tex
The resulting TIFF file should work with both PRMan and OIIO. If you leave out
the --prman, it will pick tiling and other parameters that are better for OIIO
performance, but unfortunately PRMan will no longer read it properly (it's very
picky and will crash without the exact tile sizes and data layout it expects).
If you write an exr file, I'm somewhat less confident about what PRMan will do
to it. In particular, I don't know if they do the right thing with EXR's
peculiarity, which is that the spatial layout is different! OpenEXR says that
the leftmost and rightmost columns are exactly on the international date line,
and that the top and bottommost rows are exactly at the pole.
In other words, the TIFF convention is
s = lerp (-pi, pi, (x+0.5)/width)
whereas the OpenEXR convention is
s = lerp (-pi, pi, float(x)/(width-1))
When you use 'maketx' and output to an exr file, it automatically resizes in
just the right way to make the texture turn out right. I have no idea if
PRMan's txmake does the same, nor do I know if PRMan itself will use the right
formula in the shader.
Also, regardless of the texture construction itself, I can't guarantee that
math for how the inerpolation is performed for the width=0 case is exactly the
same in the two renderers. I would expect small differences.
On Nov 14, 2013, at 5:39 PM, ryan heniser <[email protected]> wrote:
> 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]
>
>
>
>
>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
