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.
-1..1) to fix errors in keying. Simplified chroma key to not take
despill into consideration (handled elsewhere). Simplified user
interface for pieces not used.
The problem was that typical lift values (0.5 - 1.5, in our case ) would over saturate shadows so that even minor adjustments would give unusable results.
tweaking the input lift to compensate for this helped with the shadows but would loose the color adjustments for the mid-tones.
Fixed by adding a 'slope' parameter to curvemap_reset() to mirror curve presets around Y axis.
Also removed curve preset with 'random' icon, wasn't doing what it looked like it should,
this was intended only for hue correct node anyway.
Use: 1 + ((lift-1) * (lift-1)) so 2.0 is still a full lift but 1.x isnt so strong.
Changed color picker to give more precission, we were having to edit the buttons to see what the numbers were.
This is because problem reported by venomgfx on the irc.
If you have a render of 2k with a render size of 25% (and this
problem is for any resolution/size) and you try to use a image
of 1k in the compo, the first thing you do is put a scale node.
Here come the problem, if you set the option "Scene Size" in the
node scale, the buffer output is not the same size that the render.
This is because the "Scene size" work with the image size and
not the render size, so in this case is the 25% of 1k.. not
the 25% 2k.
So this new option "Render Size" scale the output buffer to the
render resolution, taking into account the render size (percentage) too.
- In my changes lift was acting like a second gamma.
- In blender 2.4x it was being added which gave ugly clipping.
- in Magic Bullet Looks it scales the color about 1.0: (col - 1 * (2-lift)) + 1
Did more testing and made sure the order of applying lift/gamma/gain works the same as MagicBulletLooks (tested on Collin's mac laptop).
