Fix inexplicable compiler error on mips platform by changing variable name
oiiotool --siappend appends subimages of top two images on the stack
DPX - add full support of subimages.

DPXInput was mostly right but there were some minor bugs to fix, we
weren't calling the right version of dpx::Reader::ReadBlock to properly
index the right subimage.

DPXOutput needed a pretty extensive overhaul for submages -- it had been
written without subimage support at all.  So needed to tease apart the
header writing stuff that applied to the whole file versus each
individual subimage.  In the end, it was mostly code movement, not a ton
of changes, other than to the high-level logic of dealing with mutiple
subimages in the file.  DPX is one of those formats where you need to
know the information about all subimages when you first open the file
for output.
Bug fixes in libDPX input of multi-image files.

The old code had two entry points for ReadBlock and ReadImage: one that
took the element number, and the other that took a descriptor (that's
DPX spec speak for things like R, G, RGBA, Luma, etc.) and read from the
first, presumably unique, element with that descriptor.  This seems to
made the assumption that if there were multiple subimages in the file,
they would each have unique descriptors. This is obviously not the case,
for example a DPX file may contain subimages for left and right stereo
views, but both may have the same kRGBA descriptor.

Anyway, the "read element" version was implemented by looking up that
element's descriptor, then calling the "read the element with this
descriptor" function. So of course it was wrong.  Thus, any code using
libDPX to read both views of a stereo DPX file would end up reading the
first image twice.

This patch fixes the "read element" to really and truly read the element
(specified by index). And the "read by descriptor", in addition to being
somewhat non-sensical, wasn't needed anywhere, so I just removed it.
iconvert - get 'open' error from the right place
DPX output: fix setting of description, offset, originalsize, orientation.
DPX tests for stereo/multi-image
Merge pull request #658 from lgritz/lg-dpx

DPX multi-image support and other improvements
DPX: Subimages now correctly set their description from their respective ImageSpec
Add FIELD3D_HOME description.
CREDITS
GCC 4.8 warning fix.
Add GIF input support.
Use the HDF5 release libs always, even when building debug OIIO.
Patch proposed by Richard Shaw.
Make build more robust to missing GIF library
Python improvements: TypeDesc
* Make a more thorough unit test
* As a result, fix tons of little problems
* More complete Python support for TypeDesc features
* Some minor (back compatible) changes to C++ TypeDesc to make it easier.
Python improvements: ImageSpec overhaul, tests, fixes
Update PDF docs
Merge pull request #663 from lgritz/lg-python

Python improvements: TypeDesc & ImageSpec
More careful with texture de-duplication.

The hash only compares input pixel values. We check a few other items in
the metadata (such as default wrap mode), but had neglected to consider
the role of the projection matrices in the metadata.  And in fact, we
had a site that routinely used EXR files for the sole purpose of having
a queryable transformation matrix (the rationale for this is more sound
than you might guess), and the deduplication was kicking in and "losing"
the different matrices because the pixels happened to be identical (all
black). And in general, we now realize that it's a little funny for the
deduplication to give us the "wrong" metadata for get_texture_info
queries. All sorts of metadata may be different despite the pixels of
the two images being identical and therefore wanting to avoid redundant
loading of tiles.

This patch does some refactoring, wherein find_tile takes a new
parameter that allows explicit "do not redirect duplicates" control,
which is used by get_imagespec and get_image_info/get_texture_info, so
that metadata queries will always return the correct results for the
named file, rather than any earlier-loaded duplicate (of pixel values).
The functions that access pixels rather than metadata (get_pixels,
texture lookups, etc.)  continue to do duplication redirects, so it
should be as efficient with duplicates as before.

Along the way, I also noticed that the per-thread "microcache" of
name-vs-texture lookups was only used when accessing via the
TextureSystem, and bypassed for apps calling ImageCache directly, nor
was it used for get_texture_info calls.  I rectified that by moving the
micro-cache check into ImageCache::find_file itself, and then making
TextureSystem::find_file (where the check previously resided) a more
simple and direct mapping of IC::find_file.  This might yield a slight
speedup for certain apps that directly use the ImageCache APIs, or
that tend to make lots of get_texture_info/get_image_info calls.