CHANGES

Fix not allocating enough scratch space for cmyk tiff reads

Related to the fixes I did a couple commits ago. There was one use of
a temp buffer that was allocating based on the 3-channel size for
translation to RGB, but it was being used to read the raw 4 channnel
data into it, overrunning the bounds and screwing up the heap.

TIFF: subtle bug -- re-opening forgot about rawcolor hint. (AcademySo…

…ftwareFoundation#2285)

When scanlines are accessed out of order, to emulate true random access,
sometimes we close the file and re-open. But in this one spot, instead
of calling close_tif() we called close(), and the difference is that close()
also calls init() which resets the options that might have been set by
configuration hints -- such as "oiio:RawColor" and "oiio:UnassociatedAlpha".
In this case, we may want to close/open the TIFF file itself, but we don't
want to "forget" about any configuration hints from the original open call.

The circumstances that led to this being symptomatic are obscure and amusing:

- Scanline TIFF file with CMYK color space, and opened with a
  configuration hint "oiio:RawColor" which causes the CMYK values (4
  chans) to be preserved rather than it all get auto-converted to RGB
  and appear to the app as if it were a 3 channel file.

- The image was held in an ImageCache-backed ImageBuf. And the IC has
  the "autotile" feature turned on (so it will try to break it up into
  tiles in the cache, instead of storing the whole scanline image as a
  single tile).

- An IBA function was running parallelized over multiple threads, and
  it happened that a thread needing a lower part of the image (high
  scanline number) made the request for its tile before another thread
  that needed a tile with lower scanline numbers. This caused the actual
  reads of the scanlines to not be in proper order, therefore necessitating
  a close and re-open of the file.

- Upon the re-open, it had forgotten that "oiio:RawColor" was set, so
  even though the app had asked for the pixels to be written into a 2k
  x 4 chan CMYK buffer, the confused TIFF reader thought it was in the
  mode where it was emulating a 3 channel RGB file. So it would not
  only convert to RGB when it should have left it as cmyk, but since the
  RGB is only 3 channels, the 2048 pixels only filled in the left-most
  1536 (that is, 3/4!) of the value slots in each scanline of the app's
  buffer.

- When running valgrind on the app that was reading the image (for
  unrelated reasons), it was complaining about reading uninitialized
  memory when it would get to pixel 1536, mystifying everybody.

... And I'm so glad today I work on monster movies and cartoons, and not
nuclear power plant control software or life support systems.

Additional fixes included:

* And add a test case

* Python ImageBuf: add constructor that takes a configuration hint spec

* ImageBuf: when adding file to cache, careful with configuration.
If you open an ImageCache-backed ImageBuf, close, then have another
ImageBuf opened later with a different set of "config" hints... you
may not get expected behaviors. Instead, be sure to invalidate it and
add it to the cache in "replace" mode.

CHANGES

vdb reader build pulled in the tbb libraries using wrong CMake variab…

…le. (AcademySoftwareFoundation#2274)

Also some adjustments for SPI only for where to find it properly, we
have weird paths.

CHANGES

CHANGES

CHANGES

Fix IOProxy::pread on Windows that botched PNG & JPEG read (AcademySo…

…ftwareFoundation#2231)

We've been plagued by recently-introduced bugs with PNG and JPEG
reading that stemmed from the first IOProxy-related patch.  The
problem was our use of the Windows ReadFile call, which seems to not
preserve the file pointer as we'd assumed (the MSDN docs are ambiguous
about this). I also began to doubt its thread safety, so in the end I
just replace the code with a simpler approach with a mutex and calls
to tell/seek/read.

Same changes to pwrite implementation.

Fix IOProxy::pread on Windows that botched PNG & JPEG read (AcademySo…

…ftwareFoundation#2231)

We've been plagued by recently-introduced bugs with PNG and JPEG
reading that stemmed from the first IOProxy-related patch.  The
problem was our use of the Windows ReadFile call, which seems to not
preserve the file pointer as we'd assumed (the MSDN docs are ambiguous
about this). I also began to doubt its thread safety, so in the end I
just replace the code with a simpler approach with a mutex and calls
to tell/seek/read.

Same changes to pwrite implementation.