Support forum for DG Tools

Posted: **Fri Apr 01, 2022 8:07 am**

240 -> 110? That's easy. Even Sherman could do it. He'd use a dropping resistor and burn down the house.

Posted: **Mon Apr 04, 2022 9:08 am**

Guest 2 wrote: ↑
Fri Mar 25, 2022 12:04 pm
With multiple DGI and AVS too of course.

That's the hard part. Where there's a will there's a way, they say.

Posted: **Sun Apr 17, 2022 4:08 am**

Today GitHub alerted me that NVenc from rigaya added 3D denoise filter.

I never noticed that NVenc had some functions for video manipolation and, as source is already there, it would be easy peasy to implement the various image switches without having to encode the image at all, just the ones with HW acceleration, of course!

Some new functions for DGSource/Filters would be nice.

What do you think?

Posted: **Mon Apr 18, 2022 8:33 am**

Bullwinkle wrote: ↑
Sun Apr 17, 2022 8:50 am
I went to the github but did not see a 3D denoise filter. Can you point me to it?

In the latest release: https://github.com/rigaya/NVEnc/blob/ma ... ram2value2

Posted: **Mon Apr 18, 2022 1:37 pm**

Great, thank you. It's MIT licensed so we can re-use code.

Rocky's not feeling well so I am covering for now. Don't worry, he'll be fine.

Posted: **Tue Apr 19, 2022 5:19 am**

Bullwinkle wrote: ↑
Mon Apr 18, 2022 1:37 pm
Rocky's not feeling well so I am covering for now.

Please forward my best wishes.

Posted: **Tue Apr 19, 2022 5:23 am**

Would be possible for DGSource to output the exact color bitdepth?

It's easy to correct by hand with ConvertBits, as they are all zeroes, but on automatic processing, such as with some GUIs, the excess bits can lead to more work for plugins and AVSIs.

Thanks.

Posted: **Tue Apr 19, 2022 11:41 am**

Guest 2 wrote: ↑
Tue Apr 19, 2022 5:23 am
Would be possible for DGSource to output the exact color bitdepth?

Output it how? It is already recorded in the DGI file (DEPTH). Do you want it to appear in the show=true display?

Posted: **Tue Apr 19, 2022 6:05 pm**

Bullwinkle wrote: ↑
Tue Apr 19, 2022 11:41 am
Output it how?

When indexing a HEVC (10 bits) and I feed AVS+ script with DGSource, I get:

Code: Select all

avs+ [INFO]: AviSynth+ 3.7.2 (r3661, 3.7, x86_64)
avs+ [INFO]: 1920x1080 fps 24000/1001 i420p16 frames 0 - 37767 of 37768

and not i420p10.

Perhaps I am doing something wrong, anyway.

Posted: **Tue Apr 19, 2022 6:34 pm**

Now I get you.

Two thangs:

1. NVDec returns all HBD as 16-bit, so that is what we deliver. We could call ConvertBits internally but...

2. It's actually more efficient to process 16 bit data, as no shifting and masking is needed.

You would need to demonstrate/prove that "the excess bits can lead to more work" if you want anything done.

Posted: **Tue Apr 26, 2022 10:18 am**

Thought I'd update on things that are on my plate. In no particular order:

* VFR support features.
* Episode and chapter demuxing for DGIndexNV.
* Warn container/ES frame rate mismatch with ability to choose which to use. [COMPLETED]
* DG version of BM3D.
* Adopt NVEncC filters as appropriate.
* Avisynth+ frame properties for pulldown. [COMPLETED for DGMPGDec, still to-do is DGDecNV]
* Support A_MS/ACM as produced by MakeMKV (and others).
* Deliver all quant values via Avisynth+ frame properties (allows for better external deblockers).
* HEVC 4:4:4 support.

Please let me know if I have neglected anything.

Posted: **Tue Apr 26, 2022 3:35 pm**

Rocky wrote: ↑
Tue Apr 26, 2022 10:18 am
Thought I'd update on things that are on my plate. In no particular order

My order would be 2 4 then everything else.

Posted: **Tue Apr 26, 2022 7:49 pm**

OK, 2 first then. Sherman can help me with it, if I can drag him away from the radio stuff. Silly boy, he bought another 48-461. Trying to corner the global market.

Posted: **Tue Apr 26, 2022 7:54 pm**

All good things come in threes, don't cha know?

Posted: **Tue Apr 26, 2022 7:56 pm**

You wait, he won't stop at three. I caught him shopping for a fourth one! And there's a chassis only unit that could be the fifth. I guess he really enjoys re-capping.

Posted: **Fri Apr 29, 2022 8:46 am**

Rocky wrote: ↑
Tue Apr 26, 2022 7:49 pm
OK, 2 first then. Sherman can help me with it, if I can drag him away from the radio stuff. Silly boy, he bought another 48-461. Trying to corner the global market.

You can start with 4, actually.

I can (with some magic powder) make MKVMerge do the dirty job for 2, in the mean while.

Au contraire, we (read I) badly need a good and fast BM3D port

Posted: **Fri Apr 29, 2022 4:33 pm**

OK, Sherman is on it.

Posted: **Fri Apr 29, 2022 5:48 pm**

Do you have any interest in CUDA Waifu2x and other neural networks?

They are really a fascinating topic to think about... something such as a next gen NEEDI3 resizer...

Posted: **Fri Apr 29, 2022 6:16 pm**

Possibly, but one thing at a time.

You can help me and Sherman by telling us of the existing BM3D filters and what you see as their shortcomings.

Posted: **Sat Apr 30, 2022 7:18 am**

I implemented a test version for pulldown flags in DGMPGDec as it was only going to take an hour or so.

http://rationalqm.us/misc/DGDecode_test.zip

It adds the following flags as per the proposed syntax:

_FO
_TFF
_RFF

I also added:

_FieldOrder -- the display field order

Probably going to change _FO to _FieldOperation to avoid confusion with field order.

Posted: **Sun May 01, 2022 4:49 pm**

Rocky wrote: ↑
Fri Apr 29, 2022 6:16 pm
You can help me and Sherman by telling us of the existing BM3D filters and what you see as their shortcomings.

Big t, nothing will happen if this doesn't get a reply.

Posted: **Tue May 03, 2022 11:47 am**

Rocky wrote: ↑
Fri Apr 29, 2022 6:16 pm
You can help me and Sherman by telling us of the existing BM3D filters and what you see as their shortcomings.

Late reply but I never get notifications, sorry.

About algorithm, you can easily go and find references on Wikipedia: https://en.wikipedia.org/wiki/Block-mat ... _filtering

AFAIK the first CUDA implementation was https://github.com/DawyD/bm3d-gpu

Then came https://github.com/WolframRhodium/VapourSynth-BM3DCUDA and, marginally, some AVS commits on https://github.com/WolframRhodium/Vapou ... indows.yml

Last release is https://github.com/WolframRhodium/Vapou ... -test8.zip

I have asked your porting because AVS+ one is limited (it supports RGB space only) and it's only marginally developed, as a side dish from the VS repo.

AVS thread is https://forum.doom9.org/showthread.php?t=183066&page=7

Posted: **Tue May 03, 2022 6:44 pm**

Got it. Thank you for the information. What color spaces are important for you?

Posted: **Wed May 04, 2022 2:37 am**

Sherman wrote: ↑
Tue May 03, 2022 6:44 pm
Got it. Thank you for the information. What color spaces are important for you?

I ain't a color space expert.

Internally it can work whatever you want, enough that precision is preserved, but I'd like that it could accept as input and provide as output the standard color spaces that both decoders and encoders can accept, without having to use external conversion. Mostly I work in 8 up to 16 bit depth but I know that someone uses floating point (32 bits) depth too.

Noticeably, I forgot to tell you the major reason of my request of native CUDA porting, i.e. the required CPU part for the temporal engine. That is where I lose most of the performance when using WolframRhodium version.

Posted: **Wed May 04, 2022 10:18 am**

OK, thank you.

Support forum for DG Tools

Feature Requests

Feature Requests

Episode indexing and demuxing

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Proper bitdepth output

Proper bitdepth output

Proper bitdepth output

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests

Feature Requests