On Mon, Oct 17, 2011 at 8:48 PM, Larry Gritz <[email protected]> wrote: > The higher-level tools (iconvert, oiiotool) are another story entirely, and > I'm willing to bow to common sense, consensus, or precedent of other apps. > The two cases we care about are when the input image (a) has a data window > smaller than the display window (a crop window) or (b) has a data window > larger than the display window (overscan regions), but the output image > format does not support these notions at all (e.g. JPEG). What should > happen? What do other programs do? > Hugh implies that Shake would pad with some black (or some kind of settable > background color?), or crop to the display window. Do you agree? > Anybody familiar enough with Nuke to know what it does in these > circumstances? > Jeremy, do you have an opinion on any of this? > -- lg >
If rendering something in nuke where the internal "data window" is smaller than the "display window" to a format the doesn't have such concepts, it will render a result that is the size of the "display window." which is basically the data surrounded by black. It's actually a bit more complicated than that because nuke wants to repeat edge pixels, but a crop node defaults to adding a one pixel black border around the cropped area (just outside the display window, so the resulting so that you edge-repeat the black border in the undefined space.) If rendering to EXR, nuke will correctly preserve the windows. I don't think nuke has a ngcolor in the sense that Shake did. In nuke-speak, you use a crop node to set the data window, and a reformat node to set the display window. You can also reformat in a crop node to do both at once. But, if you have the black border enabled when you reformat while you crop, the resulting data and display windows are not identical. The data window extends one pixel past the display window in each direction for the invisible black border. (This works fairly well in practice, despite being oddly complicated to explain nuke's behavior, you seldom have to think about it very explicitly.) In Shakespeak, the Crop node set the display window, and a setDOD node set the data window, basically. It was simpler in Shake. When rendering an EXR out of nuke where the display window is smaller than the data window, Compressor on Mac OS X will try to interpret the EXR in terms of the data window. The rule seems to be based on 'whichever is bigger.' The result is a QuickTime movie made from an EXR sequence that is physically larger than expected, and has unexpected stuff visible in it, and a very confused and angry editor. I consider the Compressor behavior to be incorrect, and I have never desired it. Basically, if I am making images where the data window matters, I'll keep strictly within the realm of tools and formats that maintain the distinction. If I need to use a tool that doesn't understand the data window, then I'll change my settings in the originating tool to make my images unambiguous. Efforts by intermediate tools to care about the data window in formats that don't understand it have never turned out useful to me. They should just use the display window, IMHO. _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
