Three code fixes for 1 report. User experienced crashes while
painting on float buffer + having preview renders on.
- Texture Nodes: Image was re-allocated without using
proper thread lock
- Paint code: old convention to free the byte rect from
a float image as signal to re-create now is a proper
flag. This keeps image memory unchanged. Nice for render.
- Imbuf: call to make a byte rect from float was freeing
mipmaps unnecessary.
Texture nodes: including output node in group crashed when it got
connected. Note that this feature is not supported to do anything
else than temporarily giving an output when editing node groups.
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!
report & fix from Martin Lubich (loramel)
Use double rather then floats, this doesn't use significantly more memory (as allocating a double buffer would), other vars in this function were doubles already so may even gain some speed.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
- 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.
