To throw in another data point; I tried to repro the tiff/exr discrepancy
using the recipe that Larry posted earlier.
Using local files, 1 thread, gcc 4.8.1, oiio master, and the
system-provided libtiff (3.9.4), I'm *not* able to trip the problem
(provided I'm looking at the right numbers in the t
I'm assuming you reverted IlmBase back to 1.x as well (not sure if this
> matters, but...)?
>
Yeah, I was using IlmBase 2.2.0 and 1.0.3 with OpenEXR 2.2.0 and 1.7.1
respectively.
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openi
> I found out that I was getting vastly different speeds even on the same
> exr version depending on whether I built libIlmImf myself or used the
> system libraries. It seems to have boiled down to compiler releases (gcc
> 4.4 vs gcc 4.8 vs clang -- the latter two make much faster code for some
>
> > Also, reading and writing of values in OpenEXR goes through ImfXdr.h's
> conversion routines doing bitshifting for I assume endianness conversion? -
> I guess the x86 port for OpenEXR had to convert this, whereas the SGI
> versions didn't, and we're stuck with it now?
>
> There are certainly so
At one time there was a requirement that only the display windows were the
> same, not necessarily the resolution of the data. So prior to calling the
> 'exrmultipart' command, we used 'oiiotool --fullsize' to set all display
> windows to that of the highest resolution in the file set.
>
The down
For DWAA/B compressed openexrs, .R and .Y would be lossy compressed,
whereas .I would not. So from that perspective either would suffice.
On Wednesday, June 15, 2016, Larry Gritz wrote:
> OK, preliminary proposed fix here:
> https://github.com/OpenImageIO/oiio/pull/1434
>
> I'll let it sit for a
> But you MUST run that version of TextureSystem only on machines that
> support those hardware instructions!
>
How feasible is it to do a runtime cpuid check and only take the f16c paths
on supported cpus? Then you can have one binary to rule them all.
Thats how we handle f16c (and avx) in open
Depends on the overall organization of the logic, I guess.
>
Yeah, that and how much gain you get from it. If it's just a tiny perf
bump, it's not likely to be worth the hassle of the messy logic.
Do you have any rough feel of the improvement that it gives for sampling
half textures?
OpenEXR is
Yeah, I was going to say make it contextual -- so its basically an alias
for dwaCompressionLevel for the DWAA/B case.
On Wednesday, September 21, 2016, Deke Kincaid > wrote:
> If the constraint of —quality is that it is always 0-100, then that is
> going to be hard to map and would lead to con
I think I pulled that out of my rear end one day, so don't out too much
stock in that mapping if it sounds sketchy.
On Wednesday, September 21, 2016, Kevin Wheatley
wrote:
> Closest I've seen to a quality scale was this email from Karl
>
> https://lists.nongnu.org/archive/html/openexr-devel/2014
If its not explictly set, 45 will be used in IImImf.
But Id have to check the code to see if dwaCompressionLevel gets explictly
added if its omitted. My guess is that it isnt added automagically.
On Thursday, September 22, 2016, Deke Kincaid wrote:
> One more. When you don't set the compressio
The decision of how to compress each channel is an implicit thing internal
to the openexr lib currently.
There isn't a method to test how a channel will be handled, but the logic
is basically:
If the channel name (not the layer name) is R, G, B, Y, YR, or YB, it will
be lossy compressed.
If the
12 matches
Mail list logo
