- remove some warnings
- fix typos
- cmake allow in-source build (when WITH_IN_SOURCE_BUILD is defined)
- cmake, use an explicit list of rna files (don't glob)
Compositing, lens distortion node: it delivered RGBA out with alpha zero,
making it not draw previews, violates both premul or straight alpha usage.
Now it just sets alpha to 1 for entire output.
Cleaned code readability a bit as well.
Clamped the maximum displacement distance to 4 x the input image dimensions - prevents hanging when vary large values are mistakenly plugged in, such as Z buffers,
- Colormanagement code was gamma correcting non-RGBA buffers in composite.
(Like vector buffers).
- Crash on using "use Color Management" button during composites, because
it was freeing all node images. Added code to stop first jobs before
freeing. It sends notifier for recomposites after free anyway.
Compositor/texture nodes: math node now allows to use pow() for
negative raising too, but only when that value is near-integer.
For other negative cases result is zero.
Patch provided by Aurel W
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
Compositor: Texture Node now behaves like an image.
- Image always in render output size
- Buffer outputs RGBA and Value both supported
- Works for filter and blur and scaling too.
- Mixing 2 textures works
Implementation note:
The texture node was meant to be 'procedural', not a buffer
but a color-sample method. Unfortunately the node editor
didn't support this well, blur/filter/scale ignored it too.
For now, its better to drop this procedural concept, then
things work at least as expected. :)
The texture node is procedural; like RGB node it has no real buffers,
but allows per-pixel reading. The compositor uses nodes that directly
access buffers too, which conflicts with it... needs more design here.
Restored old functionality that just passes on preview size buffers
for nodes to prevent crashes. Giving it a render-size buffer is not
nice; the resolution-independence of texture nodes is interesting to
keep.
Solution could be:
- visually tag input/output sockets for this case (sockets with buffers,
vs sockets with values), so users know what to expect.
Compositor: Texture node only allowed 1 user, with more nodes using it
there was a thread conflict, using same memory for writing values.
Also: brought back the original intention for texture nodes, which is to
be using a "procedural image", not allocating memory for a buffer, but
only allowing to read per pixel. Commit in 2007 (!) allocated full buffers
for texture nodes, without using them even.
The main reason to have this is so renders can be scripted to write to a specific file without having to do annoying tricks like set a dummy start/end frame range, render an animation and work out the current frame image will be written to, then rename after rendering.
Also made some 'char *' args into 'const char *'
ZCombine node in compositor ignored alpha values. Enabling it
would break compatibility though, so it's a tickbox option now.
Patch provided by reporter, Martin Lubich. Thanks!
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
this is because of fairly confusing logic, when an SRGB image has a float buffer added its always LINEAR, so we have to account for this elsewhere.
So the conversion from byte to float works like this:
* NONE -> NON-LINEAR
* SRGB/LINEAR -> LINEAR
...but none change the profile variable.
from Alexander Kuznetsov (alexk)
--- copied from the tracker
Every image inside Blender is in linear color space and gets converted to SRGB upon saving.
Level node analyzed the linear image, which was not the one user saw because other output nodes converted image to
sRGB.
This fix analyzes the image that user see (converting it to correct color space).
Here is difference:
http://www.pasteall.org/pic/show.php?id=5559
First histogram (before the fix) tells that image is underexposed, which is not the case.
