MadVR - ArgyllCMS - Page 152 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 500Likes
Reply
 
Thread Tools
post #4531 of 4655 Old 04-06-2017, 12:55 PM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 123
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 9 Post(s)
Liked: 17
Quote:
Originally Posted by Light Illusion View Post
No, a 3D LUT cannot alter screen uniformity.

Steve
Thanks Steve! Any ideas on how to tackle this issue, without replacing the unit? I calibrated it based on the center of the screen using dispcalgui, but the green / purple is quite visible in some scenes.
cfelicio is offline  
Sponsored Links
Advertisement
 
post #4532 of 4655 Old 04-06-2017, 01:01 PM
AVS Forum Special Member
 
Light Illusion's Avatar
 
Join Date: Aug 2010
Posts: 1,395
Mentioned: 11 Post(s)
Tagged: 0 Thread(s)
Quoted: 513 Post(s)
Liked: 815
No, you would need a framestore to correct such issues.
The only option is to reject the display as not being fit for purpose.



Steve

Steve Shaw
LIGHT ILLUSION

Light Illusion is online now  
post #4533 of 4655 Old 04-12-2017, 01:20 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
3dLut inconsistence

@madshi


I have a issue with 3dlut and was hopping you or someone could enlighten were I'm doing the wrong step.

I have been bothering Steve (sorry Steve) for a few days now about calibrating and generating 3dlut with lightspace. I'm at the point were the results I'm getting seam to be ok when testing the 3dlut active within lightspace but when I upload the 3dlut to madvr (after applying videoscale) I get different results. They seam subtle but I can see the difference while on screen with a 5% white patch. The patch turns cyan when active on madvr but is ok when active in lightspace.

I have upload here the 3dlut in eecolor format. With and without videoscale.

Any pointer would be appreciated.

Thank you
Attached Thumbnails
Click image for larger version

Name:	difference_1.JPG
Views:	33
Size:	181.7 KB
ID:	2080025   Click image for larger version

Name:	difference_2.JPG
Views:	32
Size:	172.9 KB
ID:	2080033   Click image for larger version

Name:	lut_active_lightspace.JPG
Views:	37
Size:	166.8 KB
ID:	2080041   Click image for larger version

Name:	lut_active_lightspace_2.JPG
Views:	30
Size:	162.5 KB
ID:	2080049   Click image for larger version

Name:	lut_active_madvr.JPG
Views:	29
Size:	177.7 KB
ID:	2080057  

Click image for larger version

Name:	lut_active_madvr_2.JPG
Views:	31
Size:	173.5 KB
ID:	2080065   Click image for larger version

Name:	lut_active_madvr_NO_VIDEOSCALER_1.JPG
Views:	32
Size:	93.4 KB
ID:	2080073   Click image for larger version

Name:	lut_active_madvr_NO_VIDEOSCALER_2.JPG
Views:	31
Size:	93.8 KB
ID:	2080081  
adolfotregosa is offline  
 
post #4534 of 4655 Old 04-12-2017, 01:34 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Hi adolfo,

are you doing all these tests with madTPG? How is your GPU configured? It should be set to RGB 0-255 output, with all features like "skin tone correction", "digital vibrance" etc turned off in the GPU control panel. Is that the case?

I suppose one way to debug this issue further is to use a color picker tool like this one:

http://annystudio.com/software/colorpicker/

This way you can render a specific test color through madTPG, then measure the exact RGB pixel madVR output, with your 3DLUT disabled vs enabled. Then maybe Steve can check if the rendered pixels madVR outputs are as expected or not? I'm not sure if LightSpace has a tool for that. But if we can verify that madVR treats the 3dlut correctly or not, that would make it easier to pinpoint where the problem is coming from.

FWIW, some months/years ago, a couple of users have compared the eeColor box to what madVR does with a 3dlut and found there to be no noticeable difference. There are some variables involved, though. E.g. madVR always wants 3DLUTs with video levels input and output. Furthermore there are 64 point and 65 point eeColor 3dluts. madVR expects 65 points. I remember that there were some color issues with Calman, when it created 64 point eeColor 3DLUTs for madVR. Once they switched to 65 points, the issues where gone, IIRC.
madshi is offline  
post #4535 of 4655 Old 04-12-2017, 02:39 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
Hi !
Nvidia gpu 0-255, madvr 16-235, lg c6 black level low (16-235) . Same is happening with everything in 0-255 (videoscaler still applied to the lut).

Nvidia control panel video setting "with the video player settings" selected.

I assume if I had something wrong in regards to the gpu I would see them when testing the luts applied within lightspace with madvr test pattern generator, no?

The issue I'm seeing happens when I upload a lut directly from lightspace to madvr or when I export a 65 eecolor lut and import it with madvr.

If you need me to run some test please point me to them and I'll try.
adolfotregosa is offline  
post #4536 of 4655 Old 04-12-2017, 03:00 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Ok, as mentioned in my previous post, I'd suggest that you choose a test pattern color that shows the error most strongly, then use the "Color Picker" tool linked in my previous comment to log the exact RGB output that madVR and LightSpace produce. Obviously the RGB output must be different. Please note that due to dithering, the exact pixel values will vary by +-1 on RGB. So it would make sense to check multiple pixels and try to get a floating point average.

If we have the exact test pattern color, and the exact RGB output value LightSpace and madVR produce, then we can manually check the 3dlut to see if madVR has interpreted the 3dlut correctly or not.
madshi is offline  
post #4537 of 4655 Old 04-12-2017, 03:33 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
well, this is just crazy :S there is a difference but like you said + or - 1 rgb but to my eyes and the i1 d3 probe madvr produces a 5% cyan patch instead of 5% white.

I done 18 random clicks on each test. no lut, active in lightspace and active in madvr.
Attached Thumbnails
Click image for larger version

Name:	lightspace_lut.JPG
Views:	31
Size:	16.3 KB
ID:	2080161   Click image for larger version

Name:	madvr_lut.JPG
Views:	28
Size:	17.2 KB
ID:	2080169  
Attached Files
File Type: txt no_lut_active.txt (180 Bytes, 12 views)
File Type: txt lut_active_lightspace.txt (180 Bytes, 11 views)
File Type: txt lut_active_madvr.txt (180 Bytes, 14 views)
adolfotregosa is offline  
post #4538 of 4655 Old 04-12-2017, 06:29 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Building the average of these 3 reading lists I'm getting this:

no_lut_active: 27.17, 27.11, 27.17
lut_active_lightspace: 25.33, 25.50, 25.33
lut_active_madvr: 24.22, 24.61, 24.55

These numbers don't really suggest a clearly visible color deviation, do they? I do wonder why lightspace seems to be somewhat brighter than madVR, though? How did you get those lightspace readings? I suppose lightspace has its own internal renderer?

Anyway. The big question is: Where does this cyan push come from, if the readings via "color picker" suggest a fairly neutral gray? Here are a couple ideas what you could still try:

1) Make a PrintScreen of both LightSpace and madVR's output. When displaying the PrintScreen in MS Paint, do you see the same results (meaning neutral "color picker" readings, but a cyan push with the madVR screenshot)?

2) Have you tried resetting madVR to default settings?

3) You could try creating a new image in MS Paint and manually draw a color which matches either the LightSpace or madVR color picker readings. Can you reproduce the cyan push that way?
madshi is offline  
post #4539 of 4655 Old 04-12-2017, 07:46 AM
AVS Forum Special Member
 
Light Illusion's Avatar
 
Join Date: Aug 2010
Posts: 1,395
Mentioned: 11 Post(s)
Tagged: 0 Thread(s)
Quoted: 513 Post(s)
Liked: 815
Quote:
Originally Posted by adolfotregosa View Post
I have been bothering Steve (sorry Steve) for a few days now about calibrating and generating 3dlut with lightspace...
No problem at all - we are here to help.
And I'd love to know what the cause of the issue is, especially as we have never seen this before - on madVR or eeColor.
(Probably should start a new MadVR - LightSpace CMS thread so other LightSpace users may see the thread and join in...)
At the moment I am as lost and confused as you...

Steve

Steve Shaw
LIGHT ILLUSION

Light Illusion is online now  
post #4540 of 4655 Old 04-12-2017, 09:07 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
Well, the only conclusion I'm able to arrive is that on my particular TV or model, dunno, that 1 or 2 value r-g-b difference between lightspace and madvr lut is enough to create the issue at very low IRE values. crazy stuff :s

I seam to be able to mitigate the issue by applying a axis blend or grey blend filter in lightspace. I don't really know which filter would be best on this situation. Steve .... ??

But yeah, just 1 or 2 rgb difference and all hell breaks loose..

Edit- Yes, lightspace applies the lut before sending it to madvr pattern generator.

Last edited by adolfotregosa; 04-12-2017 at 09:25 AM.
adolfotregosa is offline  
post #4541 of 4655 Old 04-12-2017, 10:57 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
@madshi

I managed to capture the issue perfectly.
I did what you asked. A print screen of madvr window.

You have 2 pictures attached. Each has 2 patches side by side. The left patch is the print screen of each respective lut being shown, the right one madvr window. I presume you can guess which one has the lut applied on madvr vs lightspace.
Attached Thumbnails
Click image for larger version

Name:	20170412_185044.jpg
Views:	67
Size:	70.9 KB
ID:	2080953   Click image for larger version

Name:	20170412_184905.jpg
Views:	63
Size:	66.8 KB
ID:	2080961  
adolfotregosa is offline  
post #4542 of 4655 Old 04-12-2017, 03:17 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
I don't see what kind of program/window the left side is. It doesn't look like MS Paint to me.

So you're saying if you PrintScreen the madVR window, then the madVR has a cyan push, but the screenshot of the madVR window does *not* have the cyan push? Is that what you're saying? You're not using "Overlay" mode in the madVR settings, are you?
madshi is offline  
post #4543 of 4655 Old 04-13-2017, 12:40 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
The program is the default pictures viewer of windows 10.
Yes, I did a print screen of madvr window with lut active only in lightspace and then I took another print but with the lut active only in madvr.

And yes, the print screen of madvr does not have that cyan push when side-by-side has you can see on my picture. On my phone pictures the left image is the print of the currently showing patch on madvr window ( on the right )
I don't get it but that is what I get. I can only conclude that a single r g b value can make a visible difference on my tv at that low level IRE.
Attached Thumbnails
Click image for larger version

Name:	madvr_settings.JPG
Views:	39
Size:	62.2 KB
ID:	2082185   Click image for larger version

Name:	print_madvr_lut.JPG
Views:	31
Size:	25.5 KB
ID:	2082209   Click image for larger version

Name:	print_lightspace_lut.JPG
Views:	27
Size:	24.7 KB
ID:	2082217  

Last edited by adolfotregosa; 04-13-2017 at 12:45 AM.
adolfotregosa is offline  
post #4544 of 4655 Old 04-13-2017, 01:11 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Do you have any ICC profile loaded in the OS? Or any other OS based calibration active? I'm wondering how it's possible that a PrintScreen produces different colors. That's a very unusual problem. What kind of GPU are you using? Is it a laptop with shared NVidia/Intel GPU? Or a desktop PC with only one GPU?
madshi is offline  
post #4545 of 4655 Old 04-13-2017, 04:02 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
It is a laptop with a single nvidia GTX1070.

I have a custom profile active loaded only for the laptop display.
Attached Thumbnails
Click image for larger version

Name:	profile_loader.JPG
Views:	29
Size:	20.4 KB
ID:	2082265   Click image for larger version

Name:	icc_lg.JPG
Views:	35
Size:	35.6 KB
ID:	2082273   Click image for larger version

Name:	icc_laptop.JPG
Views:	33
Size:	40.5 KB
ID:	2082281   Click image for larger version

Name:	icc_lg_2.JPG
Views:	33
Size:	47.6 KB
ID:	2082289   Click image for larger version

Name:	icc_laptop_2.JPG
Views:	30
Size:	52.1 KB
ID:	2082297  

Click image for larger version

Name:	gpu.JPG
Views:	31
Size:	49.9 KB
ID:	2082305  
adolfotregosa is offline  
post #4546 of 4655 Old 04-13-2017, 04:04 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Does the laptop have an Intel GPU inside (aka Optimus system = Intel+NVidia GPU)?

What happens if you temporarily remove the ICC profile? Does that change anything?
madshi is offline  
post #4547 of 4655 Old 04-13-2017, 05:50 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
No intel here. Only Nvidia. I have removed any trace of icc profile, rebooted and redone all measurements.

Removing the icc does not change a thing. I have done a bigger colorpicker readings and have attached them. ( dunno if that helps ). Anyhow. It is not worth losing sleep over this, i can fix it after aplying a grey blend filter from low 0.08 to high 0.12 in lightspace and from a rgb prepective it seams to lower the green value by 1 and that is enough.
Attached Thumbnails
Click image for larger version

Name:	gpu_2.JPG
Views:	26
Size:	31.5 KB
ID:	2082337   Click image for larger version

Name:	no_icc_1.JPG
Views:	25
Size:	18.9 KB
ID:	2082345   Click image for larger version

Name:	no_icc_lut_lightspace.JPG
Views:	26
Size:	30.5 KB
ID:	2082353   Click image for larger version

Name:	no_icc_lut_madvr.JPG
Views:	28
Size:	33.4 KB
ID:	2082361   Click image for larger version

Name:	print_madvr_lut_after_filter.JPG
Views:	24
Size:	34.7 KB
ID:	2082377  

Attached Files
File Type: txt lightspace_1.txt (490 Bytes, 12 views)
File Type: txt no_lut_1.txt (400 Bytes, 14 views)
File Type: txt madvr_1.txt (530 Bytes, 12 views)
File Type: txt madvr_lut_with_filter.txt (440 Bytes, 13 views)
adolfotregosa is offline  
post #4548 of 4655 Old 04-13-2017, 11:39 AM
AVS Forum Special Member
 
sillysally's Avatar
 
Join Date: Jun 2006
Location: Chicago
Posts: 4,952
Mentioned: 14 Post(s)
Tagged: 0 Thread(s)
Quoted: 1015 Post(s)
Liked: 952
^^^^
Its because your display is a OLED, I use LightSpace default 'gray balance' setting all the time on my LG OLED.

You are smart not to try and use the 5 to15% WB controls in your OLED to correct that issue.
btw, you may want to check your brightness with a pattern. You may have to increase that setting a little, but it will not hurt anything.

Nice job.

ss

"Don't worry be happy"
For Sale Lumagen Radiance Pro 4440/2, see link for details
http://www.avsforum.com/forum/210-vi...l#post54911046
sillysally is offline  
post #4549 of 4655 Old 04-13-2017, 11:53 AM
Member
 
adolfotregosa's Avatar
 
Join Date: Apr 2011
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 12
Quote:
Originally Posted by sillysally View Post
^^^^
Its because your display is a OLED, I use LightSpace default 'gray balance' setting all the time on my LG OLED.

You are smart not to try and use the 5 to15% WB controls in your OLED to correct that issue.
btw, you may want to check your brightness with a pattern. You may have to increase that setting a little, but it will not hurt anything.

Nice job.

ss
Hi SS! Yes my brightness is set at 51. At 52 I lose the perfect black. With gamma set at 2.2 it has a glow, not perfect black, but with lights on you can't tell the difference. So 2.4 for the perfect black with lights off and 2.2 when lights are on.
Actually on my tv I managed to get 5 10 and 15 spot on but my God, a single click and good bye lol I'm really happy with lightspace lut results now that I'm more familiar with it and also madvr does miracles. Dithering (on my case random dithering visually is best) and banding removal medium is mandatory.

Thank you Steve and Madshi!
sillysally and Light Illusion like this.
adolfotregosa is offline  
post #4550 of 4655 Old 04-13-2017, 04:32 PM
Member
 
crestron's Avatar
 
Join Date: Feb 2007
Posts: 22
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 10
Quote:
Originally Posted by fhoech View Post
This release brings HDR 3D LUT (BT.2020 & ST.2084) improvements, namely roll-off according to BT.2390 (hermite spline at the top end, black level lift similar to BT.1886 but with tapering factor at the dark end) and a simple form of tone mapping.

Example screen capture of Sony "Camp" HDR demo @ 400 cd/m2 peak luminance (TV gamut roughly Rec. 709):


How to set up DisplayCAL to create a HDR to SDR 3D LUT:

Set HDR peak luminance according to the capability of your display. I wouldn't recommend below 265 cd/m2.
Black output offset controls if there's roll-off at the dark end (0% black output offset = BT.2390), which is similar to BT.1886, or if the whole curve is offset and scaled by the black level (100% output offset).

I've also tweaked the perceptual intent gamut mapping to give better preservation of saturated colors than normally, but I would still recommend colorimetric as it should preserve saturations even better (the above screen capture is from a colorimetric 3D LUT). Note that despite colorimetric normally clipping, there's now always a form of tone mapping when SMPTE 2084 roll-off is selected.

Enjoy!
I use this way to build the 3dlut file,
Can be "convert HDR to SDR content by using an external 3DLUT" application,
Can not be "process HDR content by using an external 3DLUT" application,
Tip is "input and output format wrong", do not know where the problem?
how do it?
Attached Thumbnails
Click image for larger version

Name:	微信截图_20170414085843.jpg
Views:	33
Size:	34.6 KB
ID:	2083129   Click image for larger version

Name:	微信截图_20170414085956.jpg
Views:	34
Size:	52.1 KB
ID:	2083137  

Last edited by crestron; 04-13-2017 at 06:02 PM.
crestron is offline  
post #4551 of 4655 Old 04-25-2017, 09:51 PM
Newbie
 
Join Date: Mar 2016
Posts: 5
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 0
I had questions regarding the calibration of Sony LED TV W800B:
  • For a bat cave dark room calibration, what should be the white level setting? 100 nits looks too bright. While playing with the backlight setting of the TV, I seemed to like the setting which gave 66 nits white level in the dark room. Can such a low white level affect the quality of calibration?
  • How should the brightness setting of the TV be adjusted before profiling?
  • I have just got a colorimeter (i1 Display Pro) and don’t have any spectrophotometer. So I cannot generate a display specific correction for the colorimeter. Still, should I be using any correction file for this TV or just stay with Auto (None)? The TV has an edge lit White LED VA Panel.
  • I wanted to do calibration for 10 bit output. I have set 10 bit output mode in the GPU settings. If I set the native display bitdepth “10 bit (or higher)” in madVR settings, will madTPG output 10 bit then?
omarank is offline  
post #4552 of 4655 Old 05-09-2017, 03:42 PM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 866
Mentioned: 39 Post(s)
Tagged: 0 Thread(s)
Quoted: 432 Post(s)
Liked: 283
Quote:
Originally Posted by crestron View Post
I use this way to build the 3dlut file,
Can be "convert HDR to SDR content by using an external 3DLUT" application,
Can not be "process HDR content by using an external 3DLUT" application,
Tip is "input and output format wrong", do not know where the problem?
how do it?
It is not possible currently. Now that a HDR metadata passthrough is finally available in Windows and madVR, it's probably time to revisit this. @madshi , what does the header of a 3D LUT need to look like for HDR metadata passthrough (as a side thought, I'm not even sure the distinction makes sense - the only difference between HDR mode on and off from a profiling point of view is how the display is setup, which is transparent to the profiler and any 3D LUT consumer, so I would assume the only option needed would be whether to pass HDR metadata or not)?

Quote:
Originally Posted by omarank View Post
I had questions regarding the calibration of Sony LED TV W800B:

For a bat cave dark room calibration, what should be the white level setting? 100 nits looks too bright. While playing with the backlight setting of the TV, I seemed to like the setting which gave 66 nits white level in the dark room. Can such a low white level affect the quality of calibration?
I'm using around 50 in a dark room. You need a meter that is capable to deal with low light situations, because lowering peak white also lowers the black level on a LCD display (unless you sacrifice contrast). An instrument out of the i1D3 family should be fine. Other than that, there are no quality considerations.

Quote:
Originally Posted by omarank View Post
I have just got a colorimeter (i1 Display Pro) and don’t have any spectrophotometer. So I cannot generate a display specific correction for the colorimeter. Still, should I be using any correction file for this TV or just stay with Auto (None)? The TV has an edge lit White LED VA Panel.
Use the X-Rite generic correction for White LED ("Spectral: White LED (Samsung, ...)" in DisplayCAL.

Quote:
I wanted to do calibration for 10 bit output. I have set 10 bit output mode in the GPU settings. If I set the native display bitdepth “10 bit (or higher)” in madVR settings, will madTPG output 10 bit then?
I would assume so.

--

Btw, DisplayCAL 3.2.6 Beta is available (see signature). Feedback welcome (there are no 3D LUT specific changes, although the next beta will probably offer HLG as additional HDR standard. Also thinking about adding Philips HDR in the future, but there doesn't seem to be any demo material freely available, and I'm not sure how wide-spread that format will be).

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.3.5 released 2017-10-18
Previous development snapshot (OUTDATED): 3.2.9 Beta (Windows/0install) released 2017-05-23 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4553 of 4655 Old 05-09-2017, 11:00 PM
Newbie
 
Join Date: May 2017
Posts: 2
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 0
I've calibrated monitor in DisplayCal 3.2.0 for 3DLUT (MadVR ladt version) and find out in PotPlayer and MPC-HC renderer MadVR doesn't use 3DLUT profile. Gamma becomes linear when play movie. When I use soft to make profile load to LUT every 1 second, HCFR gives green figures, but it is not 3DLUT, only 1DLUT and not correct.
All done according to simple instruction at p.1, game with check and uncheck at 'calibration' menu MadVR, recalibrations gives no. Calibration is OK, liading profile at DispCal and MadVR renderer is OK, but gamma becomes linear.
Os XP 64 and Win 7 Pro 64, Potplayer 32 vit and MPC-HC 64 bit.
Where is the problem I don't imagine. On TV says that's Trump's effect. After four days dating with calibrator... I don't know...
SOS, I watch TV without 3DLUT and lose something impotent.
Urshak is offline  
post #4554 of 4655 Old 05-10-2017, 01:55 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Quote:
Originally Posted by fhoech View Post
It is not possible currently. Now that a HDR metadata passthrough is finally available in Windows and madVR, it's probably time to revisit this. @madshi , what does the header of a 3D LUT need to look like for HDR metadata passthrough (as a side thought, I'm not even sure the distinction makes sense - the only difference between HDR mode on and off from a profiling point of view is how the display is setup, which is transparent to the profiler and any 3D LUT consumer, so I would assume the only option needed would be whether to pass HDR metadata or not)?
For the madVR option "convert HDR content to SDR by using an external 3dlut", the 3DLUT must have "Input_Transfer_Function PQ" in the header, I think, but no "Output_Transfer_Function" specified, or at least not set to "PQ". This tells madVR that this 3DLUT wants to get PQ data as input, and that the output of the 3DLUT requires the display to be in SDR mode to look right.

For the madVR option "process HDR content by using an external 3dlut", the 3DLUT must have both "Input_Transfer_Function PQ" and "Output_Transfer_Function PQ" in the header. This tells madVR that this 3DLUT wants to get PQ data as input, and that the 3dLUT output requires the display to be in HDR mode to look right.

Probably, when profiling the display, from your point of view it doesn't even matter which transfer curve the display is calibrated to, because you're measuring it, and it can be either gamma or PQ or something entirely different. It doesn't even matter, right? So from this point of view, it probably doesn't make much sense for you to specify the "Output_Transfer_Function". Rather you'd probably want to set it to something like "Output_Transfer_Function AsMeasured", or something like that. However, madVR needs to know into which mode (SDR vs HDR) it should switch the display, for the 3DLUT to produce correct results. So it needs to be written into the 3DLUT header.

We also added the option for users to use a non-profiled 3DLUT to do HDR processing. Such a 3DLUT does not actually involve measuring the display, but it simply converts PQ RGB data to Gamma RGB data. This is useful because your offline conversion might be slightly higher quality than what madVR calculates in realtime. Furthermore, the realtime pixel shader code is slower than running the data through a 3DLUT. So this approach makes sense.

Now imagine a user who has an HDR display, but no meter. He can't properly calibrate his display, but he might want to use DisplayCAL's high quality HDR processing capabilities to do tone mapping, because his display's tone mapping might have bad quality. So the user may want to let DisplayCAL convert the original HDR PQ data (e.g. 1000 nits DCI-P3) down to e.g. 120nits BT.709. But he might still want the display to activate its internal HDR mode, because in HDR mode it might run the backlight/lamp in "overdrive" mode to get more brightness etc. In this situation, the DisplayCAL 3DLUT gets PQ data as input, and should also still output PQ data, but the 3DLUT should perform some tone and gamut mapping, according to the user's wishes. So in this situation the 3DLUT should have "Output_Transfer_Function PQ" in the header.

To sum it all up: If you set "Output_Transfer_Function PQ", madVR will switch the display into HDR mode. Otherwise madVR will switch the display into SDR mode. The madVR option "convert HDR content to SDR by using an external 3dlut" requires "Output_Transfer_Function" to not be set, or at least not to PQ. The madVR option "process HDR content by using an external 3dlut" requires "Output_Transfer_Function" to be set to "PQ".

Hope all is clear now?
madshi is offline  
post #4555 of 4655 Old 05-10-2017, 10:10 AM
Newbie
 
Join Date: Mar 2016
Posts: 5
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 0
Quote:
Originally Posted by fhoech View Post
I'm using around 50 in a dark room.
Ok. I tried 50 nits and it definitely looks more easy on the eyes than 66 nits in the dark room without looking dim. What peak level do you recommend for HDR 3DLUT when the HDR content has to be viewed in completely dark room?
omarank is offline  
post #4556 of 4655 Old 05-12-2017, 04:54 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 866
Mentioned: 39 Post(s)
Tagged: 0 Thread(s)
Quoted: 432 Post(s)
Liked: 283
Quote:
Originally Posted by madshi View Post
To sum it all up: If you set "Output_Transfer_Function PQ", madVR will switch the display into HDR mode. Otherwise madVR will switch the display into SDR mode. The madVR option "convert HDR content to SDR by using an external 3dlut" requires "Output_Transfer_Function" to not be set, or at least not to PQ. The madVR option "process HDR content by using an external 3dlut" requires "Output_Transfer_Function" to be set to "PQ".
That's what I was getting at, for admittedly slightly selfish reasons I would have preferred this to be an option in madVR only instead of requiring a different 3D LUT header (because apart from the small header difference, the 3D LUT will be exactly the same, independent of whether it's for an HDR display or not) and thus having to add yet another UI element (for the HDR mode/non HDR mode header choice) to an already fairly complex interface in DisplayCAL

Quote:
Originally Posted by omarank View Post
Ok. I tried 50 nits and it definitely looks more easy on the eyes than 66 nits in the dark room without looking dim. What peak level do you recommend for HDR 3DLUT when the HDR content has to be viewed in completely dark room?
ST.2084 is an absolute curve, i.e. each encoded digital level maps to a specific output luminance. It's no problem to adjust the output, just keep in mind that you then move away from "strict" ST.2084. Generally I would recommend not going much below 400 nits HDR peak luminance for the 3D LUT (irrespective of what your display is capable of). If your display can do a max of (say) 400 nits as well, and you want to keep the same ratio as for SDR (i.e. 50% in your case with 50 nits, assuming 100 nits nominal), then you could double the HDR peak luminance (e.g. 800 instead of 400) to get the desired contrast adjustment (with the display actually calibrated to 400).

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.3.5 released 2017-10-18
Previous development snapshot (OUTDATED): 3.2.9 Beta (Windows/0install) released 2017-05-23 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4557 of 4655 Old 05-12-2017, 05:24 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
Quote:
Originally Posted by fhoech View Post
because apart from the small header difference, the 3D LUT will be exactly the same, independent of whether it's for an HDR display or not
That's true only for users who have a meter and actually profile their display.

Please also think about those users who use DisplayCAL to create a simple HDR processing 3dlut which doesn't involve any calibration/profiling. For those the 2 different 3DLUTs will be *totally* different (not just the header, but all the 3dlut data, too), because one will convert PQ to gamma, while the other will not. That's a pretty dramatic difference.
madshi is offline  
post #4558 of 4655 Old 05-12-2017, 06:31 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 866
Mentioned: 39 Post(s)
Tagged: 0 Thread(s)
Quoted: 432 Post(s)
Liked: 283
Quote:
Originally Posted by madshi View Post
That's true only for users who have a meter and actually profile their display.
Not really, it doesn't matter at all whether the destination profile was created from actual measurements or not.

Quote:
Originally Posted by madshi View Post
Please also think about those users who use DisplayCAL to create a simple HDR processing 3dlut which doesn't involve any calibration/profiling. For those the 2 different 3DLUTs will be *totally* different (not just the header, but all the 3dlut data, too), because one will convert PQ to gamma, while the other will not. That's a pretty dramatic difference.
But the same is true whether or not you actually measure a display, a 3D LUT that's created with a "HDR/PQ" destination profile (synthetic or not) will simply not yield the correct result if it's used with the display in SDR mode (and vice versa, i.e. SDR destination profile and actual display in HDR/PQ mode). It's really the same situation with SDR, if you use a gamma X destination profile to create a 3D LUT for an actual gamma Y display.

Whether the correct 3D LUT header is written or not is up to user choice and is not influenced at all by the destination profile. Automatically detecting whether the destination is an actual HDR display or not (in which case the user choice could be omitted and the correct header could be written automatically) does not seem easily possible at the point when the 3D LUT is created (what would be the detection criteria? Assumed or measured peak brightness? How close the transfer function is to PQ? What about roll-off and clipping, in which case we would need to test for various combinations of black level, peak brightness and roll-off/clipping strategies to do - probably not very reliable - detection, etc).

So, if it comes down to the user making the correct choice anyway, all that the header distinction does is adding another user choice in a different program that really only does one thing, which is duplicating said user choice from madVR (as the UI to make that distinction is already there in the latter).

Another thing that came to mind, is it currently possible to tell madTPG to put a display in HDR mode (provided the latter is capable of course)?

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.3.5 released 2017-10-18
Previous development snapshot (OUTDATED): 3.2.9 Beta (Windows/0install) released 2017-05-23 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4559 of 4655 Old 05-12-2017, 06:47 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 6,107
Mentioned: 50 Post(s)
Tagged: 0 Thread(s)
Quoted: 621 Post(s)
Liked: 602
I'm confused right now. I don't think we're on the same page.

Situation A):

The user does not have a meter. He has an HDR display, but the display's tone mapping sucks, so he wants madVR to convert HDR videos to SDR, so the TV doesn't even know it's displaying HDR content. The user has the choice to either let madVR do the HDR -> SDR conversion by using pixel shader math, which works well but costs a lot of GPU performance. Alternatively the user can create a HDR -> SDR conversion 3dlut. This 3dlut receives PQ data on the input side, and outputs 2.222 gamma data on the output side. The 3dlut converts to a gamut the user selected (e.g. BT.709), using a peak display luminance value the user selected (e.g. 400 nits).

So in short: The 3dlut input is PQ BT.2020 10000 nits. The 3dlut output is Gamma 2.222 BT.709 400 nits.

Situation B):

The user does not have a meter. He has an HDR display, but the display's tone mapping sucks. However, the display has a special HDR mode which squeezes some additional brightness out of the backlight, so the user wants to put the display into HDR mode. But the user still wants the tone mapping to be done by madVR. The user has the choice to either let madVR do the tone mapping by using pixel shader math, which works well but costs a lot of GPU performance. Alternatively the user can create a HDR -> HDR conversion 3dlut. This 3dlut receives PQ data on the input side, and outputs PQ data on the output side. The 3dlut tone maps the source's BT.2020 (or DCI-P3) gamut to a gamut the user selected (e.g. BT.709), using a peak display luminance value the user selected (e.g. 400 nits).

So in short: The 3dlut input is PQ BT.2020 10000 nits. The 3dlut output is PQ BT.709 400 nits.

-------

Do you agree with me that the two 3dluts from situation A) and B) are *TOTALLY* different? Not only the header is different, but also the 3dlut data is totally different. If you agree with that, then it follows logically that the only way for the user to create 3dluts for situation A) and B) is that DisplayCAL needs to offer an option to create a 3dlut for either situation A) or B). Right?

Whether or not the header contains a flag that identifies a 3dlut as being A) or B) doesn't even matter much here. I don't see how DisplayCAL would possibly know whether to create a 3dlut for situation A) or B) if DisplayCAL doesn't have an option which lets the user choose A) or B)?

-------

All that said, DisplayCAL currently only supports A), and if you don't want to add support for B) that's ok with me. But if you do want to support option B) then I don't see how you could possibly do that without giving the user a control to choose if he wants A) or B)?

Or am I missing something obvious?

P.S: madTPG doesn't support HDR yet, planned for a future version.
madshi is offline  
post #4560 of 4655 Old 05-12-2017, 06:55 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 866
Mentioned: 39 Post(s)
Tagged: 0 Thread(s)
Quoted: 432 Post(s)
Liked: 283
Quote:
Originally Posted by madshi View Post
Do you agree with me that the two 3dluts from situation A) and B) are *TOTALLY* different? Not only the header is different, but also the 3dlut data is totally different. If you agree with that, then it follows logically that the only way for the user to create 3dluts for situation A) and B) is that DisplayCAL needs to offer an option to create a 3dlut for either situation A) or B). Right?
Yes, but that option is already there (or rather, there is nothing special necessary to support this, all the user needs to do is measure the display in HDR mode, or create a synthetic HDR destination profile), the only thing missing is the correct header so the user can actually create a 3D LUT that madVR will accept in situation B).
The only thing DisplayCAL currently can't do is switch the display into HDR mode itself automatically during measurements in case you want to create a profile from actual measurements.

Quote:
Originally Posted by madshi View Post
P.S: madTPG doesn't support HDR yet, planned for a future version.
Cool, Argyll CMS will need to support it as well in dispcal/dispread before I can implement support in DisplayCAL anyway (although I could hack around that limitation).

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.3.5 released 2017-10-18
Previous development snapshot (OUTDATED): 3.2.9 Beta (Windows/0install) released 2017-05-23 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
Sponsored Links
Advertisement
 
Reply Display Calibration

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

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
Trackbacks are Off
Pingbacks are Off
Refbacks are Off