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 14th July 2016, 23:08   #38721  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by e-t172 View Post
Have you considered widening the input range of the 3DLUT to account for all possible input values? That will probably require having a less-than-perfectly-granular 3DLUT (i.e. applying the 3DLUT will require interpolating between 3DLUT values), but that doesn't sound like a big deal - in fact, AFAIK color-managed software never use a fully specified 3DLUT like madVR does, they use something like a 64x64x64 cube and interpolate the missing points.
The widening would have to be ultra extreme to handle all possible situations. I don't think that makes much sense. The widening would dramatically increase the needed 3dlut size, or alternatively noticeably decrease 3dlut accuracy. Furthermore the widening would also dramatically slow down offline calculation, due to all the possible extremely wide out-of-gamut situations. I expect calculating such a 3dlut offline would *at least* cost multiple seconds, after heavy optimizations. Maybe minutes, without heavy optimizations. It just doesn't make sense.
madshi is offline   Reply With Quote
Old 14th July 2016, 23:28   #38722  |  Link
colinhunt
Registered User
 
Join Date: Dec 2002
Posts: 998
Quote:
Originally Posted by madshi View Post
Hmmmm... Does it work with madVR if you use DXVA copyback instead of native DXVA decoding?
No. Green screen instead of a black one.
colinhunt is offline   Reply With Quote
Old 14th July 2016, 23:34   #38723  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 568
Quote:
Originally Posted by madshi View Post
The widening would have to be ultra extreme to handle all possible situations. I don't think that makes much sense. The widening would dramatically increase the needed 3dlut size, or alternatively noticeably decrease 3dlut accuracy. Furthermore the widening would also dramatically slow down offline calculation, due to all the possible extremely wide out-of-gamut situations. I expect calculating such a 3dlut offline would *at least* cost multiple seconds, after heavy optimizations. Maybe minutes, without heavy optimizations. It just doesn't make sense.
Actually, strike my last suggestion - I just realized that you were referring to RGB values, which are indeed problematic. What about generating a 3DLUT that maps YCbCr (or ICtCp) values? That would be just as valid, and I presume that wouldn't cause any range issues since your inputs are, almost by definition, in range. 3DLUTs can be applied in any color space, and in fact can even be used to convert between color spaces (e.g. YCbCr to RGB) in addition to doing color processing. So, for example, you could have a 3DLUT that takes ICtCp values as input, applies HDR processing such as gamut mapping or gamma ramps, other/various color processing stuff, and at the same time outputs the final RGB values.

I agree that still doesn't address the issue of calculation time though. However, I would still argue that decreasing 3DLUT accuracy would be a good tradeoff for solving that problem. After all, every color-managed application does this, and they don't suffer from accuracy problems. Argyll even has a tool, profcheck, that verifies the agreement between interpolated values from an ICC profile's cLUT and the original, full-precision measured values. If you can verify that the difference is less than 1 dE, it's unlikely anyone would be able to notice the difference.
e-t172 is offline   Reply With Quote
Old 14th July 2016, 23:43   #38724  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Granted, doing it in YCbCr or ICtCp would be more reasonable. But I still think calculating the 3dlut offline would take much too long. And I don't really see the advantage right now: The math I'm using now works just fine. Except for this one specific problem, and I'm not sure right now how to solve it mathematically, either offline or online. Once I know how to solve it, it's probably possible to do it online, too. So why do it offline? It would cost many hours extra work, delay playback start, have less precision. I simply see no reason why I should do that.
madshi is offline   Reply With Quote
Old 14th July 2016, 23:55   #38725  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 568
Sure, this is all mostly speculation It's a matter of processing budget, though. Say you have an algorithm or some math formula that, given an input color X, gives you the best output color Y to map to. Say this algorithm takes 4Ás to complete for each color. There's no way to do this in realtime for every pixel of every frame, but it would only take 1 second to generate a 64x64x64 3DLUT using that algorithm.
e-t172 is offline   Reply With Quote
Old 15th July 2016, 00:04   #38726  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Ok, but GPUs are massively parallel, while CPUs are not. If the algo takes 4Ás per color per thread on the CPU, then with a quad core CPU it would actually only take 0.25 seconds to calculate a 64^3 3dlut. However, a GPU doesn't calculate just 4 colors at once, but hundreds or thousands at once (not sure how many). So even if the GPU needs 4Ás per color, because of the massive parallel calculation, the algo would still run in real time without any problems. But I'd say 4Ás on the CPU is very optimistic. It'd probably be much slower than that.
madshi is offline   Reply With Quote
Old 15th July 2016, 00:11   #38727  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by madshi View Post
We're now discussing using dE just to find a decent compromise between losing saturation vs losing luminance, while keeping the hue angle constant. That significantly simplifies the math. Although I'm still not sure how to do the math right now.
Which dE are you referring to by the way? From the ones defined on this page, CIE76 seems doable, CIE94 only with constant hue, and CIEDE2000 is just ridiculous.
Shiandow is offline   Reply With Quote
Old 15th July 2016, 00:16   #38728  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Good question. I was thinking of using either CIEDE2000 with all the hue stuff removed (which should bring it near to CIE94, I think), or straight CIE94. Alternatively, there's a dE formula available in the first google link for the search term "de color difference ipt". In any case, my plan was to stick to constant hue.
madshi is offline   Reply With Quote
Old 15th July 2016, 00:49   #38729  |  Link
Xaurus
Registered User
 
Join Date: Jun 2011
Posts: 286
Anyone else having problems with Pascal GPU (1070,1080) getting the proper P-state when using Madvr in mpc-hc or mpc-be? I can't seem to make it happen actually. I've observed this by using several programs, and GPU-z confirms the speeds are reduced.
Setting "Prefer maximum power" in the Nvidia control panel doesn't make any difference. I've tried to use DDU and reinstall the latest drivers without any effect.
Could anyone else test the built-in graphics test in GPU-z and watch the clock speeds, and then compare it to when you run a full screen video with madvr? Noticeably the RAM speed is reduced.
__________________
SETUP: Win 10, MPC-HC, LAV, MadVR
HARDWARE: Corsair 400Q | Intel Xeon E3-1260L v5 | Noctua NH-U9S | SuperMicro X11SSZ-TLN4F | Samsung 2x8GB DDR4 ECC | Samsung 850 EVO 1TB | MSI GTX 1060 | EVGA G2 750
Xaurus is offline   Reply With Quote
Old 15th July 2016, 01:09   #38730  |  Link
zoyd
Registered User
 
Join Date: Sep 2009
Posts: 43
Quote:
Originally Posted by madshi View Post
Good question. I was thinking of using either CIEDE2000 with all the hue stuff removed (which should bring it near to CIE94, I think), or straight CIE94. Alternatively, there's a dE formula available in the first google link for the search term "de color difference ipt". In any case, my plan was to stick to constant hue.
That's where I would start delL, delC components of dE94.
zoyd is offline   Reply With Quote
Old 15th July 2016, 01:11   #38731  |  Link
SpoCk0nd0pe
Registered User
 
Join Date: Jun 2015
Posts: 25
Quote:
Originally Posted by madshi View Post
But how would the display know that it's receiving frame sequential 3D instead of 2D? And how would the display know which frame is for the left eye and which for the right eye?
It does not necessarily need to know. The idea is to build two switches, one for 3d on/off, one to switch the left and right eye on the glasses.
Quote:
Originally Posted by madshi View Post
It's also not really all that simple to implement this feature. If audio and video run out of sync, I'll need to drop a frame. Usually I only drop one frame. But with frame sequential output I'd have to make sure I always drop 2 frames, so the eye order doesn't swap.
I could live with that, I usuall have no frame drops at all with Reclock.
Quote:
Originally Posted by madshi View Post
Why do you need this? Does your TV not support frame packed 3D?
I want to replace the motherboard on my TV with this:
https://hardforum.com/threads/no-lat...board.1894299/
My plan is to also build a custom shutter glasses+emitter setup to do 3d active.
SpoCk0nd0pe is offline   Reply With Quote
Old 15th July 2016, 01:20   #38732  |  Link
zaemon
Registered User
 
Join Date: Mar 2016
Posts: 27
Dumb question but is it possible to create a 3DLUT for 3D playback (with glasses?) and for HDR playback?


Sent from my iPhone using Tapatalk
zaemon is offline   Reply With Quote
Old 15th July 2016, 02:29   #38733  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 6,063
Quote:
Originally Posted by zaemon View Post
Dumb question but is it possible to create a 3DLUT for 3D playback (with glasses?) and for HDR playback?


Sent from my iPhone using Tapatalk
putting the glasses between the colorimeter and the display should do the trick.
huhn is offline   Reply With Quote
Old 15th July 2016, 03:03   #38734  |  Link
zoyd
Registered User
 
Join Date: Sep 2009
Posts: 43
Quote:
Originally Posted by huhn View Post
putting the glasses between the colorimeter and the display should do the trick.
It's easier if you first profile the meter with glasses in front to without glasses as reference, and create a correction matrix. Then you can do the 3dlut without glasses for more signal.
zoyd is offline   Reply With Quote
Old 15th July 2016, 08:10   #38735  |  Link
Sunset1982
Registered User
 
Join Date: Sep 2014
Posts: 277
Quote:
No. Green screen instead of a black one.
That's exactly what I found out when testing the RX480. Greenscreen when using madVR and LAV with DXVE Copyback. Any ideas why this is happening?
__________________
Intel i5 6600, 16 GB DDR4, AMD Vega RX56 8 GB, Windows 10 x64, Kodi DS Player 17.6, MadVR (x64), LAV Filters (x64), XySubfilter .746 (x64)
LG 4K OLED (65C8D), Denon X-4200 AVR, Dali Zensor 5.1 Set
Sunset1982 is offline   Reply With Quote
Old 15th July 2016, 09:42   #38736  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 930
What are my options if I want to use MadVR without administrator rights? Presumably there's no way to use it with MPC-HC but are there any other players that include it without having to manually register the filter file?
__________________
HTPC Hardware: Intel Celeron G530; nVidia GT 430
HTPC Software: Windows 7; MediaPortal 1.19.0; Kodi DSPlayer 17.6; LAV Filters (DXVA2); MadVR
TV Setup: LG OLED55B7V; Onkyo TX-NR515; Minix U9-H
DragonQ is offline   Reply With Quote
Old 15th July 2016, 10:04   #38737  |  Link
Uoppi
Registered User
 
Join Date: Oct 2015
Posts: 99
After updating from v0.90.20 to v0.90.21 (haven't got to try v0.90.22 yet), I started getting worse rendering times but only when scaling.

Just wondering what could be affecting the performance so much because according to the changelog, the .20 -> .21 update was almost exclusively HDR-related (which doesn't concern my usage scenario).

The get rendering times down and to avoid dropped frames, I've now downgraded from SSIM 2D to 1D in almost all of my profiles. Nvidia drivers are up to date (I have GTX 960).
Uoppi is offline   Reply With Quote
Old 15th July 2016, 10:10   #38738  |  Link
70MM
X Cinema Projectionist NZ
 
Join Date: Feb 2006
Location: Auckland NZ
Posts: 281
Image Doubling question?

Guys Ive never used image doubling but want to try.
I have the new GTX1080 card.

Is it ok to use Image Doubling with just straight 1080p content (ripped BDs)?
Im using the JVC X9000 projector but not sure how you set this up for 1080p content, 1080p > 1080p.

Can some of you offer some instructions please?

Thanks in advance...
70MM is offline   Reply With Quote
Old 15th July 2016, 10:21   #38739  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 492
Quote:
Originally Posted by Uoppi View Post
After updating from v0.90.20 to v0.90.21 (haven't got to try v0.90.22 yet), I started getting worse rendering times but only when scaling.

Just wondering what could be affecting the performance so much because according to the changelog, the .20 -> .21 update was almost exclusively HDR-related (which doesn't concern my usage scenario).

The get rendering times down and to avoid dropped frames, I've now downgraded from SSIM 2D to 1D in almost all of my profiles. Nvidia drivers are up to date (I have GTX 960).
I'm wondering if this may be what I noticed after moving from .20 ==> .22

I had to skip .21 since mixed scaling was broken for me, but moving to .22 caused a pretty big performance hit. madshi thought it might be the new rules for when scaling is active and maybe some upscaling refinements now being used... But I'm not so sure, especially now that you see a performance hit with version .21.

QB
__________________
QBhd is offline   Reply With Quote
Old 15th July 2016, 10:54   #38740  |  Link
wolfman2791
Registered User
 
wolfman2791's Avatar
 
Join Date: Jan 2014
Posts: 57
It's likely a AMD driver error that stops me from using MPC-HC x64 with madvr. x86 version works fine. The issue is OpenCL. OpenCl kernel compile failure.

Not sure it's worth finding an older driver that works. Will just keep using x86 i guess.
wolfman2791 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 08:47.


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