IBA::checker() didn't work right with offsets
Make IBA::checker() offset parameters default to 0
oiiotool --runstats should print time/mem total every wildcard iteration
ImageBuf change -- read() no longer required, and other minor API changes.

It always bugged me that an ImageBuf needed an explicit read() (or, if
you only needed spec information, init_spec()).  The constructor didn't
do it because we wanted explicit control of some things.

This change makes the init_spec() and read() entirely optional, as long
as you are ok with an "ImageCache-backed" buffer.

Basically, it keeps track of whether the spec and pixels are valid, and
any API calls that require the spec automatically do an init_spec() if
not already done, and any API calls that require the image to have been
read will call read() internally if not already done.  In theory, there
is a very tiny performance hit for constantly checking the bool that
indicates whether these have been done, but compared to most things you
do with images, that's pretty minor.  And is significantly simplifies
code that uses ImageBuf in straightforward ways. For example, a "poor
man's iconvert" just looks like this:

    ImageBuf in ("in.tif"); // doesn't read yet...
    in.save ("out.exr");   // Auto-read here implied by needing pixel vals!

Of course, you are welcome to use read() explicitly, as you did before,
and that's what you need to do if you want to force a fully local read
rather than using the ImageCache, or if you want to force translation to
a specific data format that's not what's in the file or part of the
ImageCache default behavior (e.g., force conversion to UINT16, no matter
what the file's pixel data type is).

Mostly this is nice because the kind of simple examples that we put in
the docs are a lot nicer to read without all those extraneous read() calls
being required everywhere.

Also changed 'save' to 'write' for consistency (for now, there's still
a save() function that's a symonym for write()), and added some constructor
variants that make it optional to supply a name at construction time
for wrapped and writeable ImageBufs.
Bug fix in ImageBuf::write when dealing with subtleties of untiled images
read into ImageBuf's, but which look like tiled images because of the
ImageCache.

Also a couple minor adjustments to ImageBuf::copy to use the new
notation, and make sure pixels are valid of the source before copying.
Simplify ImageBuf::copy
Fully initialize ROI with default constructor
Python ROI
Python touchups
Fix broken ImageBuf::file_format_name()
Python bindings -- ImageBuf (including unit tests and docs)
Rebuild PDF docs
Merge pull request #674 from lgritz/lg-python

Python overhaul pt 3: ImageBuf
CHANGES
Beef up oiiotool testsuite
Fix ImageBuf spec vs nativespec confusion over the data format.

Recall: ImageBuf.spec() is supposed to describe the data in the buffer
(or held by the ImageCache, if it's a cache-backed IB), whereas
ImageBuf.nativespec() is supposed to describe the data in the file
itself.

It turns out this was subtly broken all along -- in cases where you
called init_spec(), spec().format held the data type of the file
after that call, but after a full call to read(), it would be changed
to reflect the data type of the buffer.

This did not match the documentation or intended design of spec vs
nativespec, but we never noticed, and in fact there were places in the
code that (unknowingly) took advantage of this chain of events.

When, earlier this week, I committed changes that remove the need to
ever call init_spec() and read(), instead doing these actions
automatically and lazily when other API calls first need the data in
question, a bunch of icky bugs popped up, revealing this confusion.

This patch mostly fixes the situation.  It is VERY important for apps to
keep straight whether it's spec() [the buffer] or nativespec() [the
file] that they want to be calling for any particular purpose.

There is still one way things can be confusing: If you create the IB,
then reference spec() -- which will reflect how it will look in the
ImageCache, then force a call to read() to force a fully local read
rather than use the cache... at that point, spec().format will change to
reflect the buffer that you read.  I don't see how to avoid that, unless
we switch to a model where the IB constructor fully specifies at that
time whether the IC will be used or whether the file will be fully read
locally.  I'll mull that over for possible later revision.
Fix IBA::unsharp_mask bug when src and dst are different data formats.
Fix minor IBA bugs with sizing outputs based on inputs.
Additional sanity checks in ImageBufAlgo functions that operate in-place
and require initialized buffers.
fix for associate/unassociate (and background) alpha issues for Photoshop PSD

Photoshop not only wasn't being converted to associated alpha, but also
it had the color mixed with a background.

Photoshop File Format: (you can find background at 0x1010)
http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/#50577411_31265

Alpha Test Grid we made and used to calculate PS background/alpha formula from:
http://wiki.blender.org/index.php/File:Dev-PhotoshopAlphaGrid.png

In my own files (and oiio test suite) the background was either white or
unexistent. It doesn't hurt to read it from the file when available, though.

Patch done in collaboration and reviewed by Brecht van Lommel. A lot of the credit
goes to him.
Add a variety of ImageBufAlgo::resize() that specifies the filter by name.