RealSR-NCNN-Android: seven native modules, one APK, and a build link stuck at 1.11.1

Seven native modules sit behind the photo screen

RealSR-NCNN-Android ships as a single Android package that fronts several native programs, and the repository keeps those programs as separate source trees. Three projects sit at the top level. RealSR-NCNN-Android-CLI builds console binaries you can drive from Termux, and it contains 7 modules: Anime4k, MNN-SR, RealSR, RealCUGAN, SRMD, Waifu2x and Resize. RealSR-NCNN-Android-GUI builds the APK, working as a shell around those CLI programs rather than a second implementation. Resize-CLI is a third thing, a demo like Resize-NCNN-Android-CLI that needs no ncnn at all and builds with Visual Studio.

Format handling splits along the module list rather than along a settings screen. The RealSR program loads realsr models and real-esrgan models in ncnn format, while MNN-SR takes mnn format files, a second runtime added later so the app could reach model families ncnn cannot hold. Everything else rides on the ncnn toolchain the desktop projects share, which is why the packaged assets carry their own ncnn shared library instead of borrowing one from the phone.

Two ways to pick a file, two ways to run it

Driving the app comes down to two decisions: where the image comes from, and who runs the work. Pictures arrive either by sharing one or more of them from another app such as Gallery, or by tapping `Select Image` inside the app and choosing from storage. Execution then runs down one of two paths. Choose a model, press the Run button, and the photo view fills with the result once the program finishes; if you like what you see, the Save button writes it out. Or type a shell command into the same screen and press enter, where help returns more information about that command line.

What makes this arrangement unusual is that the interface never hides the terminal. A string you would hand to a program in Termux also works inside the picture viewer, so the app doubles as a debugging surface rather than only a one-tap tool. On privacy the project is brief and concrete: the application does not collect any private information from your device.

The scale and the model family live in the folder name

For ncnn weights the app reads structure from disk instead of from a picker setting. A model directory has to carry a suffix of `models-Real-` or `models-ESRGAN-`, and the files inside follow the `x[n]` pattern, where n is the scale:

models-Real-ESRGAN-AnimeSharp  // directory should have a suffix of models-Real- or models-ESRGAN-
├─x4.bin                       // models name as x[n], n is scale
├─x4.param

Set the shipped assets against that rule and they split into two families. Real-ESRGAN groups follow it: `models-Real-ESRGAN`, `models-Real-ESRGAN-anime`, `models-Real-ESRGANv2-anime` and `models-Real-ESRGANv3-anime`, holding `x2.bin`, `x3.bin` and `x4.param` pairs wherever a variant exists. Then there are `models-nose`, `models-pro` and `models-se`, three folders that ignore the prefix rule completely and use `up2x-no-denoise.bin` or `up4x-conservative.bin` style names instead, where the up2x or up3x prefix fixes the factor and the rest of the name names the mode. So the naming contract the instructions state is narrower than the tree that ships.

Extra weights load without a rebuild. Since ver 1.7.6 the GUI scans a directory that you name in `Path for custom models (RealSR/ESRGAN/Waifu2x)`: make the directory on sdcard, paste the path, save, copy files in, and they appear in the model list. A collection of additional models is published at `https://huggingface.co/tumuyan2/realsr-models`.

MNN keeps its scale and color space in the file name

Version 1.11 added a second backend, MNN, picked because it could support more models than ncnn. Conversion happens on a desktop rather than on the phone, and the documented route is short:

pip install mnn
MNNConvert -f ONNX  --modelFile "{onnx_path}" --MNNModel "{mnn_path}"  --bizCode biz --fp16  --info  --detectSparseSpeedUp

That tool ingests TFLITE, TorchScript and Tensorflow models as well, and the flag list is spelled out on the MNN conversion page the instructions point to. Nothing lands in a sidecar config: scale and color handling travel inside the file name, which has to look like one of these.

4xabcdefg.mnn
abc-x4-def.mnn
abc_4x_def.mnn

Copy the result into your custom folder and the factor comes out of the name. Color space works the same way, since a name containing `Grayscale`, `Gray2YCbCr`, `Gray2YUV`, `YCbCr` or `YUV` makes the app apply that conversion to the output. Version 1.12 added a -c parameter as the other channel, and the instructions do not say which of the two wins when a file name and a flag disagree.

The build link stops at 1.11.1

Building the APK takes two steps. Unpack the models and ELF files, put them under the GUI assets folder, then open the project in Android Studio:

RealSR-NCNN-Android-GUI\app\src\main\assets\

That directory holds the real weight of the app. Three shared libraries travel with it, `libc++_shared.so`, `libncnn.so` and `libomp.so`, alongside a `magick` directory, a `delegates.xml`, a `colors.xml` and one folder per toolchain: `realcugan-ncnn`, `realsr-ncnn`, `resize-ncnn`, `srmd-ncnn`, `waifu2x-ncnn` and an `Anime4k` entry.

Then the trap. The link given as the direct download for the current version resolves to the 1.11.1 assets archive:

https://github.com/tumuyan/RealSR-NCNN-Android/releases/download/1.11.1/assets.zip

The newest tag is 1.13.2, published the same day as the last push on 2026-05-30, so following the instruction literally hands you an asset set from before 1.12 added the -c color switch. Anyone who wants the matching archive has to edit 1.11.1 out of that URL by hand, and the build steps never mention that the link is version specific at all.

pth to ncnn is the step you do by hand

Everything destined for a `models-Real-` or `models-ESRGAN-` directory has to arrive as an ncnn pair, and turning a trained checkpoint into that shape is manual work. The desktop route uses cupscale: unzip it on a PC, open `CupscaleData\bin\pth2ncnn`, and run `pth2ncnn.exe` against the pth file downloaded from OpenModelDB. The output still needs the rename shown earlier before the app will list it.

The stated limit is worth repeating plainly: that converter turns ESRGAN models into ncnn and does not handle Real-ESRGAN models, with the author offering to convert Real-ESRGAN checkpoints by hand instead. The alternative route runs chaiNNer, which the instructions flag as needing a good internet connection, and a ready node graph is supplied at `chainner-pth2ncnn.chn`. Drag a model onto the leftmost node, press run, and the rename step becomes unnecessary because that graph already writes the expected names. Even there the instructions concede that not every model can be converted to an ncnn model.

Two details trip up scripting. The graph is fetched from a URL naming the `main` branch while the default branch is `master`, and `pth2ncnn.exe` is a Windows binary, so the conversion path as written needs a PC running Windows.

Same weights, a different host than the desktop tools

Every neural module here descends from a desktop toolchain. Waifu2x-NCNN, SRMD-NCNN, RealCUGAN-NCNN and RealSR-NCNN are all nihui's Vulkan builds, and Real-ESRGAN is the training repository the weights come from. This project changes none of the model maths. It repackages the same `.bin` and `.param` pairs, carries the runtime inside its assets, and moves the entry point to a phone screen with a shell line underneath.

The real difference is where the work runs and what failure looks like. A desktop ncnn executable takes flags on the command line, writes an output file and prints what happened. Here the same run is wrapped in an activity: progress is a wait, the output is a photo view, and typing a command is the escape hatch for the flags the button hides. MNN is the one substantive addition on the inference side, a backend the desktop ncnn tools do not carry. Resize-CLI sits outside all of it as a way to try the classical resamplers `nearest`, `bilinear`, `bicubic`, `avir` and `lancir` with Visual Studio and no ncnn, a spelling of the Lanczos mode that the project's topic tags render as `lanczos`.

Where the phone build is the wrong answer

Several cases send you elsewhere. If you already keep a desktop ncnn executable, this app adds packaging and no new capability. If your model needs a factor the shipped sets do not carry, the filename contract offers nowhere to put it, since n comes from the name and the bundled folders stop at `up4x`. If your checkpoint is Real-ESRGAN rather than ESRGAN, neither documented converter accepts it. If you want batch throughput, the documentation describes one button press or one typed command, with no queue, no output directory setting and no per-module flags beyond the -c color switch.

Tuning for the waifu2x family is encoded in names such as `up2x-denoise3x` and `up3x-no-denoise`, so choosing between them means picking a file rather than passing arguments, and no switch is documented for overriding that from the command line. The most recent push to master landed on 2026-05-30, which is the date to keep in mind when weighing claims about newer model families arriving here.

Editorial conclusion

Adopt the APK if you want waifu2x or Real-ESRGAN weights on a phone without a desktop detour, and leave it alone if you already run ncnn from a terminal or need a scale the bundled folders do not carry. Verify two things first: that the assets you unpacked match the app you are running, since the documented link stops at 1.11.1 while tag 1.13.2 is newer, and that your own model folder carries a models-Real- or models-ESRGAN- suffix, because the picker ignores anything else. Type help inside the app before you commit a folder, so you see which module actually accepts the model you converted.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. tumuyan/RealSR-NCNN-Android on GitHub