xinntao / Real-ESRGAN

Real-ESRGAN aims at developing Practical Algorithms for General Image/Video Restoration.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Question] About --tile and denoise

shirooo39 opened this issue · comments

I noticed that by using --tile, could help with the GPU running out of memory.
is there any siginificant difference in quality? I mainly only do anime images with the anime model.
or the results are the same, it's just that using --tile splits up the image into multiple chunks? so that it'd be easier for the gpu to process...

my other question is, can Real-ESRGAN do denoise? (remove jpeg artifacts)
I see on the source code that there's an option to output result into png.
if I use ext png, will it also denoise? as I noticed when saving as the same extension as source (jpg) there are jpeg artifacts.

Hello,
For me, I have GTX 1050ti (4GB), which is a low GPU memory, and I solve it via downscaling the image output and with --tile size (256 or 128).
The command would be like:
python inference_realesrgan.py --model_path experiments/pretrained_models/RealESRGAN_x4plus_anime_6B.pth --input inputs --tile 256 --outscale 2

normally the --outscale parameter should be 2 or 4 as default (6 is much too hight)

Hello, For me, I have GTX 1050ti (4GB), which is a low GPU memory, and I solve it via downscaling the image output and with --tile size (256 or 128). The command would be like: python inference_realesrgan.py --model_path experiments/pretrained_models/RealESRGAN_x4plus_anime_6B.pth --input inputs --tile 256 --outscale 2

normally the --outscale parameter should be 2 or 4 as default (6 is much too hight)

I'm sorry to say, but your reply doesn't answer my questions in any way.
I do know what commands to use, as I've written my own implementation of Real-ESRGAN onto my Colab notebook (which you could check in HERE)

what I need to know: is there any significant differences in quality, if I split the image into multiple chunks (by using the --tile flag) compared to doing it in a whole big chunk altogether. I also want to know whether or not Real-ESRGAN could do de-noise (rmeove jpeg artifacts) or not.

If there is enough overlap between the tiles (I've not looked at the used algorithm thoroughly enough to confirm that in this case), there should be no visible impact from tiling.

Using my own tiling algorithm, I've found that the overlap should be at least 48 pixels to eliminate seams.

Regarding the JPEG artifacts. Real-ESRGAN does remove them quite effectively. Of course, saving the result as JPEG will introduce new artifacts.

If there is enough overlap between the tiles (I've not looked at the used algorithm thoroughly enough to confirm that in this case), there should be no visible impact from tiling.

Using my own tiling algorithm, I've found that the overlap should be at least 48 pixels to eliminate seams.

Regarding the JPEG artifacts. Real-ESRGAN does remove them quite effectively. Of course, saving the result as JPEG will introduce new artifacts.

thank you for your answer!

is it safe to always use --tile 256 / 512? because it's useful to avoid the gpu running out of memory, when processing large images.

You'd be the best judge for that.
Using the same input, tile once at your maximum tile size, then half of it. Compare the results.

If there is enough overlap between the tiles (I've not looked at the used algorithm thoroughly enough to confirm that in this case), there should be no visible impact from tiling.

Using my own tiling algorithm, I've found that the overlap should be at least 48 pixels to eliminate seams.

Regarding the JPEG artifacts. Real-ESRGAN does remove them quite effectively. Of course, saving the result as JPEG will introduce new artifacts.

Any chance that your solution skips loading the image to GPU before tiling? My issue is that the pre_process function in utils.py, lines 55,56 loads the entire image to GPU before processing it, therefore rendering the entire tileSize flag pointless since it will break with a CUDA OOM error before even preprocessing to tiles...