This implements simple function which collapses internal loops
caused by self-intersections into a singularity.
This loops can't be removed because rasterizer expects points
of feather be aligned with points from spline itself.
When OpenMP is enabled, memory allocation needs to be protected.
Fixes bug [#32111] Memory management regression from svn_46520
projects.blender.org/tracker/index.php?func=detail&aid=32111&group_id=9&atid=498
- Some of TODO notes were laying around but they in fact
were resolved a while ago, removed this notes form the code.
- De-duplicate input color space settings drawing in clip and
image spaces. Moved this stuff to a template which could also
be used in Python.
- Replace py-defined view transform settings panel with a
C-defined template as well. Use it in space panels and
image format settings.
- Remove display settings from color management settings
panels used by different spaces. Use window settings
instead.
This adds a user-defined input color space name for image and
movie clip data blocks. Support for this thing for other data
blocks is still a TODO.
Input color space is being used on loading file to convert
loaded image buffer from this space to scene linear space,
later this space is never used in a pipeline.
Color space name was wrapped into own structure like it's
done for display and view settings. This helps keep code
de-duplicated in RNA and it'll help when likely more options
are added into input color space settings (i.e. flag whether
image could be color managed or it's a non-color data).
This implied quite of internal refactoring:
- Made routines around threaded display buffer calculation
more general, so any kind of color transform could be
performed using the same technique.
- Added function to convert given float buffer from given
input color space to output color space. This is a public
function which could be used in such a things as compositor
node.
- Added function to convert ImBuf's content to scene linear
space. Currently used only for images and clips. Should be
added to any image/movie-related data blocks such as
sequencer strips, but that a bit more long-term plan.
- If input color space is set to NONE then no buffer transform
would be performed on image loading. It'll behave in the same
way as using scene linear as input space.
- Minor style cleanup
- Made scene linear space rec709 instead of aces
Reference space is still aces
- Get rid of hardcoded rec -. rec709 transformation on view transforms
This would make view transform be applied on a reference color space
how it's supposed to be.
Since scene linear is rec709 such a hardcoded transform isn't needed
anymore.
This also fixes wrong Log view transform which used to look really
weird and now it's nice and smooth.
- Also made changes to SPI and Nuke configurations to make them behave
properly with reference space of aces.
- Renamed Nuke's rec709 space to nuke_rec709. Probably it could be
replaced with scene rec709, but that's requires more investigation.
Several users requested the recovery as the removal of the two parameters was considered over-simplification for advanced users.
As in the Python Scripting mode, the two parameters are in the "advanced edge detection options" section and disabled by default.
Also the lower limit of Kr derivative epsilon was changed from 0 to -1000 so as to permit a negative value.
This auto/heat vgroup creation seems to be fuzzy/unstable (each run gives a slightly different result). I have not the competences (nor time) to investigate that laplacian stuff, so for now just adding an option when parenting to an armature with envelope/heat, to mirror weights along the X axis (as it is done by default when doing it from the Weight Paint mode).
This deadlock was caused by lock of threads using LOCK_DRAW_IMAGE
mutex and lock used in render result acquire functions.
So if image draw would lock LOCK_DRAW_IMAGE before compositor
operation released render result it'll lead into a deadlock.
Color management of byte buffers is currently disabled, to enable
it COLORMANAGE_BYTE_BUFFER from colormanagement.c should be defined.
Currently color management supposes that byte buffer is originally
in sRGB space. Ideally it'll be using the same input color space
setting as float buffer which is still in a TODO list.
It could be nice artistic option to play with. Also in theory it's
possible that byte images would store data in non-sRGB space.
There's still kind of issue with byte buffers which results in
showing linear image when view transform is set to RAW. It'll be
resolved as soon as real input color space is added. Other view
transformations should work fine.
