Page 4 of 12

Port Cube

Posted: Thu Aug 18, 2022 11:05 am
by Rocky
Your error? You don't need to convert from RGB after DGCube. If DGCube receives YUV420P16 then it outputs YUV420P16. Why are you adding that conversion? What are you trying to do with it?

Can support 4:4:4 at the correct moment.

Port Cube

Posted: Thu Aug 18, 2022 12:07 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 11:05 am
If DGCube receives YUV420P16 then it outputs YUV420P16.
Ok, now I understand. We just need the support for limited range cubes from Warner too.

Port Cube

Posted: Thu Aug 18, 2022 12:26 pm
by Rocky
I can do that but how do you know that the cube is limited range? In general, how would I know? And can you give me such a cube please?

It will be a bit complicated though as I will need different YUV <--> RGB matrices, etc. So I need to be sure about what you claim about limited range cubes.

Port Cube

Posted: Thu Aug 18, 2022 12:38 pm
by Guest 2
Mmm... there is something wrong: https://krakenfiles.com/view/qqjYIXbecL/file.html

The script is:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
LoadPlugin("D:\Eseguibili\Media\DgCube\DGCube.dll")
DGSource("F:\In\2_0446 Akira\akira.dgi",ct=48,cb=48,cl=0,cr=0, rw=1920, rh=1032)
propClearAll()
CompTest(1)
DGCube("D:\Programmi\Media\AviSynth+\cube\1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=false)
Prefetch(6)

x265.exe --crf 20 --preset slow --output-depth 10 --aq-mode 5 --fades --colorprim bt2020 --colormatrix bt2020nc --transfer arib-std-b67 --range limited --min-luma 64 --max-luma 940 --output "F:\In\2_0446 Akira\akira_dgcube_6_temp\akira_dgcube_6_out.hevc" "F:\In\2_0446 Akira\akira_dgcube_6_temp\akira_dgcube_6.avs"

Original from Akira 4K PQ.

Port Cube

Posted: Thu Aug 18, 2022 12:48 pm
by Rocky
Please describe the problem in words. And I need your cube file when you report an issue.

You should not set fullrange=false for that script. Other than that, unless you tell me the problem...

Also, the cube specification allows to have limited ranges. The code already supports it.

Port Cube

Posted: Thu Aug 18, 2022 12:54 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 12:48 pm
Just tell me what the problem is!
The image is corrupted, it seems two layered ones. Just look from 00:03 on.
Rocky wrote:
Thu Aug 18, 2022 12:48 pm
You should not set fullrange=false for that script.
I do not understand what the proper use is for fullrange. I thought that with a limited range in and a limited range out, it should be false.
Rocky wrote:
Thu Aug 18, 2022 12:48 pm
Also, the cube specification allows to have limited ranges. The code already supports it.
How to tell DGCube what kind of LUT are we providing?

Port Cube

Posted: Thu Aug 18, 2022 1:03 pm
by Rocky
fullrange should be left alone for YUV. It's only relevant for RGB. I posted about it above.

You don't need to tell DGCube about the LUT. It parses what it needs from the cube file. The cube file can specify limited "domains", aka ranges. Code's already there for it. Whether it's working right, we'll see. If not, we'll fix it. Slow and steady wins the race.

As always I need: source stream, cube file, description of problem and how to make it happen.

Let's determine the typical use cases/work flows and get them working one by one.

Port Cube

Posted: Thu Aug 18, 2022 1:06 pm
by Guest 2
Output before last build (external color space conversion):
correct.png
Output with last build (internal color space conversion):
wrong.png

Port Cube

Posted: Thu Aug 18, 2022 1:18 pm
by Rocky
Try without the prefetch. I can tell you more when I can duplicate it.

Port Cube

Posted: Thu Aug 18, 2022 1:20 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 1:18 pm
Try without the prefetch.
No difference at all.

Port Cube

Posted: Thu Aug 18, 2022 1:24 pm
by Rocky
That stuff is present in the source file I downloaded. Shows up without DGCube. Also see it just playing it in MPC-HC and DGIndexNV. Was that stream the source or your encode? I need the clean source.

EDIT: It must be your encode because it is resized. Please provide the corresponding source stream. Thank you.

Port Cube

Posted: Thu Aug 18, 2022 1:41 pm
by Rocky
Also, just open the script in VirtualDub2 to eliminate the encode. I've tested various PQ streams with a cube like yours and everything is fine.

Port Cube

Posted: Thu Aug 18, 2022 1:49 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 1:24 pm
That stuff is present in the source file
That is the encoded one.
Rocky wrote:
Thu Aug 18, 2022 1:24 pm
It must be your encode because it is resized.
I resized to make it faster.
Rocky wrote:
Thu Aug 18, 2022 1:24 pm
Please provide the corresponding source stream. Thank you.
Here https://krakenfiles.com/view/0VcYGMVjg5/file.html

Port Cube

Posted: Thu Aug 18, 2022 1:49 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 1:41 pm
Also, just open the script in VirtualDub2 to eliminate the encode. I've tested various PQ streams with a cube like yours and everything is fine.
What nvidia driver are you using?

Port Cube

Posted: Thu Aug 18, 2022 1:52 pm
by Rocky
Thank you.

3090 516.93

Investigating with source file...

Port Cube

Posted: Thu Aug 18, 2022 2:01 pm
by Rocky
OK, duplicated it. That is weird. I cannot even think how it could do that. Investigating...

Port Cube

Posted: Thu Aug 18, 2022 2:03 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 2:01 pm
OK, duplicated it.
You have to believe me. Except when I'm distracted. :mrgreen:

Port Cube

Posted: Thu Aug 18, 2022 2:12 pm
by Rocky
Ha ha, seems only the left half of the frame is corrupted.

Port Cube

Posted: Thu Aug 18, 2022 2:30 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 2:12 pm
Ha ha, seems only the left half of the frame is corrupted.
With a superimposed copy of the right half.

Port Cube

Posted: Thu Aug 18, 2022 2:37 pm
by Rocky
Re-download and try again. Should be gooder.

This could explain some issues I was having with MakeWritable() etc.

OK, back to the range issues. The cube similar to yours does not have a limited domain. But your cube file name implies that it expects limited input and limited output. So I need to give you a way to not automatically map to full. I propose:

1. Allow to specify limited to full or not on input.
2. Honor the LUT's domain if specified.
3. Allow to specify full to limited or not on output.

Would that cover everything? In your case you would ask for no limited to full on input and no full to limited on output. The output would still be limited, but only because it came out of the LUT that way.

Port Cube

Posted: Thu Aug 18, 2022 2:59 pm
by Rocky
Guest 2 wrote:
Thu Aug 18, 2022 2:03 pm
You have to believe me.
Because you're DG Approved and I'm not. :cry:

Port Cube

Posted: Thu Aug 18, 2022 3:04 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 2:37 pm
Re-download and try again. Should be gooder.
Will try and report. :salute:
Rocky wrote:
Thu Aug 18, 2022 2:37 pm
I propose
Yes, that is the smartest way. Perhaps you could write a small exe to show us the properties of the lut, so we can check format, if it specifies its domain and in that case show what.

Port Cube

Posted: Thu Aug 18, 2022 3:05 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 2:59 pm
Because you're DG Approved and I'm not. :cry:
:ugeek:

Port Cube

Posted: Thu Aug 18, 2022 3:24 pm
by Guest 2
Rocky wrote:
Thu Aug 18, 2022 2:37 pm
Should be gooder.
Tested and working.

Port Cube

Posted: Thu Aug 18, 2022 10:32 pm
by Rocky
Guest 2 wrote:
Thu Aug 18, 2022 3:04 pm
Perhaps you could write a small exe to show us the properties of the lut, so we can check format, if it specifies its domain and in that case show what.
That's a pretty great idea. Did you think of it yourself? Could make an info overlay for the filter, like show=true and all that nonsense.

All this confusion for nothing. You can't make an in-place filter with subsampled chroma formats. I'll do better, I promise.