Issue happened for scene. movie clip and mask strips, which contains
pointers to datablocks which are freeing on loading new file.
Also, scene strip would crash when pasted from clipboard after scene
was unlinked from file.
Before this change only old flag "Premultiply" was used to
detect alpha mode, which is not enough actually.
Now the logic here is:
- If "Premultiply" was enabled it is likely float image with
straight alpha, which shall be premultiplied before usage.
In this case image/sequence Alpha Mode is set to Straight.
- Otherwise use default alpha mode for image format based on
an extension. This could fail in some cases like TIFF, but
this wasn't handled fully correct in older blender anyway.
Initial discovered issue was that EXR images saved in older
Blender versions were set to Straight alpha mode, which is
obviously a straight way to lots of headache.
without hurting quick texture painting
- ED_view3d_draw_offscreen will now output buffer with
transparent alpha, if sky needed it should be alpha-undered
later.
- ED_view3d_draw_offscreen_imbuf now accepts alpha mode as an
argument which could be either R_ADDSKY or R_PREMULALPHA
- OpenGL render and sequencer's opengl preview will now reflect
scene's Alpha Mode
- Quick Edit will use OpenGL with transparent alpha mode
- add sequence.update(data=False) function.
- made some sequence vars editable.
- correct some comments.
also rename rna function sequence.getStripElem() --> strip_elem_from_frame()
This assumptions are now made:
- Internally float buffers are always linear alpha-premul colors
- Readers should worry about delivering float buffers with that
assumptions.
- There's an input image setting to say whether it's stored with
straight/premul alpha on the disk.
- Byte buffers are now assumed have straight alpha, readers should
deliver straight alpha.
Some implementation details:
- Removed scene's color unpremultiply setting, which was very
much confusing and was wrong for default settings.
Now all renderers assumes to deliver premultiplied alpha.
- IMB_buffer_byte_from_float will now linearize alpha when
converting from buffer.
- Sequencer's effects were changed to assume bytes have got
straight alpha. Most of effects will work with bytes still,
however for glow it was more tricky to avoid data loss, so
there's a commented out glow implementation which converts
byte buffer to floats first, operates on floats and returns
bytes back. It's slower and not sure if it should actually
be used -- who're using glow on alpha anyway?
- Sequencer modifiers should also be working nice with straight
bytes now.
- GLSL preview will predivide float textures to make nice shading,
shading with byte textures worked nice (GLSL was assuming straight
alpha).
- Blender Internal will set alpha=1 to the whole sky. The same
happens in Cycles and there's no way to avoid this -- sky is
neither straight nor premul and doesn't fit color pipeline well.
- Straight alpha mode for render result was also eliminated.
- Conversion to correct alpha need to be done before linearizing
float buffer.
- TIFF will now load and save files with proper alpha mode setting
in file meta data header.
- Remove Use Alpha from texture mapping and replaced with image
datablock setting.
Behaves much more predictable and clear from code point of view
and solves possible regressions when non-premultiplied images were
used as textures with ignoring alpha channel.
- script stub printed resource warning with py3.3 (not closing a file).
- bmesh customdata layer access had bad docstring.
- float/double conversion warnings in sequencer code (use doubles since result is double)
- remove unused var
That was kind of a regression since fix for #32091: Crop and offset coordinates changes proxy
render settings on image strips, which is now fixed in other way.
Namely Offset/Crop values are filling in 100% scene resolution values, but getting scaled to
proxy / scene percentage values.
BKE_scene_update_for_newframe should be called before RE_BlenderFrame in
seq_render_scene_strip. It's not entirely nice, but bot sure about better
solution for now.
There were two issues in scene strip rendering:
- It will skip rendering if scene doesn't have camera but uses compositor
- G.is_break will cancel preview rendering
Also removed Use Sequencer from scene's strip settings, it's not supported.
Sequencer recursion was never actually supported and only gives lots of
issues. Disabled it now, so users are not getting confused by semi-working
stuff.
Also made a correction to rendered sequencer preview, so now using scene
strip in it's own sequencer will work properly (it produced black frames
before).
This required killing compositor jobs since they could be using the same
render result as renderer called from sequencer uses.
Small improvements could be:
- Add slight delay before compositor job starts handling nodes so killing
this job would be fast
- Tag compositor to be updated after preview was fully rendered.
The issue was caused by SEQ_BEGIN macro modifying sequence's depth
which ruined transformation routines. Used own DFS instead which
doesn't modify sequences.
Also corrected some typos in api and comments.
Made offset and crop working in final resolution space, meaning that visual result
would be the same when using different proxy resolution in sequencer preview and
different resolution percentage when rendering.
It could break some files designed to with render percentage not equal to 100%
using wrong image crop and offset values. But this would also make it easier to
setup scene and render it with different percentage (useful for preview renders
for example)
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
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.
--
svn merge -r50051:50052 ^/branches/soc-2011-tomato
- freeing a mask from RNA BKE_libblock_free() twice on the mask.
- loading a new blend file would only free the mask and not unlink it from nodes - it would access freed memory.
