Custom Texture Tool PS v46.2

[Admentus]

Yup, it is fixed!

[Bighead]

---

PNG Alpha Pixel Manipulation

I'll start by saying that even if a pixel has 0% alpha, it can still contain valid data in the RGB channels. This could lead you to think that since it's invisible, it has no relevant properties since it can not be seen. I recently discovered that isn't the case, and there are many situations where color values are still used when the alpha value is zero, so the operation PNG Alpha Pixel Manipulation comes into play. This operation and its various sub-operations can fix various issues involving alpha that don't show up correctly in-game. As far as I can tell, it is mostly games developed by Nintendo themselves that this issue is most common.

---

There are six options to pick from:

Convert Fully Transparent Color Pixels to Opaque
Function: Pixels where (R>0 or B>0 or G>0 and A=0) are converted to (A=255)
Sometimes Dolphin dumps textures that are fully transparent, but actually contain color data. Use this option to expose these hidden image so they can be edited. The final edited image may need to have its transparency restored.

Add Full Transparency and Keep Pixel Color Data
Function: All pixels are converted to (A=0)
This is the inverse of the option above. This makes an image fully transparent while keeping the color data. Use this after editing an image that was made visible with the option above.

Set Fully Transparent Black Pixels to White
Function: Pixels where (R=0 B=0 G=0 A=0) are converted to (R=255 B=255 G=255 A=0)
Some games expect textures with an invisible white mask. This option searches for pixels that contain no alpha and color data and fills them with white invisible pixels.

Set Fully Transparent White Pixels to Black
Function: Pixels where (R=255 B=255 G=255 A=0) are converted to (R=0 B=0 G=0 A=0)
This is the inverse of the option above, and can remove an invisible white mask. This can also be used to fix an issue with PhotoShop sometimes exporting an image with invisible white pixels (issue mentioned here).

Remove All Color Data From Fully Transparent Pixels
Function: Pixels where (R>0 or B>0 or G>0 and A=0) are converted to (R=0 B=0 G=0 A=0)
This option can be dangerous as it destroys color data from pixels that are fully transparent. It can be used to repair textures that look strange in-game because somehow color data was not destroyed when erasing these pixels in a graphics editor. An example can be seen here. These pixels were not supposed to be there. Although they were fully transparent, the color data was set to R=188 G=188 B=188, and the game showed them despite A=0.

Customize Data For Transparent Pixels
Function: Full control over transparent pixels allowing to overwrite their RGBA values
This is a very powerful option and depending on the configuration can actually replicate any of the above options (and then some). This option searches for pixels with a user defined alpha value (<= 0-255) and allows manually setting the RGBA values of the pixels with anything the user wants. It can turn transparent pixels opaque, increase alpha selectively, and fill entire areas with colors.

---

This section explains each option a bit more in-depth with examples.

Convert Fully Transparent Color Pixels to Opaque: (Show Spoiler)

Function: Pixels where (R>0 or B>0 or G>0 and A=0) are converted to (A=255)

The first example is this eye texture from Wind Waker:



When this texture dumped, it was completely transparent. I would have never given it a second look if Windows didn't somehow show the eye in the thumbnail. But upon viewing it, it was just a blank canvas. This is where the option Convert Fully Transparent Color Pixels to Opaque comes into play. After applying it to the texture, the image revealed itself. On the technical side of things, it searches for any pixels that have a value >0 in the RGB channels and sets the alpha channel to 255.

So now that I had a visible texture, I created an HD version and tossed it into the pack. Every so often, I send my updates to Hypatia who is currently playing through the game. A few days later, she sent me the image below, which is a bug because the eye is supposed to be closed when it curls up into a ball:



This is obviously incorrect. So while I was able to make the pixels visible with this option, it still needs to be converted back with the next option.

Add Full Transparency and Keep Pixel Color Data: (Show Spoiler)

Function: All pixels are converted to (A=0)

This is merely the reverse of the above option, and reverts all pixels to fully transparent but keeps the color data. While any texture that has a bunch of nothing would probably work in the example above, I like to keep things canon, so this is where Add Full Transparency and Keep Pixel Color Data is needed. It will keep the color data but make the image fully transparent, which is how it was when dumped. Any pixel that contains >0 in any RGB channel has alpha channel set to 0. This fixed the eye above, and it now closes properly when in defense mode. How did this happen? My guess is that the original Zelda: WW artists just selected all and deleted the original eye from the canvas, making a fully transparent image. But the software they used kept the color data.

It is very unlikely that this option will ever be needed, as this situation seems EXTREMELY rare. The eye texture above is so far the only known example, and it's not even required to reverse the process (a blank texture also works in this situation). For this option, I can't really post an example like the others, as the example would be invisible anyway.

Set Fully Transparent Black Pixels to White: (Show Spoiler)

Function: Pixels where (R=0 B=0 G=0 A=0) are converted to (R=255 B=255 G=255 A=0)

Next up is this lava texture:


Although it was created with identical colors as the original texture, it did not show up in-game in the same way.


This completely baffled me for awhile. I could not figure out why it was showing up so wrong. So I started poking at the pixels of the original texture using GIMP and found something interesting...



The transparent pixels are actually white even though you can not see them. I could not find a way to replicate this in GIMP. If you create a layer, fill it with white (RGB set to 255), set alpha to 0%, and export as PNG, the color data is lost (RGB is set to 0). This can now be circumvented in recent GIMP versions by checking "Save color values from transparent pixels" when exporting the image.
This is where Set Fully Transparent Black Pixels to White was needed. This will search for any pixels where (R=0, G=0, B=0, A=0) and max out the RGB values (R=255, G=255, B=255, A=0) creating an invisible white mask. And with this, the lava was finally correct.

Set Fully Transparent White Pixels to Black: (Show Spoiler)

Function: Pixels where (R=255 B=255 G=255 A=0) are converted to (R=0 B=0 G=0 A=0)

This option more or less fixes issues caused by raster graphics editors. It is known both GIMP and PhotoShop can leave behind stray white pixels when working on grayscale images. Suppose you start with a fully white canvas, then delete those pixels. There is a chance that those pixels are still there just invisible! Discovered by calebthegeek, the Gamecube game "Wario World" is sensitive to those invisible white pixels. A picture is worth a 1000 words, you can see the "heart" texture is just showing up as a gray circle.



Removing those "white" pixels and setting them to "black" fixes the issue.


This "issue" was also prevalent when editing the fonts in Metroid Prime Trilogy (issue discovered and fonts by Malkierian), which this option can work around.


For more information check out this post:
https://forums.dolphin-emu.org/Thread-metroid-prime-1-2-3-and-trilogy-hd-texture-pack?pid=493365#pid493365

Remove All Color Data From Fully Transparent Pixels: (Show Spoiler)

Function: Pixels where (R>0 or B>0 or G>0 and A=0) are converted to (R=0 B=0 G=0 A=0)

This option is similar to the one above, but removes all color data from transparent pixels no matter what their value is, rather than any pixels where R=255, G=255, B=255.



The circled area had some "ghost" pixels that was affecting how the texture looks in-game. The alpha was set to 0 so it was completely invisible, but the pixels still had color data (Gray: R=188, G=188, B=188, A=0). So what this option does, is search for any pixels where A=0, and sets RGB=0. It will never change how the image looks since it only affects pixels with 0% alpha, but those pixels may have junk color values that somehow evaded the eraser.

As it turns out, this option also fixes a long-standing issue that General_Han_Solo was having with his Rogue Leader packs.



Apparently, certain textures had completely transparent pixels around the borders that still contained color data and were creating a white box around them. Removing the color data fixes the issue.

Customize Data For Transparent Pixels: (Show Spoiler)

Function: Full control over transparent pixels allowing to overwrite their RGBA values

This is actually a really difficult option to explain as it has many potential uses.



Search Type: This allows defining which pixels are selected for the custom fill values.
• No Color Data - Pixels must have a value of zero in the RGB channels.
• Allow Color Data - Pixels can have any value in the RGB channels.

Search Treshold: Defines the maximum alpha value a pixel can have to be selected for the custom fill values.

Custom RGBA Fill Values: Defines the RGBA values to fill selected pixels with.

I made a post here to show how it can be used to upscale textures with "Invisible Pixels".
https://forums.dolphin-emu.org/Thread-ssx-3-hd-texture-pack-uhd-fhd?pid=504650#pid504650

And the user/pack creator leonnyxx made a great and thorough blog post here.
https://leonelvidals.blogspot.com/2020/03/ssx-3-hd-texture-pack.html

---

So that covers that. The takeaway is, if Dolphin dumps a texture that is completely invisible, there might actually be something there. If a texture with transparency isn't showing up correctly in-game, there may be some invisible pixels that are doing something that you can not see.

[Bighead]

This fixes a really bad issue that can cause PowerShell to eat several GB of RAM when writing DDS textures. Please update!
http://www.mediafire.com/file/dqbj1psjpc1t67i/Custom+Texture+Tool+PS+v36.2.zip - (Edit: Link was updated, it is safe.)

I'm going to guess this issue has been there ever since I started generating custom headers. I discovered it last night when I was trying to convert a 133MB 8192x8192 texture to BC7 and received an error that a byte array was out of bounds. This didn't make sense to me, a texture would have to be over 2GB to exceed the array limit. Luckily, the good people at Stack Overflow are as sharp and helpful as always.
https://stackoverflow.com/questions/52361118/powershell-consumes-gb-of-ram-when-returning-large-byte-array

But the issue was actually two-fold. I fixed the above issue, and realized it was still using about half as much RAM as before which was still in the GB. It turns out adding byte arrays together directly does the same thing (I add my custom header array to the pixel array then write the image). Instead, using a method such as "Array:Copy" or "Marshal:Copy" into a new array prevents the conversion to an "object" array, which is what is causing the memory issue.

Edit: Arghh, don't use this version if you managed to download it. It is corrupting DDS textures, apparently I messed up something when combining the arrays.

Fixed here:
http://www.mediafire.com/file/dqbj1psjpc1t67i/Custom+Texture+Tool+PS+v36.2.zip

[Ivan89el]

Hey. In recent versions, have an error on startup: http://fastpic.ru/view/89/2018/1008/d3c61bb0d2ccc95a43dd47cdaecd6a1f.png.html
They also work much slower, and does not work waifu2x caffe (only waifu2x-converter). Latest version that works well v33.0, but she occasionally crashes. Sorry my english.

[Bighead]

The script is probably very broken using PowerShell v2, I'm surprised it works at all. I dropped support for it in v34.0.
https://forums.dolphin-emu.org/Thread-custom-texture-tool-ps-v36-2?pid=478448#pid478448

I should update the first post. You will need to update PowerShell, I'll link v5.0 below:
https://www.microsoft.com/en-us/download/details.aspx?id=54616

If you are using Windows 7 64-bit, you will want: Win7AndW2K8R2-KB3191566-x64.zip
If you are using Windows 7 32-bit, you will want: Win7-KB3191566-x86.zip

Please let me know if this fixes your issues.

[Ivan89el]

Unfortunately, this update has already been installed on my computer.

[Bighead]

Ok I'm not sure what's going on then. The image you linked: http://i89.fastpic.ru/big/2018/1008/1f/d3c61bb0d2ccc95a43dd47cdaecd6a1f.png
...is the classic window also used when using CMD.exe, which was what was used in PowerShell v2.0.

Before I can help further, please run this script and screenshot the information it shows:
http://www.mediafire.com/file/m3ae7o1tzy4ohh8/GetPowerShellInfo.ps1/file#

You should get a result similar to this:

[Ivan89el]

Here is my result: http://fastpic.ru/view/91/2018/1010/4f18060e7fec38323d13a50a0cb919af.png.html

[Bighead]

Okay you definitely have v5 of PowerShell installed. I can probably fix the error starting up, I'm guessing it has to do with your screen resolution. The error itself shouldn't cause any problems however. I'll have to get my VM up and running again to really test everything.

[Ivan89el]

Maybe. Problems did not arise except a very slow speed and not working waifu2x caffe