- Move color management settings to scene, so it's now clear for
all areas (such as compositor, sequencer) which settings to
use for display buffers
- Currently removed per-editor color management settings. It could
be nice to have them, but they don't fit nicely into overall
pipeline and could be added as a override settings for display
only later.
- Make sequencer working in space defined by sequencer_workspace
role in OCIO configuration file.
If this role is not set, sequencer will fallback to legacy sRGB
Gamma 2.2 space.
Currently use vd16 color space for sequencer. Not sure what exactly
this color space is, but it's pretty close to SPI Film view and
it's still invertable.
- Sequencer will now output linear float buffers, not color managed
float buffers.
Before this sequencer used to output float buffers in sRGB space,
which was sequencer's working space. Now it can not output buffers
in this space since other areas are not aware of this space.
This also makes it's consistent that all float buffers in Blender
are in linear space.
- When saving render result into byte file format scene's display
transform would be applied on this buffer.
When saving files from image editor, there'll be a display
transform settings which are default set to scene's settings but
could also be overwritten.
Additional details are there (would be extended soon):
http://wiki.blender.org/index.php/User:Nazg-gul/ColorManagement
This avoids having bunch of cached images when doing animation rendering,
keeping all the memory available for rendered itself.
This keeps memory usage low when rendering huge edits with mixed
scenes and movie strips.
This should not affect on sped of video encoding, which was confirmed by
some own tests.
Currently commiting to tomato due to not sure if there's something
i can not foresee here.
Issue was caused by the way how render result was acquiring -- pointer
to render data was used to find needed render descriptor. It's not
reliable since render contains copy of scene's render data, not pointer
to this data.
Use node scene's id name for render result acquiring, the same way
as it was done in old compositor system.
Issue was caused by Cycles using render options from rendering scene, not
from active scene.
For now solved by passing render resolution inside RenderEngine structure.
This probably could be solved in more general way, like adding bindings
for RenderEngine->Render, which would avoid passing options like
is_animation, came_override and so via RenderEngine. Would think about
this a bit more and probably would do that.
The same issue happens in trunk as well, but not consider such a change
trunk-ready, would want to make more tests and probably clean the code
a little bit before commiting this into trunk.
This fixes memory overflow caused by creating render result every time
RenderResult is creating when updating sample and not being freed until
tile is fully rendered.
Solved in probably not best way -- RenderResult is being stored in
RenderBuffers, so it's creating only once.
This solves memory issues, but while was looking into this issue
discovered dramatic slowdown caused by samples update in some files
from mango svn.
Solving this slowdown is becoming first priority from now on.
