forked from AcademySoftwareFoundation/OpenImageIO
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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.
- Loading branch information
Showing
9 changed files
with
180 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters