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 17th April 2009, 10:49   #381  |  Link
Casshern
Registered User
 
Join Date: Apr 2007
Posts: 220
Why not offer both:
1) apply settings after LUT conversion in RGB space - this is a little lossy but enough for a preview
2) if user likes what he sees, he can then use the second option to generate a corresponding lut - to have best quality without two uncessary operations

Quote:
Originally Posted by TinTime View Post
Having extra options never hurts. Well, almost never

I guess it makes more sense to have these controls in the renderer. However, there could be occasions where generating and storing a custom LUT for specific movies might be nice (e.g. the odd times when the brightness is off or something), although this would then involve manually overwriting the standard madVR LUTs and then replacing them after watching the movie. A bit of a pain.
Casshern is offline   Reply With Quote
Old 17th April 2009, 11:17   #382  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Quote:
Originally Posted by leeperry View Post
...but he said that the data Color.HCFR kept wouldn't help.

I'd like to use HCFR data somehow. I have one, and I'd like to close the loop. Digital screen correction, to match my digital room correction
Mark_A_W is offline   Reply With Quote
Old 17th April 2009, 11:24   #383  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Mark_A_W View Post
I'd like to use HCFR data somehow. I have one, and I'd like to close the loop. Digital screen correction, to match my digital room correction
well, we discussed it in the ddcc() thread, have a look!
proper gamut conversions w/ mismatched saturation % is indeed pointless.
but I've discussed it w/ several peeps on the HCFR forum, and they agree w/ yesgrey....colors w/ a saturation >75% are hardly ever used(if ever).

saturations on my HC3100 look like this, so I'm quite safe :
leeperry is offline   Reply With Quote
Old 17th April 2009, 11:41   #384  |  Link
FoLLgoTT
And so it begins...
 
FoLLgoTT's Avatar
 
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
@yesgrey3
Obviously you are the right man for my question.
Would a saturation editor be possible?

Here is an example for the influence of gamma of the saturation measured from my calibrated Sony G90:

Gamma 2.2:


Gamma 2.5:


@leeperry
Quote:
sure, I'll read the first page again and not sure this is related, but I asked tritical if we could import the measured saturations to counter-balance the gamut conversion...but he said that the data Color.HCFR kept wouldn't help.
I would be satisfied with a manual input solution. I don't like to depend on a specific program. I like general and flexible solutions and have no problems with running through a few measure-setup-iterations. But importing HCFR data as a additional feature would surely be nice.

Last edited by FoLLgoTT; 17th April 2009 at 11:56.
FoLLgoTT is offline   Reply With Quote
Old 17th April 2009, 12:30   #385  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by madshi View Post
Wouldn't it make more sense to do these things via shader math and "only" use the 3dlut for gamut/gamma correction? ... Of course that would mean that the 3dlut would do Y'CbCr -> Y'CbCr. Or maybe Y'CbCr -> YCbCr, if we implement linear light processing... What do you think?
Yes, but if a user sets the values only once and never changes them again it would be nice to create a 3DLUT including those settings... Let's wait to see how it ends up. For now we could stick just with doing it in the shaders and latelly, if it would be really necessary, I could add it, it would be simple.
The Y'CbCr -> Y'CbCr is already supported by cr3dlut, though I don't know if it's working correctly, because I haven't tested it yet. The Y'CbCr -> YCbCr would be possible to add, but then we would have to perform the final gamma encoding via 1D LUTs to have higher precision and a full control of it.
But remember that several other things that we might want to do via the 3DLUT should be done at the end of all image processing... we can always use 2 3DLUTs in the processing chain... 512MB is almost the basic reference in the current graphics cards.

Quote:
Originally Posted by FoLLgoTT View Post
Would it be possible with a 3D LUT to only change the saturation over luminance?
I think it should be possible, I'll have to look into it to see how...

Quote:
Originally Posted by Mark_A_W View Post
I'd like to use HCFR data somehow. I have one, and I'd like to close the loop.
It's just adapting HCFR's output to cr3dlut's input, or cr3dlut's input to HCFR's output...

Quote:
Originally Posted by Mark_A_W View Post
Digital screen correction, to match my digital room correction
That's our final goal...
yesgrey is offline   Reply With Quote
Old 17th April 2009, 12:52   #386  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by yesgrey3 View Post
I think it should be possible, I'll have to look into it to see how...
the ability to input the measured saturations for primaries/secondaries in your cr3dlut .ini would be pure awesomeness....but it'd take someone really brave to check it in Color.HCFR again because there's a mininum of 48 manual test patterns from the original test DVD to be done in Color.HCFR

or a script would need to be made to send a "next chapter" hotkey to MPC and then click on "next" in Color.HCFR

I already asked the Color.HCFR coders a while back if they could sync their manual DVD patterns w/ MPC, but they didn't care too much and seemed very busy already.

and I can prolly live w/ +5% of saturation at max, considering tints >75% are hardly ever used....right?

Last edited by leeperry; 17th April 2009 at 13:03.
leeperry is offline   Reply With Quote
Old 17th April 2009, 12:57   #387  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by leeperry View Post
the ability to input the measured saturations for primaries/secondaries in your cr3dlut .ini would be pure awesomeness...
It's also in my ToDo list... but no ETA.
yesgrey is offline   Reply With Quote
Old 17th April 2009, 15:29   #388  |  Link
ericgur
Registered User
 
Join Date: Dec 2001
Location: Israel
Posts: 34
Quote:
Originally Posted by Egh View Post
Best way to make picture sharper -- tweak scaling settings

Also, you are wrong with your assumption, generally speaking, it is not certain if madVR actually does upscale all the time. In case your native LCD resolution is only fit for 720p then 1080p will be downscaled by the renderer.
Well, when downscaling in one or both axises, there shouldn't be any sharpening before downsampling in that axis. You'll need a low pass filter. Lanczos does it for you if you recalculate the coefficients taking the scaling factor into account. One way to shapen the image using Lanczos is to convolve a mild high pass (e.g. [-0.07, 1.14, -0.07]) with each of the Lanczos filters (for all phases).
Another option is to modify the Lanczos formula itself.

In the following code 'x' is the sampling point relative to the center-left pixel in the sampling window. winSize is the size of the sampling window (8 for Lanczos4, 6 for Lanczos3, etc.)

In standard Lanczos, 't' equals halfWinSize.
If 't' is raised (must never be smaller than halfWinSize) the Lanczos function will more and more resemble a cropped sinc function and produce a sharper image with more ringing.

Code:
static const double pi  = 3.14159265359;
static const double eps = 1e-9;
double Sinc(double x)
{
    return (fabs(x) < eps) ? 1.0 : sin(x) / x;
}
double Lanczos(double x, int winSize, double t = 0)
{
    int halfWinSize = winSize >> 1;
    if (t < halfWinSize)
        t = halfWinSize;

    if(fabs(x) >= halfWinSize)
        return 0.0;

    x *= pi;

    return Sinc(x) * Sinc(x/t);
}
ericgur is offline   Reply With Quote
Old 17th April 2009, 15:51   #389  |  Link
ericgur
Registered User
 
Join Date: Dec 2001
Location: Israel
Posts: 34
Quote:
Originally Posted by madshi View Post
Cool! Do you still work in that area? Do you have signed an NDA or something that would stop you from sharing some of your knowledge with the HTPC world?
Sadly I can't and won't share propriatery algorithms. At this level, my text book knowledge is helpful without the getting the lawyers involved. All the information I provide can be found in printed text books and articles and is not a trade secret.

Quote:
Originally Posted by madshi View Post
I've been told by a Gennum employer that although you can do sharpening/detail enhancement before scaling, it's better for image quality to do it after (up)scaling.
You can try for yourself, the trick is to do a mild sharpening before upscaling, preferably after noise reduction. And the filter must be a high pass.

Quote:
Originally Posted by madshi View Post
Do you happen to have the CSC coefficients at hand for the other 3 cases (BT601 video levels, BT709 PC/video levels)?
The CSC coeeficients are taken from Video Demystified - a very useful book for video. I don't have a copy of it at home, so I'll post them later on. Send me a PM with your mail, I have a PDF of this book and I can mail it to you (when I return to work after the weekend).

Quote:
Originally Posted by madshi View Post
Wouldn't it make more sense to do these things via shader math and "only" use the 3dlut for gamut/gamma correction? Of course that would mean that the 3dlut would do Y'CbCr -> Y'CbCr. Or maybe Y'CbCr -> YCbCr, if we implement linear light processing. Brightness, contrast, saturation and CSC would then be done via shader math. Should be no problem performance wise, since my current shaders are mostly memory bandwidth limited, anyway. Adding in some math should not slow down things much, if at all. What do you think?
I think the big LUTs are not user friendly due to their load time. What you're currently doing is no match for the modern GPUs. Even the low end integrated GPUs can do it easily.


Quote:
Originally Posted by madshi View Post
Has he assumed that somewhere? I don't read his post like that. Furthermore, it doesn't matter much if you upscale or downscale. Noise/artifact removal should still be done before scaling (because scaling makes the artifacts more difficult to remove). However, sharpening should probably be done on the higher resolution picture. So that would be before downscaling and after upscaling. ericgur?
See my previous post on how to do sharpening. The mild pre upscaling sharpening gives little sharpness with little artifacts. Sharpening after scaling is more tricky as you'll need an adaptive algorithm - preferebly an edge directed filter. These are hard to do in realtime SW.
ericgur is offline   Reply With Quote
Old 17th April 2009, 16:03   #390  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by ericgur View Post
I think the big LUTs are not user friendly due to their load time. What you're currently doing is no match for the modern GPUs. Even the low end integrated GPUs can do it easily.
They can do CSC via shader math, but not full gamut correction. I have some ideas on how to mask the LUT loading times...

Quote:
Originally Posted by ericgur View Post
See my previous post on how to do sharpening. The mild pre upscaling sharpening gives little sharpness with little artifacts. Sharpening after scaling is more tricky as you'll need an adaptive algorithm - preferebly an edge directed filter. These are hard to do in realtime SW.
Have you seen e.g. the "LimitedSharpenFaster" AviSynth sharpening filter? What is your opinion about its quality?

Thanks!
madshi is offline   Reply With Quote
Old 17th April 2009, 16:26   #391  |  Link
honai
Guest
 
Posts: n/a
@madshi

Now that you've mentioned it I think it's safe to pull up a request for including LSF or, better yet, LSFmod in madVR.
  Reply With Quote
Old 17th April 2009, 16:38   #392  |  Link
flanger216
Registered User
 
Join Date: Mar 2004
Posts: 140
@ericgur

Is it consistently useful to apply a mild, post-scaling sharpener for video presentations? Or is it something that's typically only done on softer source material?

I'm sure this is a "try it and see if you like it" sort of thing; I was just wondering if you had any theoretical guidelines on the subject.
flanger216 is offline   Reply With Quote
Old 17th April 2009, 16:39   #393  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by ericgur View Post
I think the big LUTs are not user friendly due to their load time. What you're currently doing is no match for the modern GPUs. Even the low end integrated GPUs can do it easily.
I'm not so sure about that... maybe it's true.
Here are some performance numbers:
cr3dlut
Total number of RGB combinations processed:
256*256*256 = 16777216
processing time: 4656ms (Chromatic_Adaptation 2)
processing time: 2968ms (Chromatic_Adaptation 1)
Tested in a C2Duo E2160@2.7GHz

cr3dlut using shaders???
Let's extrapolate considering the number of RGB combinations in a HD movie:
1920*1080 = 2073600/frame
expected processing time: ~575ms (CA 2)
expected processing time: ~367ms (CA 1)
Since this is a very parallelizable task, if we consider that instead of two it can process 100 at a time
expected processing time: ~11.5ms (CA 2)
expected processing time: ~7.34ms (CA 1)
This is using 64bit FP, if we use 32bit FP the times could be cut almost in half...

madshi, if the extrapolation depicted above is reasonable, maybe you would want to consider making all cr3dlut work in the shaders. There would be another big advantage... with 3DLUTs we are limited to 8bit per component input, due to the LUT size; using shaders, you could have full 16bit input/output or even more...
yesgrey is offline   Reply With Quote
Old 17th April 2009, 16:41   #394  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by flanger216 View Post
Is it consistently useful to apply a mild, post-scaling sharpener for video presentations? Or is it something that's typically only done on softer source material?
that's the beauty of LSF, it won't sharpen up if there's no need
I've tried a lot of sharpening filters, this one is fast and the most impressive I've seen. And there's a version that uses a separate DLL(coded in assembly) to accelerate the processing slightly.
leeperry is offline   Reply With Quote
Old 17th April 2009, 17:14   #395  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
would it be possible under a reasonable amount of work to have a switch which then uses the multi core cpu rather than gpu for the work? for example when watching AVC with a quadcore the cpu load is mostly ~30-50%, so theres still some power left which could be used. but I suffer from a terrible graphic card which is just too slow, so perhaps the cpu would be able to do that work as well. dunno how whether it might be too much work to add though.
Thunderbolt8 is offline   Reply With Quote
Old 17th April 2009, 17:28   #396  |  Link
ericgur
Registered User
 
Join Date: Dec 2001
Location: Israel
Posts: 34
Quote:
Originally Posted by yesgrey3 View Post
I'm not so sure about that... maybe it's true.
Here are some performance numbers:
cr3dlut
Total number of RGB combinations processed:
256*256*256 = 16777216
processing time: 4656ms (Chromatic_Adaptation 2)
processing time: 2968ms (Chromatic_Adaptation 1)
Tested in a C2Duo E2160@2.7GHz

cr3dlut using shaders???
Let's extrapolate considering the number of RGB combinations in a HD movie:
1920*1080 = 2073600/frame
expected processing time: ~575ms (CA 2)
expected processing time: ~367ms (CA 1)
Since this is a very parallelizable task, if we consider that instead of two it can process 100 at a time
expected processing time: ~11.5ms (CA 2)
expected processing time: ~7.34ms (CA 1)
This is using 64bit FP, if we use 32bit FP the times could be cut almost in half...

madshi, if the extrapolation depicted above is reasonable, maybe you would want to consider making all cr3dlut work in the shaders. There would be another big advantage... with 3DLUTs we are limited to 8bit per component input, due to the LUT size; using shaders, you could have full 16bit input/output or even more...
Running CSC on an octa core Intel (2x5450 Xeons) workstation takes a few (2-3) ms on 1080p using integer math (fixed point) on 16bit per color component - without even using SSE. GPUs have more crunching power and the time should be under 1ms. It doesn't matter how many different pixels exist as each pixel is calculated on its own. Runtime of random pixels and a black image is identical, only the resolution matters. I highly recommend working in 12 or 16 bit (12 bit is excellent and allows illegal values that can cropped later). 16 bit is overkill but in the SW world, it costs about the same as 10/12 bit. In HW using more bits is horribly expensive...
ericgur is offline   Reply With Quote
Old 17th April 2009, 17:33   #397  |  Link
ericgur
Registered User
 
Join Date: Dec 2001
Location: Israel
Posts: 34
Quote:
Originally Posted by Thunderbolt8 View Post
would it be possible under a reasonable amount of work to have a switch which then uses the multi core cpu rather than gpu for the work? for example when watching AVC with a quadcore the cpu load is mostly ~30-50%, so theres still some power left which could be used. but I suffer from a terrible graphic card which is just too slow, so perhaps the cpu would be able to do that work as well. dunno how whether it might be too much work to add though.
Some algorithms are not GPU friendly and should be done in CPU. A good example is statistics gathering like histograms, average brightness, etc. These types of algorithms are usually very simple to implement in a multi core CPU.
ericgur is offline   Reply With Quote
Old 17th April 2009, 18:08   #398  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by yesgrey3 View Post
madshi, if the extrapolation depicted above is reasonable, maybe you would want to consider making all cr3dlut work in the shaders. There would be another big advantage... with 3DLUTs we are limited to 8bit per component input, due to the LUT size; using shaders, you could have full 16bit input/output or even more...
I'm not sure. You planned to add some new features to cr3dlut which should make calculations a lot more complex, I guess. I don't really like the idea of doing this via shaders if we can achieve the same result via a simple texture lookup. Furthermore, shaders are usually only 32bit. Being limited to 8bit input is not as bad as it sounds, thanks to trilinear interpolation.

Quote:
Originally Posted by ericgur View Post
Running CSC on an octa core Intel (2x5450 Xeons) workstation takes a few (2-3) ms on 1080p using integer math (fixed point) on 16bit per color component - without even using SSE. GPUs have more crunching power and the time should be under 1ms. It doesn't matter how many different pixels exist as each pixel is calculated on its own. Runtime of random pixels and a black image is identical, only the resolution matters.
You are misunderstanding yesgrey3. Once again, the purpose of the 3dlut is not to do CSC, only. The main purpose of the 3dlut is complex gamut correction, of course in linear light. I expect that doing this via shader math would cost too much performance to be reasonable.

Quote:
Originally Posted by Thunderbolt8 View Post
would it be possible under a reasonable amount of work to have a switch which then uses the multi core cpu rather than gpu for the work?
I have already thought about offering an option to do chroma upsampling in the CPU (with full quality = 16bit). Not sure whether I will really implement this, though.

Quote:
Originally Posted by honai View Post
@madshi

Now that you've mentioned it I think it's safe to pull up a request for including LSF or, better yet, LSFmod in madVR.
That's 3 steps too far. Let me get basic playback working fine before even thinking about adding funny features like that...
madshi is offline   Reply With Quote
Old 17th April 2009, 18:12   #399  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
ok, so that's the french BD of "Nightmare Before Christmas"

left is downscale to 768p in ffdshow(spline36)>LSF 1.0@40>PC conversion>ConvertToYUY2()>t3dlut HD.3dlut>HR in RGB32

right is downscale to 768p in ffdshow(spline36)>LSF 1.0@40>PC conversion>mVR w/ HD.3dlut in YV12

the gamma is slightly darker in mVR(which increases the contrast), and mVR's PNG's are also 13% bigger than HR.










Last edited by leeperry; 18th April 2009 at 22:39.
leeperry is offline   Reply With Quote
Old 17th April 2009, 18:44   #400  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by ericgur View Post
Running CSC on an octa core Intel (2x5450 Xeons) workstation takes a few (2-3)
Quote:
Originally Posted by madshi View Post
You are misunderstanding yesgrey3. Once again, the purpose of the 3dlut is not to do CSC, only. The main purpose of the 3dlut is complex gamut correction, of course in linear light.
yes, ericgur, the 3DLUT is for performing color gamut correction, so we could get accurate colors within our display's color gamut, which usually is different (in some cases much more wider) than the source's color gamuts.

Quote:
Originally Posted by madshi View Post
The main purpose of the 3dlut is complex gamut correction, of course in linear light. I expect that doing this via shader math would cost too much performance to be reasonable.
In fact, the first working version of my color gamut conversion worked with PS scripts inside mpc-hc, and it worked pretty fast. Of course it does not have the current 64bitFP precision, but the difference is not very high...

Quote:
Originally Posted by madshi View Post
I'm not sure. You planned to add some new features to cr3dlut which should make calculations a lot more complex, I guess. I don't really like the idea of doing this via shaders if we can achieve the same result via a simple texture lookup. Furthermore, shaders are usually only 32bit. Being limited to 8bit input is not as bad as it sounds, thanks to trilinear interpolation.
Yes, the calculations should be more complex, but I don't know if it will be a lot slower... I presume it would not be much more slower than it is now. The biggest penalty comes from the chromatic adaptation using the full Bradford transform model.
32 bit is all that is needed, we only need 64bit because the gamma decoding/encoding.
The biggest advantage of the 3DLUT is that you know that it will never use more GPU resources that it currently uses.
Its biggest disadvantage, is the size.
The decision is yours. At any time, cr3dlut's code could be transformed in shader code, it would not be a very hard task...
yesgrey 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:10.


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