View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000424madVRbugpublic2016-07-30 23:422018-01-14 18:30
Reporterhuhn Assigned Tomadshi  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Platformx64OSwindows 10OS Version14366
Summary0000424: reconstruct and other chroma scaler are adding very visible artefatcs when a 3d LUT is used
Descriptionthis problem is pretty huge and complicated but easy to reproduce.

sample 3d lut nv12 frame and a screenshoot created with reconstruct sharp without a 3D LUT: http://www.file-upload.net/download-11810700/3dlut.7z.html
Steps To Reproduceload 1 frame CC.mkv
use reconstruct sharp for chroma scaling
load/set absolut 2.4 gamma.3dlut as a 3D LUT.
Additional Informationmost chroma scaler are showing artifacts. but reconstruct sharp and bicubic 150 are very terrible. there are some artifacts without the 3D LUT too.
maybe these are two bugs and the 3D lut is just highlighting these issue.

the 3D LUT isn't triggering this bug if a screenshoot created using reconstruct sharp is used as a source and than altered with a 3D LUT.

screens:

"fine" reconstruct sharp: https://abload.de/img/reconstructsharplna79.png
"broken" reconstruct sharp + 3D LUT: https://abload.de/img/3dlut2kyxh.png

"fine" screenshoot+ 3D LUT: https://abload.de/img/rgbimage3dlut36lbi.png

i don't see how my 3D LUT itself could be the cause here.
TagsNo tags attached.
madVR Version90.22
Media Player (with version info)mpc-hc 1.7.10 x64
Splitter (with version info)lavfilter 68.1
Decoder (with version info)lavfilter 68.1
DecodingSoftware
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerNVidia
GPU Model960
GPU Driver Version369.00

Activities

madshi

2016-08-10 18:32

administrator   ~0001424

My best guess is that the chroma scalers produce some out-of-gamut colors, which then have Red, Green or Blue values which lie outside of the valid 16-235 range. Your 3dlut might not handle these cases very well.

Making a screenshot pretty much cuts off BTB/WTW, because a screenshot is always stretched to black 0 and white 255.

Possible solutions:

1) Try to create a better 3dlut which handles BTB/WTW values better.
2) Use a custom pixel shader which cuts off BTB/WTW.

huhn

2016-08-10 21:51

reporter   ~0001425

Last edited: 2016-08-10 22:27

 the 3D LUT is a TV RGB (CLIP WTW) 3D LUT.

don't forget that the issue is visible without a 3D LUT but it is very very minimal compared with a 3D LUT.

i don't have a clue what should be changed in the 3D LUT creation. it was done with newest dispalCAL 0000001:0000002 week ago.

i can try to create a 3D LUT without WTW clipping but that doesn't make sense to me.
but it is an easy task to do. i will try to check that next weekend.

edit: i tried pre and post resize:
16-235 -> 0-255 [SD][HD]
255 -> 16-235
the problem was still there.

madshi

2016-08-10 22:10

administrator   ~0001426

Try a custom pixel shader with something like "return clamp(tex2D(sampler, tex), 16.0/255.0, 235.0/255.0);" to clip BTB/WTW. Does that fix the problem?

huhn

2016-08-10 22:45

reporter   ~0001427

sorry i don't have a clue about shaders. i get : C:\Program Files\MPC-HC\Shaders\clipping shader.hlsl(1,1): error X3000: syntax error: unexpected token 'return'

madshi

2016-08-10 22:54

administrator   ~0001428

Well, you need a bit of frame around that line of code. This should work:

sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
  return clamp(tex2D(s0, tex), 16.0/255.0, 235.0/255.0);
}

huhn

2016-08-10 23:13

reporter   ~0001429

the brightness is dropping a lot but on the first view all 3D LUT related issues are gone.

the brown cross is still damaged by reconstruct but it has some strange are artefacts in the first place:
https://abload.de/img/reconstructfixc7bsl.png

i ask fhoech about this. a WTW clipping 3D LUT or a 3D LUT in general shouldn't do that.

madshi

2016-08-11 00:51

administrator   ~0001430

Oh, I forgot that custom pixel shaders run in PC levels and not TV levels. Change the clamp to "0.0, 1.0" instead of "16.0/255.0, 235.0/255.0", that should take care of the brightness drop. Does that still fix the issue? If so, the 3dlut BTB/WTW handling is definitely the cause of the issue.

huhn

2016-08-11 09:17

reporter   ~0001432

with "0.0, 1.0" the 3D LUT related issue is gone.
so it is clearly the 3d LUT.

madshi

2016-08-11 10:24

administrator   ~0001433

Good to hear, then we can close this issue?

huhn

2016-08-16 14:40

reporter   ~0001443

i don't known. looks like argyllcms 3D LUTs in general shouldn't be feed with out of gamut colors:
[QUOTE=fhoech][QUOTE=huhn]could you have a look at this issue:
[url]http://bugs.madshi.net/view.php?id=424[/url]

this is a problem with out of gamut colors created by chroma scaler and the 3D LUT can't deal with this properly.

the 3D LUT is a TV RGB 16-235 (CLIP WTW) 3D LUT.

log: [url]http://www.file-upload.net/download-11839782/madVR2016-07-2010-120.3127x0.329ySXYZLUT.7z.html[/url][/QUOTE]
Hi, you'll have to explain what the issue is, the bug report is not clear to me at all. Also note that code values 0 and 255 in digital video are reserved for sync, and should thus be passed through by a 3D LUT unchanged (and this is what the Argyll LUTs do, not sure if it is related). If the chroma scaler creates values in that range, it probably needs to be changed to leave sync untouched.[/QUOTE]


but i guess this can be closed there is nothing more for me to add about this problem.

i don't known if you are right now interested in the other chroma scaler artefacts.

madshi

2016-08-16 14:46

administrator   ~0001444

What other artifacts to you mean?

huhn

2016-08-16 15:11

reporter   ~0001445

the image host has a 502 bad gateway. so i have to make new ones later today.

they are the "same" artefacts seen with the 3D LUT but a lot weaker.
reconstruct sharp and bicubic 150 (not an important chroma scaler i know) are showing them and maybe more.

madshi

2016-08-16 15:18

administrator   ~0001446

Those are probably ringing artifacts.

huhn

2016-08-16 22:28

reporter   ~0001447

reconstruct sharp and or sharp AR doesn't show any difference.
reconstruct sharp: https://abload.de/img/reconstructsharp81sb2.png
spline3 AR: https://abload.de/img/spline3arwqs46.png

it gets amplified when scaled to UHD.
cropped UHD screens i used super xBR 100 to scale them to UHD.
reconstruct sharp: https://abload.de/img/croppedreconstructshaxxsao.png
spline3 AR: https://abload.de/img/croppedspline3ar4cska.png

madshi

2018-01-14 17:04

administrator   ~0002052

Sorry for the very late reply.

Hmmmm... Which artifacts do you mean in the cropped UHD screens exactly? I can see a faint blue line on the left side of those brown squares. Is that what you mean? If so, that looks like ringing to me. I'm not sure if there's anything I can do about it.

FWIW, I'm planning to replace recontruct with my own NGU based algorithm in the future, which hopefully won't have such artifacts. reconstruct is not my algo, so it's hard for me to fix problems with it.

huhn

2018-01-14 17:44

reporter   ~0002063

when i look at them i see a red tint in the white lines between the squares with reconstruct. sorry it has been a while.

which is i guess the same artefact as the 3d LUT one just a lot less notable.

"the 3D LUT isn't triggering this bug if a screenshoot created using reconstruct sharp is used as a source and than altered with a 3D LUT."

taking this old comment into account this issue may just come from processing images in limited range without BTB WTW clipping.

madshi

2018-01-14 17:53

administrator   ~0002066

I've looked at both images with a pixel peeper. I can see the red tint, but it's in both images. For some reason, to the human eye it seems stronger in the "reconstruct" image, but the pixel peeper doesn't lie. It says:

FFEBE8 vs FFEAE6

Which means RGB (255, 235, 232) vs (255, 234, 230). So both images have the Red subpixel fully maxed out while Green and Blue are not maxed out, which results in the red tint. The red tint is ever so slightly deeper in the reconstruct image, but technically, it's only a very small difference.

huhn

2018-01-14 18:04

reporter   ~0002067

well i don't know what to say about this. it looks quite different on left part.
which is mostly notice thanks to the 3D LUT issue.

madshi

2018-01-14 18:18

administrator   ~0002071

Well, it looks somewhat more reddish to me, too (although I didn't originally notice it at all, until you pointed it out to me), but the actual RGB numbers don't differ much.

In any case, I don't really want to spend much time debugging "reconstruct" issues, it's not "my" algorithm, and I think it would be wiser to spend the time on a better replacement instead in the future, no?

huhn

2018-01-14 18:24

reporter   ~0002073

after all this time i just wonder if this comes from WTW/BTB numbers.it doesn't seem to happen if the image isn't scaler afterwards.

but fine to me to leave it at this.

madshi

2018-01-14 18:30

administrator   ~0002075

It could have to do with WTW/BTB and "reconstruct" might make things worse somehow. Could also be ringing, or a combination of WTW/BTB + ringing. In any case, if the issue still exists once I've implemented the NGU based successor to "reconstruct", we can revisit the issue then. So I'll close this one for now.

Issue History

Date Modified Username Field Change
2016-07-30 23:42 huhn New Issue
2016-08-10 18:32 madshi Note Added: 0001424
2016-08-10 21:51 huhn Note Added: 0001425
2016-08-10 22:10 madshi Note Added: 0001426
2016-08-10 22:27 huhn Note Edited: 0001425
2016-08-10 22:45 huhn Note Added: 0001427
2016-08-10 22:54 madshi Note Added: 0001428
2016-08-10 23:13 huhn Note Added: 0001429
2016-08-11 00:51 madshi Note Added: 0001430
2016-08-11 09:17 huhn Note Added: 0001432
2016-08-11 10:24 madshi Note Added: 0001433
2016-08-16 14:40 huhn Note Added: 0001443
2016-08-16 14:46 madshi Note Added: 0001444
2016-08-16 15:11 huhn Note Added: 0001445
2016-08-16 15:18 madshi Note Added: 0001446
2016-08-16 22:28 huhn Note Added: 0001447
2018-01-14 17:04 madshi Note Added: 0002052
2018-01-14 17:04 madshi Assigned To => madshi
2018-01-14 17:04 madshi Status new => feedback
2018-01-14 17:44 huhn Note Added: 0002063
2018-01-14 17:44 huhn Status feedback => assigned
2018-01-14 17:53 madshi Note Added: 0002066
2018-01-14 17:53 madshi Status assigned => feedback
2018-01-14 18:04 huhn Note Added: 0002067
2018-01-14 18:04 huhn Status feedback => assigned
2018-01-14 18:18 madshi Note Added: 0002071
2018-01-14 18:18 madshi Status assigned => feedback
2018-01-14 18:24 huhn Note Added: 0002073
2018-01-14 18:24 huhn Status feedback => assigned
2018-01-14 18:30 madshi Note Added: 0002075
2018-01-14 18:30 madshi Status assigned => closed
2018-01-14 18:30 madshi Resolution open => no change required