Odd fill behavior when working with different sections of identical color

[Japhasca]

My fill settings default except: 0% tolerance and no anti-aliasing.

 

I've noticed when I use the selection and move tools (with anti-aliasing off, so I know there's no "almost-the-same" issue going on with colors) to rearrange some areas, when I go to fill them in, I have to do each moved section seperately, when they are touching and the same color, as though they were being preserved as separate sections.

 

Here is an example (this is drawn on a layer with only the black outline; the white is background and the rest of the layer is transparent.)

 

1: A black outline is drawn in pencil.

2: An area has been outline with the selection tool, and moved to the side.

3: The two areas are now reconnected with pencil. Keep in mind NO OTHER COLORS HAVE BEEN USED SO EVERYTHING ELSE IS TRANSPARENT.

4-6: The shape has to be filled in three sections, as though they were different colors.

 

Edited July 9, 2014 by Japhasca

[BoltBait]

Increase your tolerance to 5%.

[Japhasca]

Increase your tolerance to 5%.

Thanks. That seems to do the trick, although I'm still assuming it's a bug since there is literally no color difference in the sections. Will use this workaround for now!

Edited July 9, 2014 by Japhasca

[zeromus]

This seems to happen because there is some indeterminate nonsense left behind in the seemingly transparent area. In my case, there are some (255,255,255,0) pixels and some (0,0,0,0) pixels. Use your eyedropper to scrub over some of the area opened up by moving the piece and you can see it. The flood fill notices discrepancies in the RGB values which you can't see.

 

This doesn't seem to be affected by the current primary color selection or the color of the moved edge or even the color of the fill.

[Red ochre]

There was always some question over the RGB values of 0 alpha areas - often as a result of previously used plugins just changing the alpha to preserve colour information.

My 'Object2colour' plugin was, in part, designed to reset RGB values of transparent areas.
 

http://forums.getpaint.net/index.php?/topic/25420-object2colour/

 
I know that doesn't solve the problem but may help, I hope.

[Rick Brewster]

Well, it's not "indeterminate nonsense" It's pure zeros, which makes sense mathematically. There's a few questions here I'm pondering ... 1) should the paint bucket be doing its comparisons using premultiplied alpha, in which case all transparent colors would be treated the same?, or 2) should the Move tool leave behind transparent white pixels?, or 3) should new layers be filled with transparent black instead of transparent white?

 

3.5 leaves behind transparent white. Not sure why or why not. I've filed a bug to look into this. Whether or not things make sense mathematically, it's not really an ideal user experience as described here.

[BoltBait]

1) should the paint bucket be doing its comparisons using premultiplied alpha, in which case all transparent colors would be treated the same?

I vote for this.

(If we are voting.)

[Ego Eram Reputo]

1. I'd go with this. I think this is the behavior most users anticipate.

2 & 3. Why white or any color? Why not 0,0,0,0? I'm sure there is a good reason & would like to know what it is.

[Japhasca]

If I'm understanding this correctly, then whatever values transparent pixels have to begin with should be what's left behind by any function that removes other pixels, be it a full erase, moving a section, etc. If it's not that simple I apologize >_< but I appreciate the look into the matter.

[zeromus]

First of all, it's indeterminate nonsense. It is a combination of transparent black and transparent white in a pattern which resembles an accident.

 

I vote #1 _and_ #3.  Experiment: make a new document, select it all, and cut it all. Now what's left? Transparent black. That's "all zeroes", as you say. It's mathematical. What's in a new, seemingly empty layer should be the same as what's in a layer you just deleted the entire contents of.

 

In Paint Shop Pro, the pixel moving tools leave behind whatever the current secondary color is. That could be useful for spriters, but I doubt anyone else will like it. But, for the sake of brainstorming, that's another option.

 

Japhasca, you're moving pixels. There's nothing to leave behind. There should be no trace of what used to be there. So the question in this case is, what's there when there's nothing? That's one of the things we're discussing.

 

Actually, photoshop leaves even more stunning patterns of 'traces of what used to be there'. 

[Thorsby]

If you choose option 2 or 3 instead of 1, you'll still have the problem with pictures you started on before version 4.

[Red ochre]

1. Sounds sensible.
2. Tricky. On balance, I would prefer to leave transparent white. Leaving colour information can give unexpected results when using plugins that alter alpha. I can see very few cases where recovering that information would be practical or useful.
( Information between A = 1 & A = 255 is useful though.)
3. I would keep transparent white as the default - changing it now could possibly interefere with anti-aliasing on some plugins.

I have no right to vote.

[Rick Brewster]

3.5 fills the area with the secondary color with the alpha value set to zero.

[Rick Brewster]

This is fixed for 4.0.1

[Ryuza]

Hopefully it's alright to post this here since it hasn't been too long since the last post.

 

I've been having the same problem the original poster had with this, where I move a selection and try to fill the empty space and it's treated differently, I had the problem on 4.0 and after updating with the fix. Right now a new layer is transparent white, a deleted area is transparent black, and the area left over after moving something is your secondary color but transparent. It seems like it'd be easier to work with if they all used one set color like black with an alpha value of 0.

 

I'm not sure if it's just the type of work I do, spriting and such, but it's been coming up often where I have to keep deleting a lot of empty blocks of space that use various transparent secondary colors. If it's useful for some people to leave it as it is maybe there could be an option that lets you either use the transparent secondary color or transparent black?

Edited July 21, 2014 by Ryuza

[zeromus]

I'm still seeing some kind of problem (basically what I already described) in 4.0.2. I'm seeing some pixels with (Sr,Sg,Sb,0) where S is my secondary color, and some pixels with (0,0,0,0) left behind after moving a few pixels on a mostly transparent layer.

Edited July 21, 2014 by zeromus

[Ryuza]

Has there been any update on whether this might be worked on more?

[Ego Eram Reputo]

The Developer of paint.net is having a well deserved break. Rest assured he will be taking note of these issues.