Thursday, October 17, 2013


Made to batch re-size and convert images for Steam grid.
Latest Update : Version 2.0c:
Changed a couple things here and there and added some options.
Changes :
There is now a mode displayed in the console so people know what options are being used.
There are now two quality options (highspeed/highquality) highspeed is used by defualt.
There is now a way to specify the number of threads to use. Specifying 0 will behave the same way as not specifying one at all.
A usage message is added for people who run the application normally.
Download :
Usage: Drag images or folders containing images on the executable.
If you would like to benchmark add "-bench" without quotes to the file name.
If you would like to use high quality mode add "-q" without quotes to the file name.
If you would like to specify number of threads to use add "-thread=" followed by the number of threads you want to use (no spaces, without quotes) to the end of the file name.
You can use multiple modes at the same time.

Because most of this was from an old application and uses most of .Net built in stuff I will provide the source:

== OLD == Benchmark done by Pbanj:
2.0b HighSpeed CPU utilization

2.0b HighSpeed

2.0b HighQuality

Download : Update : Its fucked up, here is a fixed version: Download : Reason : I was using an old project to make this one, and I decided to change the output format to Jpeg from Png, but I forgot to change the extensions from .png to .jpeg. I am sorry for any inconveniences. Update : Here is another update I was told that the images were pixelated and I knew what was causing it. Microsoft's built in Jpeg compressor in .NET is shitty, and so to remedy that I simply made it output PNG. Another thing that is changed is I removed the ending popup message because apparently Pbanj thought it was annoying. Download : Requested : Pbanj requested that I implement multi-threading to this. And so I might do just that, just to speed up batch processing. For single image processing there will be no speed improvements. Updates : Here is SteamGridImager1.0c and the first version of SteamGridImager2.0. Download 1.0c : Changes : Added folder support, if you have too many images to process put them into a folder and drag the folder onto SteamGridImager1.0c.exe, all images in the folder and sub-folders will be processed. Also added a benchmark feature for people who want to see stats, simply add "-benchmark" (without quotes) to the end of the executable file name.  Download 2.0 : Info : This is 2.0 because it was more or less a rewrite of the first version. This version is an attempt to implement multi-threading. Minimal testing was done so performance increases may vary. Also to note I do not know best practices of multi-threading to make optimized multi-threaded apps yet, the only thing I'm certain of is there is a performance gain and that it works lol. Further optimization of the app will probably not come as unless you are processing thousands of files its not going to make that big of a difference. Supports everything 1.0c supports feature wise. Benchmarks : Here are the two version processing 100 images = Version 1.0c
Version 2.0
Here are the two versions processing 2000 images = Version 1.0c
Version 2.0
As you can see the multi-threading does provide some performance gain (at least on my system) but quite little (probably due to my lack of knowledge on multi-threading). Welp take it or leave it lol. On second thought : I will try later to implement multi-threading another way and see if that yields better performance. Welp here is the other way I've implemented Multi-threading, its better I guess but again not by much lol. Features and usage is the same. Download 2.0a : Difference explained : 2.0 has a list of all the images and each thread can grab a new one as soon as its finished with the current one its working with. Each time a thread grabs an entry, that entry is removed from the list so other threads don't process that image a second time. 2.0a gives each thread its own list of images to work with. It works non-stop until it finishes. There is no waiting like 2.0 does. In 2.0 all the threads are grabbing from one source so there needed to be some form of management. If multiple threads try to access the list at the same time, all but one thread is put on hold until that one thread is finished with the list, basically the other threads need to wait in line until they get the information needed to work on the next image. Another factory that might be making my tests seem like multi-threading isn't gaining much might be a HDD bottleneck. 2.0a benchmark with the same test from earlier. 100 images:
2000 images:
CPU Utilization:
Testing done by Pbanj: 1.0c

No comments: