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 11th July 2016, 16:07   #38641  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
I have noticed that the HDR algorithm clips the highlights even when compress highlights is selected.
Is it how it should be? I thought compress = NOT Clip.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 16:24   #38642  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
It should not clip, unless the frame peak luminance is higher than the metadata claims.
madshi is offline   Reply With Quote
Old 11th July 2016, 16:40   #38643  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Ah, okay.
I also noticed that "preserve Hue" will clip the colors if the color is too saturated.

Isn't the point of "measure peak luminance" is to prevent clipping, or it works only when the measured luminance is lower than the metadata peak?
This does not take into account that the mastering monitor may have ABL and the peak luminance actually below the metadata value.

I think the image quality would benifit from measuring the peak luminance even if it slightly higher that the metadata value to prevent clipping.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 11th July 2016 at 16:47.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 16:43   #38644  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
"Preserve hue" does not clip, it desaturates in a hue linear color space. Please re-read the tone mapping discussions on the previous 5 pages or so of this thread. This topic has been discussed extensively there.
madshi is offline   Reply With Quote
Old 11th July 2016, 17:00   #38645  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Perhaps it would be better if I post images of what I see and then ask questions.

Compress only:


Compress and Hue (HQ):


At 400nit.
It looks like the brightest areas of the headlights and tent are clipped when I enable Hue correction.
Or maybe they are so desaturated that the gradations are completely lost?

Did you consider my previous post that ABL might effect the true peak luminance and in reality it may be lower than the metadata value but higher in code value?
I heard that at least few movies were mastered on the Samsung HDR TV that has obvious ABL behavior with anything above 2% window.

I believe many (if not all) of the professional studio HDR monitors also have ABL to some extent, so it will not be wise to clip AT the metadata value.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 11th July 2016 at 17:10.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 17:16   #38646  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
As I've explained a couple of pages ago, after tone mapping (compression) there may be colored pixels (e.g. red/orage in this case) which have a luminance value assigned to it which is near to the peak luminance of the video. E.g. I suspect those pixels which are red/orage without hue correction, are near to the peak luminance of the video. The problem with that is that your display reaches its peak luminance with *white* pixels, not with red pixels. So if your display can only do 400 nits, and the video asks for a 400 nits red pixel, what can madVR do? Without hue correction, I simply do nothing. Which means the RGB pixel will go out of bounds (outside of 0-255 for PC levels), which without hue correction will then simply be clipped to the legal RGB range. This will modify hue, but it might preserve some color differences. If you enable hue correction, madVR detects this situation and it will then desaturate such 400 nits red pixels just as much as necessary to make them fit into the legal RGB range. In this case they get almost or even completely desaturated/white. Yellow is less effected because it has more green in it than red, and green produces much more luminance than red. So in this situation hue correction may lower perceived detail because the difference between white and bright yellow is much smaller than the difference between red and bright yellow. However, without hue correction, the exact hue isn't reproduced correctly, and the luminance is WAY too dark.

I don't think this is a case of incorrect metadata or ABL related problems.

P.S: You can see the same effect in the spheric tent in the background. Without hue correction it's WAY too dark, but is nicely red. This is likely again an area which is near to the video's peak luminance, but with a highly saturated red color. Turning hue correction on will detect this and desaturate the pixel accordingly. So the pixel goes towards white, which is not nice, but which helps reproducing the correct luminance.

Last edited by madshi; 11th July 2016 at 17:19.
madshi is offline   Reply With Quote
Old 11th July 2016, 17:22   #38647  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Now I understand , thanks.

The ABL is a different issue, I just posted it in the same go; I see clipped highlights where they should not be, the reason I assume is ABL when mastering.
Not to be repetitive but: true peak luminance in reality may be lower than the metadata value but higher in code value.
Therefor it is not wise to clip at the metadata value in software.
Leave some "headroom" to compensate for the ABL behavior of the mastering monitor.

Or even better, measure the peak white code value even if it's above the metadata peak value.

I hope this makes sense.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 11th July 2016 at 17:30.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 17:27   #38648  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Leaving headroom also means highlights getting duller. There's no free lunch here.
madshi is offline   Reply With Quote
Old 11th July 2016, 17:31   #38649  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
That's where your "measure peak white" comes in, but it should do its job with code values above metadata values also, not only below like it does now (I assume).

The colorist is not limited to the code values of the peak luminance of his monitor, he might use higher code values while pushing the ABL of his monitor.
We must remember that the code values control the LED backlight, and they do NOT actually clip the code values if the the backlight can't go brighter.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 11th July 2016 at 17:40.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 18:23   #38650  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
To solidify my statements about ABL and code values, here is an image from the LG_Chess_HDR video:
With HDR OFF, his nose has values of 255 which equate to 10,000 nit but the metadata peaks at 1000 nit.


May I suggest a solution, not only complaint.

When the measured peak white is below the peak metadata value, the measured luminance value should be stretched like it does now (if I'm not mistaken).
But when the measured peak value is higher than the metadata (like this example) the luminance should be given headroom in % (not a free lunch).

In other words, give 105% as the new luminance, and super compress anything above metadata into these 5%.
Example: If metadata is 1000nit and there is code values above that, compress them to 1050 nit.
We lose 5% in average luminance but we do not lose picture information which is way more important.

EDIT:
If we actually measure the code/bit values, many of the HDR test videos have code values above the peak metadata value, which currently madvr clips above.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 11th July 2016 at 18:32.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 21:22   #38651  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,474
Quote:
Originally Posted by madshi View Post
You guys know the drill: Please provide me with samples + screenshots which show that SuperRes Anti-Bloating helps in some situations, and I will reconsider. I've removed it because I couldn't really see any benefit in my own tests, and the feedback from the majority of users seemed to confirm that.
Fair enough, in order to make my screenshots comparison valid I went back to your original description of AB that went like "The new anti-bloating tries to concentrate sharpening on higher frequencies and to remove lower frequencies. I like the look that produces, but your mileage may vary", that's basically what it's boiling down to my eyes with the lighthouse picture I regularly use downscaled to 640*360 and then reupscaled to 1920*180: it looks less edgy, obviously softer and I really really dig the look on moving objects and especially on double SR refined after every 2X step in combination with 60Hz FRC and noisy low bit-rate low-resolution footage....so at the end of the day it's still entirely subjective I'm afraid? I'm just not sure what my screenshots would have to prove? Should I use test patterns in order to make it less subjective?
leeperry is offline   Reply With Quote
Old 11th July 2016, 22:17   #38652  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,474
OK here goes, please don't shoot, 1080p original Vs SR@2 LL Vs SR@2 LL+AB75%, dithering was disabled:

http://screenshotcomparison.com/comparison/178286

http://screenshotcomparison.com/comparison/178284

http://screenshotcomparison.com/comparison/178285

All files can be found here.

Long story short edges are less noisy and it looks wonderful with FRC, double SR@2 after every 2X upscale looks seriously edgy otherwise IME. It might also be closer to the ground truth, at least edges would appear to be.

Last edited by leeperry; 11th July 2016 at 22:50.
leeperry is offline   Reply With Quote
Old 11th July 2016, 22:49   #38653  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by James Freeman View Post
May I suggest a solution, not only complaint.

When the measured peak white is below the peak metadata value, the measured luminance value should be stretched like it does now (if I'm not mistaken).
But when the measured peak value is higher than the metadata (like this example) the luminance should be given headroom in % (not a free lunch).

In other words, give 105% as the new luminance, and super compress anything above metadata into these 5%.
Example: If metadata is 1000nit and there is code values above that, compress them to 1050 nit.
We lose 5% in average luminance but we do not lose picture information which is way more important.
But what should I do if the measured peak value is only 4% higher than the metadata? Should I still increase headroom by 5%? What if it's 7% higher? Or 170% higher? A proper solution would probably have to change the added headroom "size" depending on the amount of overshoot.

And then there's the problem that this kind of thing would require me to piece 3 line/curve segments together, which makes the math quite a bit more complicated.

Furthermore, compression already gets much stronger the higher the peak is. In order to compress a large overshoot into just 5% more room would require even stronger compression ratios which I'm not sure would look much different to clipping.

Overall I'm not sure it's worth spending lots and lots of development time and effort into a probably very small improvement like this. I'm not even sure there would be a visible benefit at all. I think the main visual problems don't come from luminance overshoots, but from highly saturated pure color highlights, as explained before.

Quote:
Originally Posted by leeperry View Post
OK here goes, please don't shoot, 1080p original Vs SR@2 LL Vs SR@2 LL+AB75%, dithering was disabled:

http://screenshotcomparison.com/comparison/178286

http://screenshotcomparison.com/comparison/178284

http://screenshotcomparison.com/comparison/178285

All files can be found here.

Long story short edges are less noisy and it looks wonderful with FRC and double SR@2 after every 2X upscale looks seriously edgy otherwise IME. It might also be closer to the ground truth, at least edges would appear to be.
Just to complete the picture, could you please add screenshots for the following 3 configuration variants?

1) SR@1 with AB25.
2) SR@1 with AB disabled.
3) SR disabled.

The purpose is to find out whether maybe activating AB maybe simply just decreases the effect/strength of SR without having any other benefit. Thanks.
madshi is offline   Reply With Quote
Old 11th July 2016, 23:20   #38654  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,474
Quote:
Originally Posted by madshi View Post
Just to complete the picture, could you please add screenshots for the following 3 configuration variants?

1) SR@1 with AB25.
2) SR@1 with AB disabled.
3) SR disabled.

The purpose is to find out whether maybe activating AB maybe simply just decreases the effect/strength of SR without having any other benefit.
OK, here goes:

http://screenshotcomparison.com/comparison/178293

http://screenshotcomparison.com/comparison/178295

http://screenshotcomparison.com/comparison/178298

files on mega

I got a good bunch of other features enabled in the upscaling refinement window, my point was in my real-world use AB75 does wonders. Of course SR looks sharper than without but I believe the top left of the picture in my first link with SR1 looks better with AB25 than without. The whole point of AB to me is that motion looks smoother because edges aren't nearly as noisy anymore. Anyway, please bring it back
leeperry is offline   Reply With Quote
Old 11th July 2016, 23:41   #38655  |  Link
zoyd
Registered User
 
Join Date: Sep 2009
Posts: 43
Quote:
Originally Posted by madshi View Post
But what should I do if the measured peak value is only 4% higher than the metadata? Should I still increase headroom by 5%? What if it's 7% higher? Or 170% higher? A proper solution would probably have to change the added headroom "size" depending on the amount of overshoot.
I don't know what you do in a case like this. There is no part of the PQ encoding standard that allows for overshoot so I would assume it's either a bad encode or the metadata is wrong. The chess clip specifies a max luminance of 1000 nits but clearly has codes above that, especially in the chess piece highlights. I've checked both the Sony sample (bright setting sun) as well as a reference clip I have, and all codes are within their specified max luminance of 4000 nits.

no HDR processing
zoyd is offline   Reply With Quote
Old 12th July 2016, 05:22   #38656  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
This is my previously posted comparison of SuperRes with and without anti-bloating:

I have a couple of examples of where anti-bloating removes detail that would be considered valid sharpening.

SD -> FHD
super-xbr100 + SuperRes (3)


In the first example, search for the headline "Rick Nielsen: no cheap collector" in the middle of the image. SuperRes does a good job of making the original letters more clear and easy to read. While anti-bloating returns these letters to a blurred smear.

The rest of the lettering, especially on the lower part of the guitar shows the same improvement and then degradation when anti-bloating is enabled.

Guitar
Guitar SuperRes (3)
Guitar SuperRes (3) + Anti-Bloating 100%

In the second example, look at the leather patches on Kata Mara's arm and the black guy.

Also, the objects in the shadows (top-right) become obscured when anti-bloating is enabled. SuperRes again slightly enhances the low-res original and anti-bloating effectively cancels this out.

Fantastic Four
Fantastic Four SuperRes (3)
Fantastic Four SuperRes (3) + Anti-Bloating 100%

So far, only my original test where SuperRes (3) was combined with crispen edges (1.0) did anti-bloating prove to be an effective countermeasure for SuperRes. I am thankful to see that SuperRes, at the right strength, does not oversharpen the image. This has completely changed my settings preferences.
Warner306 is offline   Reply With Quote
Old 12th July 2016, 05:58   #38657  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by madshi View Post
Overall I'm not sure it's worth spending lots and lots of development time and effort into a probably very small improvement like this. I'm not even sure there would be a visible benefit at all.
Quote:
Originally Posted by zoyd View Post
I don't know what you do in a case like this. There is no part of the PQ encoding standard that allows for overshoot so I would assume it's either a bad encode or the metadata is wrong.
I agree, it is not worth fixing a bad encoding in madVR.

Yet again, we must remember that the code values control the LED backlight, and the code value do NOT actually clip if the the backlight can't go brighter.
Lets just hope no colorist relies on that trait of current HDR TVs/mastering Monitors because in the future a TV might just show these 10,000 nit peaks and look blindingly bright in the wrong spots.

In my example with the nose and zoyds example with the chess piece the peak brightness is 10,000 nit in some places while the peak metadata is 1000 nit.
We should never see a chess piece or a human nose radiating as bright as the sun... so this LG_Chess video has some "noob" flaws in terms of HDR encoding.

I may be completely wrong and the camera actually captured 10,000 nit from the boom lights illuminating the scene and reflecting from shiny objects.
So the colorist actually did an excellent job preserving that in the encoding even though the final video was mastered for/on a 1000nit peak display.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 12th July 2016 at 06:10.
James Freeman is offline   Reply With Quote
Old 12th July 2016, 06:24   #38658  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 492
madshi,

What changes happened between 0.90.20 and 0.90.22 that would hurt performance? As I have said in the past, I like pushing my GPU to the max and my 720p24 profile is right on the edge (so much so that even a chroma superres of just 1 pushes it over the edge). When I tried 0.90.22 the first file I watched at 720p was actually 718 and I thought the performance hit was because of that... however later I watched one that was 720 and I could no longer maintain render queue. I rolled back to 0.90.20 and all is well again. Just curious what could have changed since I didn't see anything is the changelog for either 21 or 22. Something deeper under the hood?

QB
__________________
QBhd is offline   Reply With Quote
Old 12th July 2016, 06:33   #38659  |  Link
x7007
Registered User
 
Join Date: Apr 2013
Posts: 252
Hi,

What does it mean if 1080p/720p MKV movies have present queue 0-2/3 in Windowed Mode but FSE it works fine.

Asus G751JT

Windows 8.1 x64 + Potplayer x64 + Lavfilters 0.61 + DXVA2 CopyBack or CUVID + 970M + 368.69 Drivers + Potplayer Profile set to Maximum Performance - 3 Pre-rendered frames - Gsync Disabled Fixed Refresh


How can I fix it ?

x7007 is offline   Reply With Quote
Old 12th July 2016, 08:17   #38660  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,474
Quote:
Originally Posted by Warner306 View Post
I have a couple of examples of where anti-bloating removes detail that would be considered valid sharpening. (..)

Guitar
Guitar SuperRes (3)
Guitar SuperRes (3) + Anti-Bloating 100%
AB100% is too high of a value IME and I rest my case that there is no such thing as "valid sharpening" to my eyes(especially with sxbr100 which is too sharp to me and so is SR3), for instance I prefer the "Nie" characters written on the left button of the guitar with AB than without. You also didn't mention whether picture was refined after every 2X upscale and what downscaler was used(I ran SSIM 2D 100%).

Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293

This is what AB does, it cleans edges for smoother movements. Either way there is no free lunch to be expected from upscaling, it's all about compromises and I find the AB75% compromise more than worth it as picture doesn't look harsh and oversharpened anymore.

Last edited by leeperry; 12th July 2016 at 08:34.
leeperry 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 15:15.


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