Blender Foundation: Blender 2.x BF release: Detail: 32527 Texture paint- grimy brush transition

Log In
New Account

[#32527] Texture paint- grimy brush transition

Date:
2012-09-10 02:26 Priority:
3

State:
Closed

Submitted by:
Bartosz Moniewski (monio) Assigned to:
Antony Riakiotakis (psy-fi)

Category:
None Status:
Todo / Closed

Relates to: Duplicates:

Patches:

Summary:
Texture paint- grimy brush transition

Detailed description

Win7- 64bit / GTX460 / blender 2.62 - 2.63a

When painting with soft brush their falloffs create darker grimy stain. Look at image:
http://i.imgur.com/os35Q.jpg
1) Pressed brush for 2 seconds to emphasis grime effect
2) Two quick strokes.
3) One stroke of dark color create even darker color in transition.

This occurs only in normal painting mode. While project painting color mixing is fine.

Followup

Message

Date: 2012-09-18 15:14
Sender: Antony Riakiotakis
Hi, two things to consider:

First, when painting in the image editor (I assume this is what you mean by "normal paintiing mode"), airbrush is considered on all the time, so if I turn on airbrush in projective painting I also get the fringes. Can you verify that please?

Second, the fringes themselves are due to using 8-bit per pixel images. These do not get their colours converted to linear space before mixing with brush colours due to precision loss, so the fringes are to be expected unfortunately. You can use float images to get a better result though.

Date: 2012-10-19 19:01
Sender: Ton Roosendaal
Hi Antony,

Can you explain this further? It's either a known limit (ensure the docs note this), or something we will work on?

Date: 2012-10-19 19:43
Sender: Antony Riakiotakis
Hi Ton, my guess is that this is caused because for texture painting with 8bit per component images we do colour blending in sRGB colour space. This sort of works but exhibits some artifacts (such as fringing) I have written a little example in my blog (http://psy-fidelity.blogspot.gr/2011/06/color-correction-revisited.html).
This should be either documented better or fixed, it's more a precision issue though because converting byte images from sRGB to linear can be lossy.

Date: 2012-10-20 10:44
Sender: Ton Roosendaal
I'm not convinced it's sRGB, it looks to me like there's alpha blend involved?

Date: 2012-10-24 14:12
Sender: Ton Roosendaal
OK I've investigated the topic.

Image Paint - as opposed to project paint in 3d - has been designed to work with fixed RGBA buffers for brushes. These buffers then get blended in the original image.
If you are working on 8 byte color, a successive series of brushes blended in with give errors very quickly, especially when blending values are low.

Example:
http://www.pasteall.org/pic/show.php?id=39436

That is because the byte precision gets very bad on low values - the error in precision accumulates quickly.

Project Paint (and also GIMP btw) use a float mask for that reason - not a RGBA buffer. It then does a per-pixel blend, each time rounding values in the best way possible.

What we should do once is to upgrade image paint to also do that. It's a huge amount of code there though, and not on the immediate list of attention to solve. I mark tis in our wiki as cool project for someone to pick up.

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Tools#Painting

Attached Files:

Name	Date	Download

dirtybrush.jpg	2012-09-10 02:26	Download

Changes:

Field	Old Value	Date	By

status_id	Open	2012-10-24 14:12	ton
close_date	None	2012-10-24 14:12	ton
Status	Investigate	2012-10-24 14:12	ton
assigned_to	none	2012-10-19 19:01	ton
Status	New	2012-10-19 19:01	ton
File Added	22002: dirtybrush.jpg	2012-09-10 02:26	monio