Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th February 2014, 19:10   #23941  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
madTPG Static Vs Dynamic Report:

i1 Display Pro, HCFR (continues measurement), 30% Grey Field from the AVS709HD, OD32 Static/Dynamic, Real 8-bit (no FRC) 4:4:4 AMVA display.
In 8-6 bit there is no deviation down to the thousand number (0.00X), no difference here.

Only in 5-bit and down I start to see the effect on the i1d3 (which might reflect what's happening beyond the thousandths decimal).
With Dynamic the meter jumps ±50K in Temperature (XYZ changing).
With Static the meter is more consistent.
From this test I can conclude that Static gives a more stable results, without the meter being confused (this is in 5-bit and lower).

Dynamic does not improve the measurement precision for i1D3 from what I've seen, just the opposite.
If the lower bitdepth tests reflect what can happen at precision beyond thousandths (8-bit), then Static is the way to go.

Unlike our eyes,
The i1D3 meter likes a stable picture (not the smoother one) without noise in lower bitdepth, and probably in high bitdepth too, but HCFR show only down to thousandths.

Static it is.


Disclaimer:
I'm not THE JUDGE, here or anywhere...
This whole post is IMO & experience only.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 27th February 2014 at 19:26.
James Freeman is offline   Reply With Quote
Old 27th February 2014, 19:43   #23942  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by aufkrawall View Post
Yes, this avoids dropped frames (but I think I still had presentation glitches with my GTX 670, will test this as soon as the Radeon is sent back).
But somehow also setting default debanding strength from low to high (same level like strength during fade in/outs) solves frame drops.
Isn't this very odd? The drops occur btw. during fade in/outs.
Yes, I'm having sporadic presentation glitches with the Geforce. Happens both with either "don't rerender frames when fade in/out is detected" enabled and default debanding strength at high.
aufkrawall is offline   Reply With Quote
Old 27th February 2014, 19:55   #23943  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
Quote:
Originally Posted by James Freeman View Post
Only in 5-bit and down I start to see the effect on the i1d3 (which might reflect what's happening beyond the thousandths decimal).
With Dynamic the meter jumps ±50K in Temperature (XYZ changing).
With Static the meter is more consistent.
From this test I can conclude that Static gives a more stable results, without the meter being confused (this is in 5-bit and lower).
Do you see the same kind of deviations if you measure with Static but at a different location?
Shiandow is offline   Reply With Quote
Old 27th February 2014, 20:05   #23944  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Hello madshi!

I was tinkering around with encoding full range rgb UT Video to yuv444 h.264. And I kept getting results that looked a bit different. Tried using only ffmpeg, then using avisynth with x264. As it turns out it might be a renderer issue. Here's my source and one of my encoded files. People claimed it looks something that might be related to bt.601/bt.709 conversion.
Here's what I got:
http://screenshotcomparison.com/comparison/64616 the color always got more orangish.
Someone claimed that my encoded file looks properly so I made screenshots with Potplayer's EVR-CP where I got opposite results:
http://screenshotcomparison.com/comparison/64643
(plain EVR rendered most obviously wrong, too dark colors)

So is this a renderer bug? Or something else?
mzso is offline   Reply With Quote
Old 27th February 2014, 20:23   #23945  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Last time I tried I444 in 2012, it was working fine with madVR. Most likely something is wrong in your conversion chain.
Use Avisynth ConvertToYV24(matrix="rec709") and let x264 flag the stream corresponding.
You also need a splitter like LAV that doesn't ignore the flags.
aufkrawall is offline   Reply With Quote
Old 27th February 2014, 20:24   #23946  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by Shiandow View Post
Do you see the same kind of deviations if you measure with Static but at a different location?
With certain shades of grey and lower bit depth.
Though, I don't think the i1D3 is made for heavy patterned textures, I think it expects more uniform texture.

I've done some more testing,
It appears that the i1D3 is very sensitive and fast reacting to change.
The brighter the test image gets the faster the i1D3 reacts, so a highly dynamic image is definitely bad.

The difference is minor at higher bit depths, but to eliminate any chance of error I suggest Static.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 27th February 2014 at 20:37.
James Freeman is offline   Reply With Quote
Old 27th February 2014, 20:36   #23947  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by aufkrawall View Post
Last time I tried I444 in 2012, it was working fine with madVR. Most likely something is wrong in your conversion chain.
Use Avisynth ConvertToYV24(matrix="rec709") and let x264 flag the stream corresponding.
You also need a splitter like LAV that doesn't ignore the flags.
Doesn't seem too likely at this point. Unless avysinth and ffmpeg fail the same way.
Did that. Used PC.709 instead, because wanted to keep full range too. Yet the results remained the same.

You could check. I shared the source file and an encode.
mzso is offline   Reply With Quote
Old 27th February 2014, 20:49   #23948  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by James Freeman View Post
HCFR show only down to thousandths.
Unless something has changed, HCFR stores the XYZ & RGB values with millionths accuracy (6 decimal places).

Set the display mode to XYZ or RGB, highlight all cells (click upper left cell), open Edit menu -> copy, and then paste into a text editor.
cyberbeing is offline   Reply With Quote
Old 27th February 2014, 20:49   #23949  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
I'm not sure if it's a bug, or just something that's being magnified by viewing in 3-bit, but I've been doing some comparisons and images seem to have a slight green tint to them when using Ordered Dither and colored noise.
This does not seem to be a problem with the error diffusion builds.
6233638 is offline   Reply With Quote
Old 27th February 2014, 20:54   #23950  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by mzso View Post
Doesn't seem too likely at this point. Unless avysinth and ffmpeg fail the same way.
Did that. Used PC.709 instead, because wanted to keep full range too. Yet the results remained the same.

You could check. I shared the source file and an encode.
I'd have to set up Avisynth etc. Got no time for this, sry.
Just flag the file as bt.601. Most likely then the orange tint will go away. Clear sign for a wrong colormatrix conversion.
aufkrawall is offline   Reply With Quote
Old 27th February 2014, 20:57   #23951  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by cyberbeing View Post
Unless something has changed, HCFR stores the XYZ & RGB values with millionths accuracy (6 decimal places).
Thanks,
But I don't think we should go deeper into it.

Its simple really,
The faster the sensor is, the more stable the displayed texture should be to minimize "capturing the wrong moment", to minimize the error possibility.
IMO 8-bit Static does it best.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 27th February 2014 at 21:03.
James Freeman is offline   Reply With Quote
Old 27th February 2014, 21:00   #23952  |  Link
GREG1292
Registered User
 
Join Date: Aug 2007
Location: Fort Wayn,Indiana
Posts: 52
It can but acts like depth adjuster
8bit loses the pop I guess. Tested on several movies. Maybe I'm seeing things but my kids confirmed it. Really any setting looks good just some better than others.


Sent from my iPhone using Tapatalk
__________________
2011 VDC 9500LC ULTRA Mike Parker Modded 12-3-2015
GTX-770 and Intel Xeon V1235
Windows 10
GREG1292 is offline   Reply With Quote
Old 27th February 2014, 21:09   #23953  |  Link
Mangix
Audiophile
 
Join Date: Oct 2006
Posts: 353
well this sucks...

I've been playing around with the madVR settings and have noticed that on my monitor, I cannot see a difference between 7 and 8 bits with dithering off. Dithering only makes a visual difference at 6-bit and below. Does this mean that my monitor is dithering internally? If so, is there any point in using madVR's dithering algorithms on this monitor? I can't see a difference between any of them at 7-bits(even None).
Mangix is offline   Reply With Quote
Old 27th February 2014, 21:09   #23954  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by aufkrawall View Post
I'd have to set up Avisynth etc. Got no time for this, sry.
Just flag the file as bt.601. Most likely then the orange tint will go away. Clear sign for a wrong colormatrix conversion.
I just managed to make a snapshot with MPV's opengl-hq renderer: http://screenshotcomparison.com/comparison/64648

The color differences don't happen here. Only encoding artifacts. So... I don't know...
mzso is offline   Reply With Quote
Old 27th February 2014, 21:13   #23955  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Just gave it a quick try with Avisynth+ & MeGUI.
Original FRAPS RGB:


x264 I444:


No problem with MPC, LAV & madVR.
aufkrawall is offline   Reply With Quote
Old 27th February 2014, 21:14   #23956  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
Quote:
Originally Posted by James Freeman View Post
Its simple really,
The faster the sensor is, the more stable the displayed texture should be to minimize "capturing the wrong moment", to minimize the error possibility.
IMO 8-bit Static does it best.
I don't exactly see why that probability would be larger with Dynamic rather than Static. It's just that in one case it depends only on the location and in the other also on the time. If your sensor is fast enough then (in theory) the best thing to do would be to take multiple measurements using Dynamic, from this you can calculate both the average value and the variance. If you use static then you've only got a very bad approximation of the average value.
Shiandow is offline   Reply With Quote
Old 27th February 2014, 21:17   #23957  |  Link
DarkSpace
Registered User
 
Join Date: Oct 2011
Posts: 204
Quote:
Originally Posted by mzso View Post
Doesn't seem too likely at this point. Unless avysinth and ffmpeg fail the same way.
Did that. Used PC.709 instead, because wanted to keep full range too. Yet the results remained the same.

You could check. I shared the source file and an encode.
Flag the bitstream. Your encoded sample may or may not be PC.709 YUV, but madVR doesn't know that. Therefore, it has to guess the range (for me, it guessed PC range), and it will also guess the color matrix (for me, it guessed BT.709). Apparently, for you, it didn't do that, so you should flag the bitstream (you should always do that, actually). In x264, the options are --input-range, --range and --colormatrix (I don't know about ffmpeg, but it's probably something similar). Also, of course, make sure that you don't convert the color matrix and flag the original matrix!
original | your encode (the frames don't match precisely, but that's because I'm too lazy to deal with your strange encode at whatever fps when the original file had 30 fps)
DarkSpace is offline   Reply With Quote
Old 27th February 2014, 21:18   #23958  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by Mangix View Post
well this sucks...
I can't see a difference between any of them at 7-bits(even None).
If you are watching a movie (which is already dithered by the studios), then everything is fine.
Relax, I can't either, Most people can't.

Undithered smooth test patterns are a whole different story.

Quote:
Originally Posted by Shiandow
I don't exactly see why that probability would be larger with Dynamic rather than Static. It's just that in one case it depends only on the location and in the other also on the time. If your sensor is fast enough then (in theory) the best thing to do would be to take multiple measurements using Dynamic, from this you can calculate both the average value and the variance. If you use static then you've only got a very bad approximation of the average value.
Sounds logical.
Maybe you're right.

You are very welcome to try to test and come to a conclusion.
If what you posted is indeed the case, I'll be using Dynamic.

We still don't know if ArgyllCMS takes several reads from the same patch and averages them.

But,
I wan't to see real results, because I'm really beginning to get tired of assumptions and placebo (my own included).
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 27th February 2014 at 21:30.
James Freeman is offline   Reply With Quote
Old 27th February 2014, 21:27   #23959  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 447
Quote:
Originally Posted by Mangix View Post
I've been playing around with the madVR settings and have noticed that on my monitor, I cannot see a difference between 7 and 8 bits with dithering off. Dithering only makes a visual difference at 6-bit and below.
If you can only see a difference starting from 6-bits, then I would say your monitor is not only 6-bit but isn't doing any (temporal) dithering of its own. In that case, you should actually get more benefit out of madVR's dithering, so long as you set it to 6-bit mode so it actually affects the image you see. Of course, you might want to make sure there there's actually no difference at all - get up close to the screen on a still image and see if you can see a pattern in the pixels (it's easiest in dark areas). If you can, then dithering is working as expected, even if you don't notice it normally. If you can't see any effect at all then yes, you'll need to use a lower base bitdepth.
Ver Greeneyes is offline   Reply With Quote
Old 27th February 2014, 21:33   #23960  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Ver Greeneyes,
I think its important to know if Mangix is using a test pattern or a movie before assuming his monitor is 6-bit.

I too can hardly see the difference between 7 & 8 bit (None) with bluray content which is already properly dithered.
6-bit with Dithering, looks so good that I can use it without noticing the difference if its 8-bit or not.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 27th February 2014 at 21:43.
James Freeman is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.