Rather than plugging a matrix into the video input node, the matrix is now
multiplied by the video input using a math node. This is probably more
sensible from a user perspective.
This also means the renderer is tolerant of texture sizes that are not equal
to the sequence size, however most nodes will downsample the texture to the
sequence size (and if not, it will be downsampled once it is cached). Textures
will still *always* be in reference space and the sequence's format. This seems
like the best compromise between backend and frontend congruity.
As opposed to simply leaving all values in the table, nodes can now "take"
values that they use to free up memory (e.g. "taking" input buffers if they're
used to produce an output buffer).
This is a fairly large change, expect regressions.
Due to an oversight, incoming footage frames were NOT converted to the
working pixel format (usually half or float). For most frames, this meant the
OCIO conversion would occur on frames while they were still in their source
format (usually either RGB8 or RGB16). This leads to rounding error
inaccuracies, but even worse GLSL will clamp integer textures to 1.0 potentially
losing a lot of data.
While later nodes would correctly convert to the appropriate format, by then it
would be too late. This commit corrects this issue, converting the frames to
float during the OCIO shader pass.
Several things are accomplished in this commit, including:
- Use OIIO instead of our own functions for pixel format conversions
(cleaner code/less for us to maintain)
- Fold all PixelService functions into the PixelFormat class
(cleaner code)
- Moved OpenGL pixel definitions to OpenGL classes and out of the
global classes.
- Add support for RGB buffers as well as RGBA (optimization)
itsmattkc