Esrgan + model manga109 today best, this can be used. https://imgur.com/gallery/OWOKLG0
Custom Texture Tool PS v52.5
|
03-10-2019, 07:50 PM
I spent quite a bit of time into the resource pack manager with the last version, my thinking is that they are probably the future of Dolphin texture packs going forward. I know they now support compression which currently my script can not do. The PR states (zlib/DEFLATE), but I am not versed in this compression type. If anyone can point me in the right direction to learn more, I'd be interested in adding support for whatever is needed.
Aside from that, I am done with the resource pack stuff. I am currently in the process of adding support for both ESRGAN and SFTGAN since the process of setting them up and running them is similar for both of them. Because they can be rather difficult to set up, I will include an auto-installer that downloads, installs, and updates everything required. I also want it to be possible to change the model (.pth) and the processor (CUDA vs. CPU). The painful part about this is it requires editing the scripts directly, and I noticed they are also picky about the paths you run commands from. I have no idea of an ETA, but maybe within a few days it should be ready for testing. 03-11-2019, 03:38 AM
The textures I'm putting in as PNG keep coming out much darker when converted to dds.
Using bc7 through compressionator. Some textures come out ok, others don't. 03-11-2019, 05:41 AM
Can you send me one of the PNGs that comes out darker?
03-11-2019, 03:52 PM
I remember this issue. I used to have a work-around in place long ago, but it was a very demanding work around as it essentially means generating every image twice to avoid a rare situation.
A few things here. It's most likely not Compressonator that is creating darker images, it is more likely that it is TexConv. My guess is that Compressonator is failing to create the images for whatever reason, so the script is falling back to TexConv. This can be verified by enabling the PS console (Options >> Debug >> Show the PS Console). Doing a 1:1:1 conversion from PNG > BC7 > PNG, guaranteeing that I'm using only Compressonator for all conversions, the images have the correct color. Performing the same steps with TexConv, the darker image is created. But if I open your PNG in GIMP, and just simply overwrite it, then do the same conversion as above, the color is correct. Now I'm not that educated in color space, so I'm just going to throw out assumptions. My guess is that the PNG is using linear colorspace or an sRGB profile that TexConv does not like, so when converted to DDS some information is lost. Just simply opening them in Paint, GIMP, or ImageMagick and saving them should rewrite the image with a profile that does work. There is a work-around that is easy to do. - Convert all textures from PNG to PNG using the script. ImageMagick will write the new PNGs. - Verify that the new PNG textures look exactly like the old ones (no color lost). - Replace the PNG textures with the new ones - back up the old just in case. - Convert those to DDS and see if the issue persists. I am curious though as I would like to know more, what program are you using to edit these images (GIMP, PSD, Paint.Net,___)? And what settings are used when exporting the images?
You see that's the weird part.
All these textures are sourced from the devs of the game. They're either the high textures used for rendering, or the textures ripped from Xbox. For the textures I sourced from the devs, they're that with the alpha channel stripped (Alpha controls reflective maps in metal arms, and if you incorporate them into the dds, the texture get all screwy) and converted to png. If I remember right, I used img magic to do that. As for the Xbox textures. Same scenario but dds. Those however are ripped from the mst file that holds assets. Ripped using amPerls MAtools on github. I used the same process. At the time planned on staying as png, but it's starting to cause game lag, and bc7 looks good but performance doesn't take a hit. Oh and to edit I use Photoshop, but those textures are untouched by Photoshop. So \(0∆0)/ 03-12-2019, 03:08 PM
I doubt there is anything actually wrong with the images, I think the problem somehow lies with TexConv doing... something with images it doesn't like. To my understanding converting an image with linear color space to one with sRGB can result in the image becoming darker (or lighter?) because the gamma does not correlate 1:1. Now I know almost nothing about how gamma correction works, but I think this somewhat illustrates it:
The thing is I'm not actually telling Compressonator or TexConv to perform any such conversions, but Compressonator gets it right and TexConv gets it wrong. I just send TexConv the PNG as is, and tell it to create type "DXGI_FORMAT_BC7_UNORM". I'm fairly sure most PNGs are using an sRGB profile already, but don't quote me on that because I'm probably wrong. There is a DDS sRGB equivalent identified as DXGI_FORMAT_BC7_UNORM_SRGB but I don't make use of it. Reason one, I never knew enough about color spaces to make proper use of it, and reason two is that whenever I did try to make use of it, images came out... different than their PNG counterparts (darker or lighter). My thinking was that if one day someone came along and questioned why the ability to create sRGB DDS is not there, and offered an explanation as to why its needed, I'd plug in an option somewhere. But that never happened, and I still don't understand the need for it, so as of now the only way to create them would be to edit the script and change the format internally. But I don't think any of this chatter is even relevant to your situation. If you simply want the images to be "correct", I'm pretty sure you can just regenerate the PNGs before converting to DDS. Someday I'm going to have to learn more about gamma correction, linear vs. sRGB, etc.
I have a test version ready for ESRGAN/SFTGAN.
http://www.mediafire.com/file/dkec4ti1aw...0.0.b1.zip As far as I can tell, ESRGAN works fine, but SFTGAN is failing on a lot of images and I can't exactly figure out why. I'll go more into that later, but first I want to explain the set up process. IF YOU HAVE NOTHING REQUIRED INSTALLED This is how to set everything up the easy way: Go to Options >> Operations Tab >> Automatic Setup button on the ESRGAN/SFTGAN section. There are 6 steps, just make your way through them and follow them closely. IF YOU HAVE EVERYTHING REQUIRED INSTALLED If you already have Python, Cuda, and the filters already up and running, you can simply link them to the script on the "Tool Paths" menu. If Python v3.6 is already installed, it should pull the install path from the registry. AFTER EVERYTHING IS SET UP If the models don't show up after adding them, and you are sure all the paths are correct, close the options menu and reopen them and they should appear in the lists. After everything has been set up, ESRGAN and SFTGAN should appear in the upscaling filters list. CURRENT ISSUES ESRGAN works fine, but I am having issues with SFTGAN. I learned most of everything from this blog post here. It was mentioned that SFTGAN requires upscaling the image 4x before running it, but when I attempt this, I get an error in the segmentation test that makes the whole thing break down. The segmentation test is required. SFTGAN requires running 2 scripts: the segmentation test, and then the SFTGAN test. The segmentation test breaks the image down into multiple images, then the SFTGAN test does the magic. Unfortunately, something is failing on the segmentation test when I upscale images, and often when I don't. I won't have time to try to figure this out for a few days, so hopefully someone who has experience with SFTGAN can point me in the right direction. The code that prepares SFTGAN can be found on line 2100. On lines 2113 and 2114 is where the upscaling takes place, simply changing the upscale factor for width and height to 1x (for example, $RawImageData.Width * 1) makes many images work, but they don't get upscaled so it defeats the purpose... Spoiler: Spoiler: Another issue is that the progress bars don't fill all the way up during the automatic installation. I have no idea why, but it does not affect the installation in any way. |
« Next Oldest | Next Newest »
|
Users browsing this thread: 5 Guest(s)