Port Cube

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
User avatar
Baltasar
Posts: 60
Joined: Tue Nov 02, 2021 9:51 am

Port Cube

Post by Baltasar »

User avatar
Boris
Posts: 92
Joined: Sun Nov 10, 2019 2:55 pm

Port Cube

Post by Boris »

Ha ha. Cancel this:

DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Fri Sep 02, 2022 7:44 pm
You did that because you think it's appropriate for HLG?
AVSResize uses matrix_coefficients : transfer_characteristics : color_primaries. The LUT changes the transfer characteristics from st2084 to std-b67, as per HLG standards. I am not so into that to understand it fully but someone more expert than me told me to do so. :)

The most common conversion from PQ is to "SDR", followed by HLG. As multiple broadcast service are trasmitting HDR using HLG, perhaps it''s better to support that format too.
Rocky wrote:
Fri Sep 02, 2022 7:44 pm
unless I implement the whole of z to accommodate any conversion you want
Sometime in time. :)
Rocky wrote:
Fri Sep 02, 2022 7:44 pm
Anyway, let me investigate some more.
Thank you!
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Any news for us? :D
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Just taking a little break to get all my swim coaching certs renewed. Hope to get back to it in a day or two.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Wed Sep 07, 2022 10:51 am
Just taking a little break to get all my swim coaching certs renewed.
I ❤️ acquatic sports. Currently I am swimming, having sort of water crossfit and diving.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Wed Sep 07, 2022 7:26 pm
Well duh, you're a frog!
Unfortunately, I can't breath underwater. How I wish!
Rocky wrote:
Wed Sep 07, 2022 7:26 pm
Or should I say frogstyle?
:D
User avatar
Curly
Posts: 712
Joined: Sun Mar 15, 2020 11:05 am

Port Cube

Post by Curly »

I have an important point to make. Trust me.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Haven't forgotten about this or given up, guys. Couple things going on. First, Sherman asked me to look into a tuner issue with his 38-12 radio while he and DG are on a Wayback Machine trip searching for Jimi Hendrix. Apparently, Jimi is an elusive and ethereal spirit. They've been gone longer than expected. Getting a little concerned TBH. Anyway, it turned out to be not so simple a problem and you all know that we don't give up on problems. So been spending a lot of time trying to figure out why the local oscillator is running too slow. But I have a theory and a plan so it may be over soon. 200Vdc shocks are not so bad, but preferably not across the heart and sustained. They sure do get your attention.

Second, I need to write a filter to show pixel values at a point x/y. For example, I want to compare pixels for internal versus external at any point in the script, plan being to see where in the process the discrepancy arises or becomes unacceptably large. Knowledge is power.

Patience is a virtue and all that.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Tue Sep 13, 2022 7:41 pm
Patience is a virtue and all that.
Trees that are slow to grow bear the best fruit.

In the mean time, don't get electrocuted.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Guest 2 wrote:
Wed Sep 14, 2022 1:35 am
Trees that are slow to grow bear the best fruit.
So true.

I found out why the oscillator was running slow. The oscillator coil was replaced in the past and it has the wrong inductance to match the tuning condenser. I patched in a P-C70-OSC universal oscillator coil and it brought everything back where it should be. I'll cobble up a mounting for it and get it installed. That will complete the electrical restoration. I'll leave final reassembly into the cabinet for Sherman to do when (if?) he comes back.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Started coding the pixel view filter...
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Sat Sep 17, 2022 4:04 pm
Started coding the pixel view filter...
:salute:
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

PixelView() working for YUV420P16. Now coding RGBP16...
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

RGBP16 is working. Tomorrow we can start hunting down discrepancies.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

@Guest 2

Please advise which version of avsresize.dll you are using.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Tue Sep 20, 2022 7:41 am
Please advise which version of avsresize.dll you are using.
r19 https://forum.doom9.org/showthread.php? ... ost1973326
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Very good. Thank you.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Alright. To kick things off, let's establish the playing field. Our source clip will be the Akira clip posted by Guest 2. We will be using the following scripts:

internal:

DGSource("A4kira-015.dgi")
DGCube("1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", in="lim", lut="full", out="lim")

external:

DGSource("A4kira-015.dgi")
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full")
DGCube("1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", in="full", lut="full", out="full")
z_ConvertFormat(pixel_type="YUV420P16", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited")

DGSource() and DGCube are the latest. avsresize.dll is version r19. I removed dithering in the external script and the resample parameter.

We will be tracking the pixel at x=1900/y=750 of frame 0. This a skin tone on the neck below the guy's ear.

The first finding will be in my next post with subsequent ones to follow.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Finding #1: Comparison after conversion of input YUV420P16 to RGBP16.

Pixel value after DGSource(): Y=26048, U=30592, V=34624 # same for both scripts

Pixel value after external conversion: R = 28788, G = 24857, B = 20991

Pixel value after internal conversion: R = 28760, G = 24833, B = 20961

The percent discrepancies are: R = 0.097%, G 0.096%, B = 0.143%

So we are talking about a tenth of a percent discrepancy for the input conversion to RGB. While this appears inconsequential, let's come back to determining reasons for discrepancies after we determine the discrepancies for each stage.

Next up is to compare after the LUT application. After that is to compare after the output conversion back to YUV420P16.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Finding #2: Comparison after application of LUT.

Pixel value after external application: R = 33663, G = 24354, B = 17262

Pixel value after internal application: R = 33606, G = 24313, B = 17219

The percent discrepancies are: R = 0.17%, G 0.17%, B = 0.25%

The percent discrepancies are cumulative, that is, after all previous stages and not per-stage. At this point, we are still within a quarter of one percent.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Finding #3: Comparison after final output (adds the RGBP16->YUV420P16 stage).

Pixel value after external output: R = 26663, G = 28512, B = 37090

Pixel value after internal output: R = 26673, G = 28262, B = 37360

The percent discrepancies are: R = 0.04%, G 0.88%, B = 0.73%

The percent discrepancies are cumulative, that is, after all previous stages and not per-stage. At final output, we are still less than one percent.

It's clear that the biggest discrepancy is introduced at the final stage, so we will focus on the reasons for that first.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Port Cube

Post by Guest 2 »

Rocky wrote:
Thu Sep 22, 2022 6:51 am
It's clear that the biggest discrepancy is introduced at the final stage, so we will focus on the reasons for that first.
Are you testing PQ to HLG or PQ to SDR internal conversion?
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Finding #4: Change the final external conversion stage from:

z_ConvertFormat(pixel_type="YUV420P16", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited")

to:

z_ConvertFormat(pixel_type="YUV420P16", colorspace_op="rgb:st2084:2020:full=>2020:st2084:2020:limited")

Interestingly, this does not alter the final pixel values! One might suppose it changes only metadata, but this is an Avisynth script delivering only raw pixels, so any metadata must be in frame properties. I'll check those next.
User avatar
Rocky
Posts: 3555
Joined: Fri Sep 06, 2019 12:57 pm

Port Cube

Post by Rocky »

Guest 2 wrote:
Thu Sep 22, 2022 7:03 am
Are you testing PQ to HLG or PQ to SDR internal conversion?
PQ to HLG. The scripts were given here:

https://www.rationalqm.us/board/viewtop ... 394#p16394

You were supposed to post if you didn't like my choice of playing field. ;)
Post Reply