search

HolyWu / vs-dpir

DPIR function for VapourSynth
MIT License
32 stars 3 forks source link

Random black specks on output compared to original DPIR #11

Closed khang06 closed 2 years ago

khang06 commented 2 years ago

I can't give a better explanation than the title, so the issue can be clearly seen in this comparison. The other image in the comparison is the standalone DPIR, and the issue only happens with task='deblock'. task='denoise' works fine.

HolyWu commented 2 years ago

Please provide an unprocessed sample for investigation.

khang06 commented 2 years ago

https://cdn.discordapp.com/attachments/872690735152005200/891585644076363826/01_3144.png

HolyWu commented 2 years ago

I cannot reproduce that artifacts. What strength did you set? Are you using the latest v1.5? Does v1.4 or v1.3 have the same issue?

HolyWu commented 2 years ago

Is it also reproducible for you if you use this 01_3144.png as source rather than use the original video file as source?

khang06 commented 2 years ago

Nope, using that image doesn't actually work. However, it was figured out that doing YUV420P8 -> RGBS artifacted while YUV420P8 -> RGB24 -> RGBS didn't. A test video file can be found here and it was used with the following script:

rgb = jp.resize.Spline36(format=vs.RGBS)
deblock = DPIR(rgb, strength=12, task='deblock')

EDIT: The issue is solved by clamping the pixel values between 0 and 1

NSQY commented 2 years ago

Hi, I have a much more extreme example: https://slow.pics/c/inY0pC4F To my knowledge this has been an issue since at least 11/08/2021, using cuda.

Confirmed that clamping before DPIR fixes the issue.

HolyWu commented 2 years ago

Good finding. I'll explicitly clamp the pixel value for 'deblock' task then.

LightArrowsEXE commented 2 years ago

This issue seems to still persist.

from vsutil import depth
import lvsfunc as lvf

src = depth(src, 16).std.Limiter(16 << 8, [235 << 8, 240 << 8], [0, 1, 2])
debl = lvf.deblock.vsdpir(src, matrix=1, cuda=True)  # Simple vsdpir wrapper. default: debl strength=25

src.set_output(0) (with frameprops) image

debl.set_output(1) (with frameprops) image

As you can see here, it still creates those weird dots. image image

It seems that even if the input is limited, the output may enter illegal ranges. I'm not at all sure what the cause behind this could be.

EDIT: Here's the clean frame image

EDIT2: Converting to RGB24 first seems to work, but I was under the impression this was fixed?

HolyWu commented 2 years ago

I cannot reproduce it using the clean frame png even though I intentionally convert it to YUV420P16 first. Could you provide an unprocessed one-frame y4m since the png was already converted to RGB24?

LightArrowsEXE commented 2 years ago

Sorry, it seems I tried installing it from pypi so fast when the commits for 1.6.0 were pushed that it hadn't even updated there yet and I didn't realise. My bad!