JPEG support for reporting and controlling chroma-subsampling value
Minor docs fixes
Turn off ffmpeg by default.
This is because it's opening other files! Ick. Need to make it exclude
non-movie files.
OpenEXR fix writing of subimage name.
(Got attribute name translation backwards.)
Fix typo in float4::iota
ImageCache: Zero out the SIMD padding in tile allocations!!!

The texture system tries to use SIMD (SSE) ops. It wants work on four
floats at a time. If there aren't four channels, that's ok, because
we'll zero out "past the end" channels by multiplying with a float mask
that will be 0.  We also pad the end of the allocation for a tile, so if
we retrieve four values (for a texture with < 4 channels) from the last
pixel in the tile, we don't want to run off the end of the allocation
and segfault.

OK, but if it turns out that this padded but uninitialized memory past
the last pixel of the tile happens to have the bit pattern that
corresponds to NaN, then even though it will get multiplied by a mask
such as (1.0, 1.0, 1.0, 0.0), 0*NaN = NaN, *not* 0! (For any non-NaN
value, the float multiply mask trick would work fine.) So this was
allowing NaNs to creap into the texture results. Oops.

The solution is really simple, which is just to use memset to make sure
the padding at the end of the tile allocation is filled with zero
values.
oiiotool -help should say if there is no OCIO support.
Python read_scanlines did not honor channel subset, leading to chaos.
Python - make all IBA functions release the GIL for their expensive part.

The notorious GIL (global interpreter lock) prevents other Python threads
from executing while our functions are holding the lock.

We use a ScopedGilRelease found in many places on the web. Its purpose is
to release the GIL before expensive work, then properly re-acquire it again
when it exists scope. This allows other Python threads to advance while we
are doing the meat of our work.

In many case, this meant writing a wrapper (to scope the GIL business)
where before we did not need a wrapper.
simd: add some helpful swizzle operators
CHANGES update
minor docs fixes
rebuild PDF docs
c++11 fixes on gcc-491, glibc-2.12-1.132.el6
Change default TIFF output compression to "zip", it is better than lzw.
Make testtex able to force interp and mip modes.
Add testsuite tests to test each one individually (other than the defaults,
which are covered by existing tests).

This makes it easier to debug the texture system after changes -- if just
one of these tests breaks, it's easy to know we've introduced a bug in a
specific part of the code that deals with that case.
oiiotool --dumpdata of deep files: correctly print values of uint32 channels
Make testtex output all non-error messages to stdout, not stderr
Another texture simd overhaul

Continuation of the SIMD texture rewrite from a few weeks back, now that I
know even more about SIMD-ifying code with SSE.  Highlights:

* Replace the old "accum_sample_*" methods with "sample_*" which differ
primarily by moving the loop over anisotropic samples into the function,
which allows (a) some shared computation for all the samples along the
aniso region to be shared, and (b) certain computations to be done on
groups of 4 aniso samples at once (especially the "st_to_texel"
computation).

* Pre-normalize the aniso weights, this leads to far fewer divide ops,
and none for the common cases of only 1 or 2 aniso samples.

* Simplify, simd-ify, and mostly hoist out of loops a lot of the logic
related to "fill" values (for channels requested but not present in the
texture).

* For bicubic interpolation, SIMD-ify the computation of the four
bicubic coefficients (4-wide, get it?). Also have functions that compute
coefficients for both the bicubic value and the coefficients for the
derivatives together instead of in separate functions -- this lets them
share some intermediate values, cutting down on the math somewhat.

* A bunch of other miscellaneous ways in which slight rewriting of the
SSE math I use leads to faster evaluation, especially in the successive
lerping to do the bicubic math. Just as an example, if you have a sequence
like this (capitalized variables are SIMD registers, lower case are floats):
A = ...computation...; b = A[1]; C *= b;
The extraction of one value (A[1]) into a float b, then re-SIMDizing it
(by multiplying another float4 by b) is wasteful. It's better to do it
like this: float4 B = simd::shuffle<1>(A); C *= B;
Bottom line: Avoid mixing float registers with float4 registers if you can.

So where does this all get us? I have benchmarks like this:

    channels   baseline      after
    4-chan      15.4         13.4 (-13%)
    3-chan      18.0         13.5 (-25%)
    1-chan      17.9         13.4 (-25%)

These are all 4 channel lookups, and the "chans" is the number of
channels in the map itself (with missing channels supplied by the "fill"
logic).  So I'm getting 13% speed gain when retrieving the right number
of channels from the file, and 25% (!) gain when retrieving more
channels than the file supplies (a common case of asking for RGBA from
an RGB file, with "fill" supplying the missing 1.0 value).
Plugins for Nuke (Foundry product) for reading/writing OIIO textures.

* txReader will read OIIO texture files (TIFF and OpenEXR, tiled, mipmapped)
  as Nuke input images.

* txWriter will write image files from Nuke as proper OIIO texture files
  (tiled, mip-mapped, all metadata set correctly).