Why all the negativity in the comments here? Yes, sometimes it is extremely valuable to make a nice thin wrapper on existing tech. As a community, we can't always complain about the user interface of FOSS tools, and then when someone makes a UI, again complain that they haven't done anything or the size is large. Pick a side!
More feature rich UIs already exist as thin wrappers for this tech. Some linked from the Real-ESRGAN github repo. More importantly, Google Colab notebooks exist already as well, so you don't even need a graphics card.
People are allowed to question what aspect of this project this is novel. I believe it's a fair critique when many tools already exist. A criticism doesn't imply a negative connotation.
I personally appreciate the before/after comparison demo aspect of this tool. However, I value the ability to modify parameters and models more than a before and after comparison tool.
I see parameters/models are on the road map but I personally believe it should be part of a 1.0 release.
The only reason why I built Upscayl was because there were no GUI solutions for Linux. Everywhere you see, Windows Windows Windows. Which is great for Windows people, but you already have Topaz Gigapixel, arguably the best piece of paid software I've ever seen.
I wanted something similar for Linux. After receiving "No, I don't think so" as a reply for my question about Image upscaler GUIs for Linux on r/opensource, I decided to build one of my own. I hope the GUI can benefit other people.
Maybe ask yourself why people chose to use Electron. The cross platform alternatives (Tauri[1] pops to mind) generally offer a more complex development experience. As long as web languages remain the lowest entrypoint they will remain the dominent force, even if they're less performant.
You're absolutely right. I tried building Upscayl with Tauri initially, but after a few days I had to give up because I was trading my time for bundle size. Then I tried Neutralino only to discover that it does not support node runtime. With Electron, we were able to focus on the core features and ship Upscayl very fast.
Since electron is also the only framework that supports node modules, it was pretty much the best low-resistance path for us at the moment.
I do wanna learn Rust eventually but that is an adventure for another day :)
You deserve credit for this tool. I used it on a 35mm slide taken in 1982 that was scanned using a Nikon SUPER COOLSCAN 9000 ED. The original image was around 4000x3000 pixels. I ran it through and resized it back down and it's impressively better.
The binary at 160MB ran flawlessly on a HP Dev One laptop with Debian sid and processed the image in about 10 minutes. The difference is remarkable.
You have done a brilliant job of getting a simple front end on top of a huge pile of complicated under the hood by doing the smart thing: using your time efficiently so you can focus on the hard parts of the puzzle.
If Rust is too much of an adventure, maybe you'll find Go easier. Wails [1] is great if perhaps a bit more rough round the edges. Because it's go, package sizes are 10mb+ but nothing like Electron 30mb+
As someone venturing in Tauri as primarily a web dev, I can relate to this so much. Rust is great and Tauri has some stellar benefits, but until you really master the borrow mechanics, it slows you down so much.
?? how is tauri a response to electron criticism? Imho the main criticism of electron is a criticism of using a webview for a desktop application where you could've used something far more simple. An alternative which would make electron critics be happy would be more like imgui or bindings to plateform native ui toolkits, but definitely not some other html ui framework.
Oh you're right. I was thinking Tauri was a cross-platform native UI kit. Imgui seems interesting but given it requires C++ knowledge that introduces all sorts of lifecycle issues regarding memory safety, etc, which makes it even more intimidating to newer SWEs.
ImGui does have a bunch of wrappers in different languages. [1]
That said, native-ish interface would feel better IMO. I always appreciate applications that “feel native”. Qt and Python's Toga [2] are a couple libraries that pop up in my mind.
Just an aside as we all get Old Fat and Ugly, its actually a good thing to have such a simple reminder to grep for shit out of your egress just so you stay close to whats happening on the wire.
I haven't thought about TCPDUMP in a long time, and I appreciate this man page.
It must be because of the auto-update checker. It's a useful feature that lets us notify users about new versions and also let them download and install without opening the Github repository.
It's the electron-builder that's doing it, must be its default configuration. I'll see if I can fix the continuous checks and limit it to only at launch.
I actually tried, couldn't do it. Some version of numpy in their requirements.txt doesn't build with the Python on the my system.
Sure, I could probably install another Python with conda, but it's not my idea of fun. The app here actually worked fine from the first try, without taking gigabytes of disk space.
I followed the instructions in their README, they suggest conda, but don't tell you to use it.
My GPU isn't even CUDA-capable, but the previous version of Upscayl worked fine, possibly on the CPU. That might have changed, I don't know.
In any case, even with conda installing everything would have been a pain to someone not really accustomed to the Python ecosystem. I don't care too much about the GUI, but a working AppImage is really nice.
What GPU do you have? The Upscayl README says in big letters:
"NOTE: Upscayl does not work without a GPU, sorry. You'll need a Vulkan compatible GPU to upscale images. CPU or iGPU won't work."
Sure, perhaps a previous version may have worked without a GPU, but this seems surprising given that it uses a GPU-only library for all the heavy lifting.
I do machine learning and use Python a lot, and even then I'd sometimes prefer something packaged like this. Dependencies are Python's hell and I can't usually know in advance if a repo will be a 1-minute install or a 15-minute install.
Scaling is broken on Real-ESRGAN. That's why I had to remove the option for 2x and 3x and tiling can sometimes yield totally unexpected results. These 2 are the primary reasons why Upscayl doesn't show them.
It's honestly a relief. I do not have MacOS so I had to compile the software with a MacOS VM without hardware passthrough, it took me a whole day to set that up. I wasn't able to test it on the VM (because of lacking hardware acceleration) but some nice people from the community helped us test it and find bugs and issues for the Mac builds :)
I like video2x[1] for this, a nice simple CLI with lots of different options for different cases, (especially the anime upscalers) used it quite a bit, also played with realcugan-ncnn-vulkan[2] which has given me pretty great results.
Would it be too difficult to add video upscaling feature to this? It'd really help with old videos.
I have videos I took on my Sony Ericsson w810i in the 2000s. The joy of being able to capture something animated on a small screen... I remember it used to show what song is playing at the top and I thought "cool, it shows banners similar to what we see at the bottom of news channels"! Would be great to elevate those videos to today's standards.
I really wanted an open source project to be on par with a commercial/paid software but realistically speaking, the difference is day and night and Topaz wins hands down in my cases.
I tried Real-ESRGAN but it seems to dream up slightly too much? Has anyone else had this problem? It tends to generate details where there shouldn't be any.
This is commonly called 'hallucination' and is a confound in super resolution. Its particularly concerning when people throw SISR at medical imaging ...
It really does need a GPU. Tried it on a laptop with integrated graphics and it crashed completely. Didn't even give a BSOD, machine just went dead and rebooted.
We're making sure Real-ESRGAN reaches people who cannot use CLIs (so that pretty much includes 99% of the population). Also, I have a PR in the making for their ncnn-conversion script, it ain't much but it's honestly the best I can contribute when it comes to Python and AI.
Real-ESRGAN creator also encourages others to use their tech in their projects, as mentioned in their readme.
I know we're not really enhancing Real-ESRGAN's code at the moment, but we don't want to disrespect or disregard their hardwork either.
The binaries themselves result in 10-25 megabytes. Along with that we ship multiple models currently.
I'm not sure if around 300mb would be considered 'bloat' for an AI Image Upscaler. People who have low end hardware unfortunately cannot use the application anyway.
% du -h /Applications/Upscayl.app/Contents/Resources/models
76M /Applications/Upscayl.app/Contents/Resources/models
76MB of models
/ % ls -lah /Applications/Upscayl.app/Contents/Resources/models
total 155920
drwxr-xr-x@ 14 simon admin 448B Aug 27 04:44 .
drwxr-xr-x@ 62 simon admin 1.9K Aug 27 04:44 ..
-rw-r--r--@ 1 simon admin 32M Aug 27 04:44 df2k.bin
-rw-r--r--@ 1 simon admin 113K Aug 27 04:44 df2k.param
-rw-r--r--@ 1 simon admin 1.2M Aug 27 04:44 realesr-animevideov3-x2.bin
-rw-r--r--@ 1 simon admin 3.1K Aug 27 04:44 realesr-animevideov3-x2.param
-rw-r--r--@ 1 simon admin 1.2M Aug 27 04:44 realesr-animevideov3-x3.bin
-rw-r--r--@ 1 simon admin 3.1K Aug 27 04:44 realesr-animevideov3-x3.param
-rw-r--r--@ 1 simon admin 1.2M Aug 27 04:44 realesr-animevideov3-x4.bin
-rw-r--r--@ 1 simon admin 3.0K Aug 27 04:44 realesr-animevideov3-x4.param
-rw-r--r--@ 1 simon admin 8.5M Aug 27 04:44 realesrgan-x4plus-anime.bin
-rw-r--r--@ 1 simon admin 30K Aug 27 04:44 realesrgan-x4plus-anime.param
-rw-r--r--@ 1 simon admin 32M Aug 27 04:44 realesrgan-x4plus.bin
-rw-r--r--@ 1 simon admin 113K Aug 27 04:44 realesrgan-x4plus.param
I could probably save some size by removing the models that we aren't using but we eventually are going to use them in the next build so that's one of the stupid reasons I didn't remove it (probably should have).
Electron is definitely heavy but it's also the only framework that ships with node runtime, so it was the best option for us at the moment.