Custom Texture Tool PS v50.1

[opengrip]

Hey sorry to have another issue so soon... noticed while using SFTGAN it fails no matter what settings im using if the image has a detected alpha channel. Not sure if this is normal... or if there is a workaround..here is the log.

SFTGAN: Upscaling main image...
--- Job Loop Started (SFTGAN)
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
Traceback (most recent call last):
+ CategoryInfo : NotSpecified: (Traceback (most recent call last)::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
+ PSComputerName : localhost

File "test_segmentation.py", line 76, in <module>
output = seg_model(img).detach().float().cpu().squeeze()
File "C:\Users\dansm\AppData\Local\Programs\Python\Python36\lib\site-packages\torch\nn\modules\module.py", line 493,
in __call__
result = self.forward(*input, **kwargs)
File "D:\CTT-PS Programs\SFTGAN\pytorch_test\architectures.py", line 72, in forward
x = self.feature(x)
File "C:\Users\dansm\AppData\Local\Programs\Python\Python36\lib\site-packages\torch\nn\modules\module.py", line 493,
in __call__
result = self.forward(*input, **kwargs)
File "C:\Users\dansm\AppData\Local\Programs\Python\Python36\lib\site-packages\torch\nn\modules\container.py", line
92, in forward
input = module(input)
File "C:\Users\dansm\AppData\Local\Programs\Python\Python36\lib\site-packages\torch\nn\modules\module.py", line 493,
in __call__
result = self.forward(*input, **kwargs)
File "C:\Users\dansm\AppData\Local\Programs\Python\Python36\lib\site-packages\torch\nn\modules\conv.py", line 338,
in forward
self.padding, self.dilation, self.groups)
RuntimeError: Given groups=1, weight of size 64 3 3 3, expected input[1, 4, 512, 256] to have 3 channels, but got 4
channels instead
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
Traceback (most recent call last):
+ CategoryInfo : NotSpecified: (Traceback (most recent call last)::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
+ PSComputerName : localhost

File "test_sftgan.py", line 55, in <module>
seg = torch.load(os.path.join(test_prob_path, basename + '_bic.pth'))
File "C:\Users\dansm\AppData\Local\Programs\Python\Python36\lib\site-packages\torch\serialization.py", line 382, in
load
f = open(f, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: '../data/samples_segprob\\t_01__bat_n01_bic.pth'
<< Job Loop Iteration >>
<< Job Loop Iteration >>
<< Job Loop Iteration >>
--- Job Loop Ended
End Processing File ---

[Bighead]

Definitely not intended. ESRGAN and SFTGAN do not support images with alpha by default. The script should work around it by extracting the alpha channel and upscaling it separately (at the cost of 2x the time), then combining the two at the end if the option is ticked to save alpha. I'll have to check it out and see whats up, I thought it was working but maybe not... It might be broken if these conditions line up: the image has an alpha channel, saving alpha is NOT checked. I can't remember if I'm converting a 4 channel image to a 3 channel one before sending it to ESRGAN or SFTGAN when preserving alpha is toggled off.

Edit: Just tested and I can't reproduce the error. I attempted SFTGAN on an RGBA 128x128 texture, with and without preserving alpha, and with and without upscaling in segments. The results are what I would expect.



I would still like to help try to get to the bottom of it. Two things I can think to ask:
- What exact settings did you use (upscale operation and SFTGAN settings)?
- Can you send me the image to see if I can reproduce it?

[Kirbeast]

I'm using OptiPNG on this texture png pack https://forums.dolphin-emu.org/Thread-super-smash-bros-hd-retexture-project-v4-0-3-august-2015
On a lot of the textures it is saying the texture optimized (Reduction: size in kb). I check out the texture and OptiPNG didn't change anything, still the same size as before, even though it said it optimized it.
Why is this happening? Is this a bug?

[Kirbeast]

I created a Resource Pack with your Resource pack manager, I put it in the Recourse Pack folder. Open dolphin and I get this error "error occurred while loading some texture packs"
I'm not sure why this is happening maybe its a bug? any ideas how I can fix it?

[Bighead]

I tested it and OptiPNG is definitely working. By default a copy of the optimized texture is created in ~CTT_Generated/OptimizedTextures, but you can overwrite the original texture with the optimized one as it is optimized with the option Optimize Textures in Place.

Spoiler: (Show Spoiler)

Optimized / Original / OptiPNG Settings
   

If I may ask, what is the reason for wanting to run OptiPNG? This only reduces the file sizes of the PNG textures on disk, it does not make them any faster or any smaller in RAM/VRAM. It's mostly just for a final step when creating a PNG pack to take it that little bit further ; optimize it to take the least amount of disk space for archival purposes.

The Smash Bros. pack you linked has a DDS version available, which is preferable over the PNG version. DDS is much faster, eliminates most stuttering, etc. etc. I do suggest always using DDS texture packs over PNG texture packs if available. And if not, create one yourself.

I also attempted to generate a resource pack with the Brawl pack and it seems to work fine even when choosing compression.

Spoiler: (Show Spoiler)

When you go to create a resource pack, make sure the Texture Path is set to the root of the texture pack folder, and that the "GameID" is correct.

Spoiler: (Show Spoiler)

[Kirbeast]

(07-28-2019, 06:17 PM)Bighead Wrote: I tested it and OptiPNG is definitely working. By default a copy of the optimized texture is created in ~CTT_Generated/OptimizedTextures, but you can overwrite the original texture with the optimized one as it is optimized with the option Optimize Textures in Place.

Spoiler: (Show Spoiler)

Optimized / Original / OptiPNG Settings
   

If I may ask, what is the reason for wanting to run OptiPNG? This only reduces the file sizes of the PNG textures on disk, it does not make them any faster or any smaller in RAM/VRAM. It's mostly just for a final step when creating a PNG pack to take it that little bit further ; optimize it to take the least amount of disk space for archival purposes.

The Smash Bros. pack you linked has a DDS version available, which is preferable over the PNG version. DDS is much faster, eliminates most stuttering, etc. etc. I do suggest always using DDS texture packs over PNG texture packs if available. And if not, create one yourself.

I also attempted to generate a resource pack with the Brawl pack and it seems to work fine even when choosing compression.

Spoiler: (Show Spoiler)

When you go to create a resource pack, make sure the Texture Path is set to the root of the texture pack folder, and that the "GameID" is correct.

Spoiler: (Show Spoiler)

Thanks for replying and the tool!
Maybe my file path is making the problem the tools aren’t on the root of my hard drive. I do have the new file path setup, worth trying.

I’m using OptiPNG to reduce file size of the png textures and fix errors if it actually does that
It’s for a project called Smash Bros. Legacy TE, we distribute a dolphin build pre setup with our game to thousands of people. So if that is a bit smaller in filesize the better.

I didn’t use the pre packaged dds pack because it’s not in the better BC7 format. So I’m converting it myself to the higher quality format.

From what you said I don’t think I really understand stand the purpose of OptiPNG. So let me ask some question to get this straight.
Does OptiPNG reduce the quality of the image?
Does it fix some textures not loading in dolphin?

I’m thinking that my folder hierarchy is not correct for my recourse pack. I can download your Super Mario Bros Wii HD recourse pack for a good comparison.

[Kirbeast]

Well I re downloaded and installed the program without changing the Tool Master Path, and OptiPNG is actually working! Maybe it is also because I used 7zip to unzip the ctt-ps_programs_installer.exe, who knows, I'm just glad its working now. My recourse pack was missing the game id folder... I remember seeing it there, but I'm glad I could figure it out with you help!!
Thank you!

[Bighead]

(07-29-2019, 06:35 AM)Kirbeast Wrote: Maybe my file path is making the problem the tools aren’t on the root of my hard drive. I do have the new file path setup, worth trying.

The file path doesn't matter for most applications, just ESRGAN and SFTGAN. Those are the full reason I suggest installing the CTT-PS Programs Pack to "AppData" or "C:\" and not "Program Files" because my script (CTT-PS) can directly modify those scripts (.py) to change some options. If they are in program files, my script can not write to them without some trickery to elevate permissions which comes with its own problems. All other programs are simply run or read (rather than written to), so where they are located does not matter.

(07-29-2019, 06:35 AM)Kirbeast Wrote: I’m using OptiPNG to reduce file size of the png textures and fix errors if it actually does that

Reducing file size is solely what it does. As far as I know, it doesn't fix any errors. In fact, if you use it directly it can actually cause errors (in regards to Dolphin texture loading). In some cases, if OptiPNG reduces the bit depth then the texture will not load. It can also convert the image from RGBA to an indexed image, and I've found examples of these that don't load in Dolphin. I have set conditions in CTT-PS that does not allow these optimizations, so as far as I know using this tool is the only "safe" way to use OptiPNG.

(07-29-2019, 06:35 AM)Kirbeast Wrote: I didn’t use the pre packaged dds pack because it’s not in the better BC7 format. So I’m converting it myself to the higher quality format.

Good call.

(07-29-2019, 06:35 AM)Kirbeast Wrote: From what you said I don’t think I really understand stand the purpose of OptiPNG. So let me ask some question to get this straight.
Does OptiPNG reduce the quality of the image?
Does it fix some textures not loading in dolphin?

No it does not reduce image quality. The pixels that you see with your eyes should not change. And if they do, then that would be a bug. OptiPNG attempts to remove data without changing the image appearance. This can be done by reducing: bit depth, color type, color palette, and/or removing alpha channel. Not all of these are good for the purpose of texture loading and can "break" the image. So that answers your second question, it does not fix textures not loading but has the potential to break them (except when using it with CTT-PS).

The wrap-up answer is: OptiPNG reduces file size, does not change pixels, it can break textures, but not when using this script (CTT-PS) unless they are already "broken".

(07-29-2019, 06:35 AM)Kirbeast Wrote: I’m thinking that my folder hierarchy is not correct for my recourse pack. I can download your Super Mario Bros Wii HD recourse pack for a good comparison.

The only thing to note here is that within a resource pack, there should be a "textures" folder that contains another folder that matches the GameID. Anything inside the GameID folder, hierarchy should not matter.

Code:

resource-pack.zip
\__ manifest.json
\__ logo.png (optional)
\__ textures (Directory)
   \__ GAMEID (Directory)
       \___ TEXTURES GO HERE

Since you mentioned textures that do not load (I am assuming PNG), this could be because of any of the reasons mentioned above (color depth, indexed image, etc). This can be fixed by just doing a straight conversion of PNG to PNG using this script. All PNG images will be rewritten using only 24/32-bit RGB/RGBA. The resulting images should all work in Dolphin, and those can be ran through OptiPNG (using this tool) to "safely" reduce file size as much as possible, while still retaining the ability to load in Dolphin.

---

(07-29-2019, 09:17 AM)Kirbeast Wrote: Well I re downloaded and installed the program without changing the Tool Master Path, and OptiPNG is actually working! Maybe it is also because I used 7zip to unzip the ctt-ps_programs_installer.exe, who knows, I'm just glad its working now. My recourse pack was missing the game id folder... I remember seeing it there, but I'm glad I could figure it out with you help!!
Thank you!

Looks like we were replying around the same time. Glad you got it working the way you intended. I don't think there should be an issue with manually unzipping the EXE (its just an SFX RAR archive), I didn't add any special parameters to it but who knows.

[Kirbeast]

(07-29-2019, 09:22 AM)Bighead Wrote: Looks like we were replying around the same time. Glad you got it working the way you intended. I don't think there should be an issue with manually unzipping the EXE (its just an SFX RAR archive), I didn't add any special parameters to it but who knows.

Thanks for all your help, I really appreciate it! Your tool has been really helpful for me 

[Bighead]

To reduce my own spam, I consolidated these two posts which only cover development with no actual downloads.

Part 1 - 08-07-2019, 10:22 PM: (Show Spoiler)

Following up on the Zelda64 backgrounds. Part 1 is to make it so textures can be overlapped when combined. To figure out what to do, first I looked for an emerging pattern on what needs to be overlapped and how. Luckily one shot out immediately. No matter how many tiles there are in a set, there are only 4 possibilities of what pixels will be overlapped (or more literally, cropped out).

Spoiler: (Show Spoiler)

Along with a way to overlap pixels, a few new options have been added as well.

Spoiler: (Show Spoiler)

Grid Array: The number of columns and rows in total.
Inner Pixel Overlap: The number of pixels that overlap between textures.
Button Ratio: Allows configuring the shape of the button for a square or different rectangles.
Output Name: The name of the combined texture. No longer needs (.png) to be added.

When a texture is assembled and combined, a CTT file is created. This is nothing new.

Spoiler: (Show Spoiler)

It does now however hold more information. The path on line 1 hasn't been used in a long time, but now points to where the segments were originally located. There are also other values such as the rows, columns, overlap, the button ratio, and it can now be loaded into "Combine" operation as well as "Split". It also holds the dimensions of the tiles, which is pulled from the first tile. If tiles are uneven, this could be a problem, but that situation should not exist. These dimensions will be used in the near future in the "Split" option to calculate the new pixel overlap when splitting. I'll explain this more in part 2 in probably a few days.

Spoiler: (Show Spoiler)

The image must be built at least once to create a CTT file. If loading the CTT file in the "Combine" operation, it will now fully assemble the texture on the "Select Textures" window. It could even be possible to share a CTT file or create your own if you know the texture order. If the path to the textures has changed on Line 1, the CTT file can also be dropped into the same folder as the textures and loaded from there, and it will find all the textures in that folder.

Spoiler: (Show Spoiler)

There are a few more quality of life features I'd like to add eventually, but those can come later after I get the core features down. This part is about done and working as intended. Setting the pixel overlap to "1" creates the dimensions we expect.

Spoiler: (Show Spoiler)

That's it for now, I'll update again once I get the "Split" operation updated. No point in a test version or beta at the moment as I've unified a lot of things between combine and split operations, so "split" is in a badly broken state (but primed for the changes).

Part 2 - 08-09-2019, 01:59 PM : (Show Spoiler)

Part 2 is the "Split" operation. I thought this would be trickier than the "Combine" operation, but it was actually much easier. Creating/importing the CTT file was probably the bulk of the overall work.

The CTT file is now in its final form. It should now hold enough information to derive any other values that may be needed.

Spoiler: (Show Spoiler)

Code:

Line 1: The last known path to the segments.
Line 2: The base dimensions of the segments.
Line 3: The number of columns.
Line 4: The number of rows.
Line 5: The base amount of overlap pixels.
Line 6: The button style when combining.
Line 7: The name of the combined texture.
Line 8+: The list of texture segments.

Not much on the GUI has changed, but a new option "Insert Overlap Pixels" was added.

Spoiler: (Show Spoiler)

This option duplicates the edge pixels between textures when splitting to simulate the overlap. Splitting an upscaled texture while duplicating overlap pixels will only work properly if the original texture was combined with the duplicate pixels overlapped. The value entered should match the upscale value of the combined texture multiplied by the number of overlap pixels set when combining. Using a wall from the market box as an example....

Code:

Segment Size   : 64x32
Combined Size  : 256x256   / With Overlap : 253x249  
Upscaled Size  : 1024x1024 / With Overlap : 1012x996
Upscale Value  : 4
Inner Overlap  : 1
Insert Overlap : 4 * 1 = 4

The Upscale Value / Insert Overlap Pixels isn't stored in the CTT file because I have no idea what the user will choose for an upscale value. But, this value will be automatically calculated when importing a CTT file. This is where storing the "Inner Pixel Overlap" and dimensions of the original segments comes in handy (I mentioned I'd explain more in part 2). If overlap pixels were defined when combining the texture, the original combined dimensions are calculated:

calculated width = base width * cols - (cols * overlap) + overlap
calculated height = base height * rows - (rows * overlap) + overlap

The formula above should properly calculate the original size of the combined texture if the textures were overlapped when combined. If the actual dimensions of the texture to be split is greater than the calculated dimensions, it is assumed it was upscaled with an integer factor. The actual width is divided by the calculated width, multiplied by the "Inner Pixel Overlap", which is how I determine the value for the "Insert Overlap Pixels" setting.

If not importing a CTT file, "Insert Overlap Pixels" should be manually set to the upscaling value * Inner Pixel Overlap. Since Zelda64 skybox textures only have 1 pixel of overlap, "Insert Overlap Pixels" should always just equal the upscale value used. But if there is a different game that uses 2 pixels of overlap between textures for example, and the upscale value used was 4, then overlap pixels should be 4 * 2 = 8.

So to see it in action, first I combined a section of the background using 1 for "Inner Pixel Overlap". This creates an image of size 253x249. I then upscaled this background using waifu2x. The result isn't fantastic, but I only need it to test. The resulting dimensions are: 1012x996.

Spoiler: (Show Spoiler)

Simply replacing the combined texture with the upscaled one allows the CTT file to load it. If all went well, the "Insert Overlap Pixels" should match the upscale value of "4".  The advantage of using a CTT file is that when textures are split, they are automatically renamed with their original names. If not using a CTT file, they will have to be manually renamed.

Spoiler: (Show Spoiler)

Because pixels are being duplicated to simulate the overlap, the dimensions of the new segments should match the dimensions of the original segments (64x32) multiplied by the upscale factor (4) so the size ends up what we would expect (256x128) instead of something weird.

Spoiler: (Show Spoiler)

So to wrap it up, the whole point of this was to automate combining and splitting textures that have duplicate pixels between them and overlap these duplicate pixels in-game. When combining, the duplicate pixels are cropped out before combining the textures. When splitting, duplicate pixels are recreated in the necessary positions. Zelda:OoT skybox textures overlaps a single column/row of pixels at their native resolution. Any increase in resolution increases the amount of overlap pixels equal to (overlap pixels * upscale factor). When the overlap is properly accounted for, there are no visible seams in-game.

Spoiler: (Show Spoiler)

So while this eliminates almost all of the headache when it comes to the overlap, the tedious task of assembling the texture is still required, and building it in the grid is almost as cumbersome as doing it in an image editor (if not more so). It helps to have a texture map which can alleviate some of the pain, which can easily be done using the watermark option, free look camera, and some screenshots.

Spoiler: (Show Spoiler)

I still have a few more things I want to do before putting out a test version. I'd like to make it so its possible to move the images around on the grid after importing them, so they could be nudged around like a sliding puzzle. There's also a few other minor issues and kinks that need worked out, but for the most part its fully functional and should make doing these backgrounds much much simpler. Shouldn't be too much longer 'til then.