ScottyN91

Magic wand does not treat fully transparent pixels the same, and paint.NET creates differently-coloured transparent backgrounds during different operations

Recommended Posts

This is a combination of 2 related issues. The first and most important of the two is that the Magic Wand with 0% tolerance does not treat pixels with an alpha value of 0 the same if their RGB value is different. For instance, fully transparent black will not be selected if a pixel that is fully transparent white is selected with the 0% magic wand in add or replace mode.

 

The reason I noticed this functionality is due to the second issue, which is that by default when deleting a selection of pixels (be it the whole canvas or just a portion) or creating a new layer, the selection is filled with fully transparent white. However, when performing other operations such as resize image (larger or smaller), as well as using other plugins, these transparent pixels are changed to transparent black. This also commonly happens when I open a png downloaded from the internet and find the fully transparent portion of it is black, which causes issues when using the magic wand as described above, as the "default" is transparent white in paint.NET.

 

To give an example:

  1. Open a new image, which should be filled with solid white by default.
  2. Select all and delete, which fills the canvas with transparent white (the way I checked this was with the color picker tool).
  3. Create a square of opaque white (or some other colour) within the layer.
  4. Resize image (either smaller or larger)
  5. Use color picker on transparent portion of image around the square, and the portion will have changed to transparent black.
  6. Select the whole square (using rectangle select or 0% magic wand), and then move the selected pixels away from the square's current location.
  7. Deselect the square, and then use magic wand (with 0% tolerance and add or replace) on anywhere in transparent area except from where the square used to be.
  8. This will then highlight the void of transparent white that was left behind when the square was moved, which is not selected due to magic wand being used on the transparent black section around the old position of the square.

 

In addition, step 4 can be replaced with using plugins such as the latest versions of TR's AlphaCutter (which leaves transparent black behind in the areas not inside in the mask), or Vandermotten's series of Object Align functions, which leave behind transparent black in an area that represents how the object was shifted (for example if you use align to bottom and the object moves down, a thin strip of transparent black will appear at the top of the image that is proportional in size to the number of pixels the object was moved down by).

 

This makes using the magic wand slower than I would have hoped, because I need to use it in add mode to select the transparent black pixels as well as the default transparent white ones, in order to select all fully transparent pixels (I assume the Magic Wand would also segregate transparent red for example in this manner, which would require even more selections to be made). This needs to be done every time I do one of these operations, and the transparent black pixels then need to be deleted in order to change them to transparent white (the same is required when opening random pngs which have transparent black backgrounds).

 

One of the "solutions" is to increase the tolerance to around 5% in global mode, or 16% in contiguous mode on the Magic Wand to select all the transparent pixels, however I don't like doing this because it could select the very edges of the actual content on the canvas if that content has faded/feathered edges from opaque down to transparent going outwards, hence I use 0% to make sure I only select fully transparent pixels.

 

Fixing the magic wand issue would mask the second issue, so I don't know how relevant you feel it would be to fix the second issue also?

Are these two issues bugs, or something that I'm not quite understanding about how paint.NET works?

Thanks in advance.

Edited by ScottyN91
Changed wording to be clearer

Share this post


Link to post
Share on other sites

I think what you're looking for is for the Magic Wand tool to do its calculations in premultiplied alpha color space. Then, color values with an alpha of 0 are all equivalent.

 

This would probably be added as a button on the toolbar for selecting between the two. Premultiplied would probably be the default because it makes the most logical sense; using "straight" alpha is more of a niche scenario, AFAICT.

 

This is on the list, but it just hasn't made its way up to the top of the priority list.

  • Like 1

Share this post


Link to post
Share on other sites

A workaround to the problem of selecting different types of transparent pixels is to run the plugin Transparent to Transparent Black before doing the selection. As the name suggests, it will convert all the transparent pixels to the same value, (0, 0, 0, 0).

  • Like 1

Share this post


Link to post
Share on other sites

Hi @Rick Brewster and @MJW,

 

Sorry for not getting back to you in so long (and kind of necroing my own thread in the process), but I wanted to say thanks for your answers.

Rick, what you described is almost certainly what I'm looking to achieve with the magic wand, and I agree that it would make sense for it to be the default when it's implemented. Whilst I am a little disappointed that this feature isn't possible with current version of PDN, I totally understand that you don't have time to put in every feature/request from day 1, and I'm glad that it's on the to-do list for future releases - thanks for a great image editor so far!

 

Also, thanks MJW for suggesting your plugin to me, I've tried it already and it has definitely helped with getting rid of randomly coloured transparent pixels so I can select all transparent regions easily 👍.

 

Lastly, do either of you know why it is that plugins and even different tools within PDN use both transparent black and transparent white (as described in my OP)? Is there not something similar to a standardised transparent colour that plugin creators/the different built-in tools can call to make sure they all use the same colour for "transparent"?

Share this post


Link to post
Share on other sites
1 hour ago, ScottyN91 said:

Lastly, do either of you know why it is that plugins and even different tools within PDN use both transparent black and transparent white (as described in my OP)? Is there not something similar to a standardised transparent colour that plugin creators/the different built-in tools can call to make sure they all use the same colour for "transparent"?

 

I think it's because (in my opinion) the sensible value is (0, 0, 0, 0), but for some reason Microsoft defined the system-defined color "Transparent" as (0, 255, 255, 255). Some programmers set the transparent color by assigning the ARGB values, and they tends to use (0, 0, 0, 0), others use Microsoft's defined Transparent color. I suspect if Microsoft had defined Transparent as (0, 0, 0, 0), there'd be much less inconsistency.

Share this post


Link to post
Share on other sites

Ah ok, thanks for clearing that up. I guess this will just be something that'll always be there, but when pre-multiplied alpha gets implemented, the inconsistencies across the editor/plugins probably won't matter too much anymore.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now