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.
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).
notes:
- uncomment #define USE_RASKTER in BKE_mask.h to use the previous mask rasterizer.
- slightly slower for regular masks but significantly faster for feather.
- main benefit is that it threads well so works nice for tile compositor.
- feather is lower quality, can use some improvements here.
- feather can also use some interpolation enhancements, will do later.
Problems were in the old multires loading system.
Actually, the sigsev itself was the easy part of the job (simply had to convert from tesselated data to polys/loops), but after that I was getting a horrible bunch of wild stray faces...
It finally turned out it was a mismatch in two different subsurf structs used while computing a mdisps layer from the multires DM, leading to getting complete random normals (null ones, NAN ones...), leading to complete dummy tangent space matrix, leading to absurds mdisps values...
Note: I also moved the copy of first layer's vertex and face data from old me->mr to mesh's v/fdata earlier in multire_load_old(), to be able to use general face_to_poly conversion function (later on we would have to do it by hand, the general function would erase our newly computed mdisps layer...).
Took me the whole week (something like 20h) to track this down: multires + subsurf = C nightmare!
It used to be a dependency cycle which lead to incorrect or
missed tesselation on some circumstances.
Seems to be introduced in rev41627.
This commit seems to behaving properly on simple cases,
probably could fail in some other cases, so need to be
checked further.
Discovered when was looking into:
#32034: Metaball used as render object(group) for particle will display wire only.
