- 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.
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.
Refactored code a bit to make naming a bit more clear and added a
function to create mesh from given display list rather than from
object's displist.
Tested using plain curves (which doesn't imply using derived meshes)
and curves with constructive modifiers (which are using derived meshed).
