Page MenuHome

bpy.ops.paint.image_paint with a texture requires initialization with manual paint stroke otherwise color not quite right
Open, Confirmed, MediumPublic

Description

System Information
Win 10 5820K GTX 970

Blender Version
2.79b and latest daily build

Short description of error
bpy.ops.paint.image_paint with slightly wrong colors when painting on object with texture on brush before a manual paint stroke applied

Exact steps for others to reproduce the error

  1. Load attached file
  2. Run script
  3. With mouse over the cube - press space and type Simple Modal Operator to activate modal paint operator
  4. move mouse about to paint.
  5. left click to stop modal paint operator
  6. now paint on the cube normally by holding mouse button down
  7. you will see this is a slightly different color
  8. press space and type Simple Modal Operator to activate modal paint operator again
  9. move mouse around
  10. you should now see modal operator painting correctly

This seems to happen each time I change the texture on the brush to a new one (with obviously different colors on it)

Image is attached showing this.

Possibly something not being initialized properly?

Thanks you in advance for any work on this.

Details

Type
Bug

Event Timeline

I have done a little further investigation.

It seems what is happening is this: bpy.ops.paint.image_paint does not use color space of the brush texture until after a stroke has been 'manually' done. Therefore the texture is being used as if it is in the raw texture space until a manual stroke overides this.

Having looked at the code it appears that the color space initialization for the texture is done in
paint_stroke.c
function: paint_brush_update (particualy lines 239->261)

However this is never called from the python code image_paint function.

As a workaround I tried adding the following (adapted from paint_brush update function) lines of code to
function: paint_stroke_new

     if (!stroke->brush_init) {
		ups->do_linear_conversion = false;
		ups->colorspace = NULL;

		/* check here if color sampling the main brush should do color conversion. This is done here
		* to avoid locking up to get the image buffer during sampling */
		if (br->mtex.tex && br->mtex.tex->type == TEX_IMAGE && br->mtex.tex->ima) {
			ImBuf *tex_ibuf = BKE_image_pool_acquire_ibuf(br->mtex.tex->ima, &br->mtex.tex->iuser, NULL);
			if (tex_ibuf && tex_ibuf->rect_float == NULL) {
				ups->do_linear_conversion = true;
				ups->colorspace = tex_ibuf->rect_colorspace;
			}
			BKE_image_pool_release_ibuf(br->mtex.tex->ima, tex_ibuf, NULL);
		}

		stroke->brush_init = true;
	}

Which seems to fix the problem - however - I have no idea if there are serious knock on consequences to this change which would break things (is stroke->brush_init needed here?)

I am sure there is a much more elegant solution.

Philipp Oeser (lichtwerk) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Apr 12 2018, 3:06 PM

Hi @Rob Hughes (RevDr) and thx for the report,
as a first note: I can confirm the issue and also that your code fixes it (I tested without stroke->brush_init -- but needs more research...)