System Information
Operating system: n/a
Graphics card: n/a
Blender Version
Broken: at least 2.8, maybe earlier
Worked: n/a
Short description of error
When projection painting an image with float data onto an image with char data (or v.v.) the data gets converted in each thread without locking, leading to race conditions and wrong output.
Exact steps for others to reproduce the error
make sure you run on a multithreaded processor
-default startup
-set the base color of the material of the cube to image texture. create a new image texture using the default settings.
-set a camera background image from an .exr file containing float data.
-select cube, go to texture paint mode.
-from options -> external choose apply camera image. choose the .exr image
result=> sometimes nothing at all happens, sometimes the image gets applied but stippled, sometimes it works as expected.
You can get similar effects (though it (accidentally) works correcly more often) by projecting a jpg image (char data) onto a float texture in the material.
The problem is in the file source/blender/editors/sculpt_paint/paint_image_proj.c (line numbers against commit d376aea61)
at the lines 5309 and 5320 the functions
IMB_float_from_rect(ps->reproject_ibuf);
and
IMB_recr_from_float(ps->reproject_ibuf);
are called to convert the source image data to the correct format. However, ps->reproject_ibuf is shared between threads, so this is not thread-safe. The checks on line 5308 and 5319 are already a race condition.
I created a patch
which fixes the problem , but I'm not sure if I'm overlooking something.This makes sure reproject_ibuf contains the correct formats *before* the threadpool is started.
I replaced the original location of the conversions with BLI_asserts(). That may be overkill?
Is posting a patch here the best way to submit a patch? or should I create a pull request on github or something like that?