or Connect
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS
New Posts  All Forums:Forum Nav:

# MadVR - ArgyllCMS - Page 23

Can a 3dlut loaded into madvr correct the colours in a wide gamut display?

l mean, when you played a video in a wide gamut display, the will loook oversharper or oversatured, very unrealistic colours.

A 3dlut will correct this in madvr and displkay correct colours?

### AVS Top Picks

Could you guys tell me which is the right pattern to check the accuracy of Saturation Sweep? My 3dLut didn't give me the results I was expecting

Also, I found out that I need DispCalGUI to use Gamma 2.2 instead of sRGB to give me better blacks, the method of this topic use sRGB, if I understand correctly. Is there a way to change that?

Thanks!
Quote:
Originally Posted by Alec246

Could you guys tell me which is the right pattern to check the accuracy of Saturation Sweep?

For the patterns, I use the mp4 or mkv patterns located here

http://www.avsforum.com/t/1406352/gcd-gamut-calibration-disk
Quote:
Originally Posted by N3W813

For the patterns, I use the mp4 or mkv patterns located here

http://www.avsforum.com/t/1406352/gcd-gamut-calibration-disk

Thank you. This confirmed that this is not working for me. The Saturation sweeps are horrible... No idea why.

Anyone have any idea why I'm getting some pretty bad DeltaE 2000 between 20% and 80%, while 100% is perfect? I thought the 3dLut was supposed to correct through all the range, not just the 100%.

Edit 2: I'm definetely using the pattern through MadVR wrong. Because using CalPC to check my monitor, I get better DeltaE 2000...
Edited by Alec246 - 8/26/13 at 3:12pm
Alec246, Do you ude CalPC to create a ICC?, i was using it but dont know why every time that l do a calibration the firefox screen gets all blue, every time, no idea why.
Quote:
Originally Posted by onaga

Alec246, Do you ude CalPC to create a ICC?, i was using it but dont know why every time that l do a calibration the firefox screen gets all blue, every time, no idea why.

No, my ICC profile was created using DispCalGUI and Argyll. I only use Calman to measure the results. And when I created my .3dlut I was using no ICC profile loaded into the system.

When you use Firefox with a ICC, you have to change certain options that are hidden. See this link

http://www.metalvortex.com/blog/2012/03/16/831.html
Hmm, I'm not having any luck using ArgyllCMS with the MadVR pattern generator - when I try it with dispcal, dispcal just crashes. I've made sure that madVR is registered and that the pattern generator was actually running and visible, and used the exact command line that the first post recommends. When I remove -dmadvr it works, so it's definitely related to madVR in particular.

Edit: Ah! The 32-bit version of ArgyllCMS does work. That's a pity, I'd prefer to use the 64-bit version for building the profile..
Ah yes, gotta admit, madVR is currently limited to 32bit. There might be support for 64bit coming *just for the test pattern stuff*, though, much earlier than a full 64bit madVR version. That's why I renamed "madHcNet.dll" to "madHcNet32.dll" when I released the first version of the test pattern generator. Argyll uses this dll to control the TPG. So I "only" have to create a 64bit version of this one dll to make it possible for 64bit processes to control the TPG. It's still not at the top of my to do list, though...

Edit:

@Graeme: As long as there's no madHcNet64.dll available, it might make sense for the 64bit Argyll version to deny the -dmadvr switch and report that the switch only works in 32bit (for now). Also, it seems that there can be crashes when BlindConnect() fails, for whatever reason. Could you check whether those crashes are inside your code or mine? If it's in my dll, then I should look at why it crashes and fix that. If the crash is in your code, then maybe you could fix it. Thanks...
Edited by madshi - 8/28/13 at 8:28am
I realized that there's nothing stopping me from simply using the 64-bit tools for the actual profile creation, since that aspect of things is separate from any measurement. So it's not ideal, but I'm not missing out on any functionality or performance either.

Graeme: Are there any guidelines for how much memory colprof will end up using for the inverse lookup acceleration grid given the ARGYLL_REV_ACC_GRID_RES_MULT environment variable? What kind of range is worthwhile for that variable assuming memory isn't a concern?
Edited by VerGreeneyes - 8/28/13 at 5:43pm
Quote:
Originally Posted by onaga

Can a 3dlut loaded into madvr correct the colours in a wide gamut display?

l mean, when you played a video in a wide gamut display, the will loook oversharper or oversatured, very unrealistic colours.

A 3dlut will correct this in madvr and displkay correct colours?

Yes.
Quote:
Originally Posted by Alec246

Anyone have any idea why I'm getting some pretty bad DeltaE 2000 between 20% and 80%, while 100% is perfect? I thought the 3dLut was supposed to correct through all the range, not just the 100%.
Not really, since I've no idea what colors you are testing with. Are they black to 100% primaries ? White to primaries ? Grey to primaries ?

If it's one of the first two, then my guess would be that they are out of gamut, and you are seeing the effects of gamut clipping.
Quote:

@Graeme: As long as there's no madHcNet64.dll available, it might make sense for the 64bit Argyll version to deny the -dmadvr switch and report that the switch only works in 32bit (for now).
I'll switch the code to look for madHcNet64.dll if it's been compiled 64 bit. It should error out if it can't find it. I've got no schedule for releasing the change at the moment though.
Quote:
Also, it seems that there can be crashes when BlindConnect() fails, for whatever reason. Could you check whether those crashes are inside your code or mine? If it's in my dll, then I should look at why it crashes and fix that. If the crash is in your code, then maybe you could fix it. Thanks...
I'm not sure how to do that without a repeat by. The return value from BlindConnect() is checked, and it should simply error out if it fails.
Edited by gwgill - 8/31/13 at 1:17am
Quote:
Originally Posted by VerGreeneyes

Graeme: Are there any guidelines for how much memory colprof will end up using for the inverse lookup acceleration grid given the ARGYLL_REV_ACC_GRID_RES_MULT environment variable?
Not really. There are several bits that use memory, and it all interacts with the various settings.

The two main parts are the reverse lookup acceleration grid, and the calculation cache.

You can potentially increase the grid resolution but you will get to the point of diminishing returns, due to the computation time to set it up, and the fact that while it narrows down the inversion search, there will be a minimum number of cells that it will return.

The calculation cache helps when the inverted grid resolution is about the same or higher than the forward grid, since it avoids the heavy numerical work of inverting the forward cells interpolation when more than one query hits the same cell. The bigger the cache, the less chance that something will have to be recomputed, but there will be a point of diminishing returns.
Quote:
What kind of range is worthwhile for that variable assuming memory isn't a concern?
If you want to figure it out, try different combinations of larger ARGYLL_REV_ACC_GRID_RES_MULT and ARGYLL_REV_CACHE_MULT in something like 30% increments (ie. 1.3, 1.7, 2.0). That would be 16 combinations in itself, but there is no point in going beyond the optimum for each individual value.
Edited by gwgill - 8/31/13 at 1:17am
Graeme: Thanks for the information - I might experiment with the timing a bit, but I guess I'm not that concerned with it (I think I got more of a win out of switching to the 64-bit version).

I was wondering: how well do the profiles included in the 'ref' folder of ArgyllCMS line up with the five types in madVR's 3DLUT settings. I assume that BT.709 -> Rec709.icm and BT.2020 -> Rec2020.icm, but what about the others? Opening SMPTE431.icm shows it should correspond with DCI-P3, but does EBU3213_PAL.icm match up with EBU/PAL? And I don't think anything matching SMPTE C is included, unless that's SMPTE_RP145_NTSC.icm.

Finally, is it possible there's a bug in the 3DLUT generation when '-G -ip' (link with perceptual intent) is used? The output seems to require expansion from 16-235 to 0-255 when '-et -Et' is used to look correct (a way I found to do this was to simply omit the '-Et' parameter). With '-iaw' and several other variations, the output looks correct (I get some odd behavior with dark shades, but the range itself looks correct).
Edited by VerGreeneyes - 9/1/13 at 12:12am
A kind of silly question but can't seem to find a definite answer.

Is re calibration required if I change the source computer? The signal will be HDMI/digital regardless.
Quote:
Originally Posted by gwgill

Not really, since I've no idea what colors you are testing with. Are they black to 100% primaries ? White to primaries ? Grey to primaries ?

If it's one of the first two, then my guess would be that they are out of gamut, and you are seeing the effects of gamut clipping.

This is far too technical for me! Here's the screen capture of Calman after taking readings from a Calibration Sweep using MadVR with the .3dlut loaded.

And here's the monitor without any .3dlut correction loaded.

DeltaE seems much better!
Quote:
Originally Posted by baii

A kind of silly question but can't seem to find a definite answer.

Is re calibration required if I change the source computer? The signal will be HDMI/digital regardless.

Yes, defintely if the video hardware and/or driver has changed. I calibrate and profile if I change the video card and drivers. I would definitely go through the workflow again if you swapped out the computer.
Quote:
Originally Posted by Alec246

This is far too technical for me! Here's the screen capture of Calman after taking readings from a Calibration Sweep using MadVR with the .3dlut loaded.

The hue and saturation do not seem like the cause of the large errors in red, magenta, and blue. Can you check each of those points and see what the values are for DeltaL?
In an effort to simply the 3DLUT generation process for MadVR, I have written simple batch scripts to help assist the non-technical users. The scripts will guide you step-by-step through the 3DLUT generation and verification process using ArgyllCMS and MadVR TPG. The batch scripts have been created using commands and parameters suggested by Graeme Gill and Madshi.

Install guide:
1. Extract the zip file to any directory on the source machine
2. Copy the 'bin' and 'ref' folders from ArgyllCMS (*32-bit only) install folder to the zip extraction folder
3. Start MadVR TPG and disable 'VideoLUT' and '3dlut'
4. Execute scripts from 1 through 8

Folders in the zip:
.\3DLUT - Folder for the generated 3DLUT for MadVR
.\bin - Binaries for ArgyllCMS
.\logs - Log files for each of the batch scripts
.\output - Output files generated and used by ArgyllCMS
.\ref - Reference files from ArgyllCMS

The '0.Reset.bat' file will copy last generated 3DLUT, logs, and output files to the backup directory respectively in each of the folders. You can use this to restart the process.

These scripts are a work-in-progress. Please report any issues.

FWIW, I seem to get much better results on dark shades with the following settings for collink:
Code:
collink.exe  -v  -3m  -qh  -et  -Ib:2.2  -G  -a dispcal.cal  -ip  Rec709.icm  MadVR.icm  3DLUT.icm


The difference is that I use the perceptual intent (-ip) and leave out -Et (because perceptual seems to need stretching from 16-235 -> 0-255 otherwise, which might be a bug).
Quote:
Originally Posted by VerGreeneyes

I was wondering: how well do the profiles included in the 'ref' folder of ArgyllCMS line up with the five types in madVR's 3DLUT settings. I assume that BT.709 -> Rec709.icm and BT.2020 -> Rec2020.icm, but what about the others? Opening SMPTE431.icm shows it should correspond with DCI-P3, but does EBU3213_PAL.icm match up with EBU/PAL? And I don't think anything matching SMPTE C is included, unless that's SMPTE_RP145_NTSC.icm.
You're asking the wrong person - you can easily see what the ICC profiles are doing and the names derive directly from the standards they are implemented from, while what MadVR is doing is opaque (no source code), so you need to ask madshi that question.
Quote:
Finally, is it possible there's a bug in the 3DLUT generation when '-G -ip' (link with perceptual intent) is used? The output seems to require expansion from 16-235 to 0-255 when '-et -Et' is used to look correct (a way I found to do this was to simply omit the '-Et' parameter). With '-iaw' and several other variations, the output looks correct (I get some odd behavior with dark shades, but the range itself looks correct).
I doubt there is any such bug, since the two pieces of code are orthogonal. Testing -ir vs. -ip on my systems showed a slight change in appearance, but nothing like a change in video range - the black and white values remained the same. If you have a concrete example of a problem (such a black and/or white values changing), then I'm happy to look into it.

BTW. there seems to be a bug in the way MadTPG disables the 3dLut that could have a serious effect on measurements made using dispread. This bug may be throwing a lot of confusion into things.
Edited by gwgill - 9/1/13 at 6:11pm
Quote:
Originally Posted by baii

A kind of silly question but can't seem to find a definite answer.

Is re calibration required if I change the source computer? The signal will be HDMI/digital regardless.
You shouldn't have to, no, since it's all digital and the processing should all be the same. But keep in mind that it is possible that something could change that affects the output, if (for instance) the graphics card is doing some sort of "special processing" or the way it interacts with the TV changes (ie. 16-235 video level handling), or some other aspect isn't set identically.
Quote:
Originally Posted by Alec246

This is far too technical for me! Here's the screen capture of Calman after taking readings from a Calibration Sweep using MadVR with the .3dlut loaded.
I don't have Calman, and the screen captures don't reveal what's being tested, so I really can't help you.

Keep in mind that video reproduction isn't precisely defined, so "verifying" a system that is aiming at one thing using a different system that assumes you are aiming at something else, will always show a discrepancy.

There is a verification workflow that detailed in the ArgyllCMS tutorial if you wish to avoid this sort of issue.
Quote:
Originally Posted by VerGreeneyes

FWIW, I seem to get much better results on dark shades with the following settings for collink:
Code:
collink.exe  -v  -3m  -qh  -et  -Ib:2.2  -G  -a dispcal.cal  -ip  Rec709.icm  MadVR.icm  3DLUT.icm


The difference is that I use the perceptual intent (-ip) and leave out -Et (because perceptual seems to need stretching from 16-235 -> 0-255 otherwise, which might be a bug).

I get slightly better results on dark shades and gamma as well using this.
Quote:
Originally Posted by gwgill

I doubt there is any such bug, since the two pieces of code are orthogonal. Testing -ir vs. -ip on my systems showed a slight change in appearance, but nothing like a change in video range - the black and white values remained the same. If you have a concrete example of a problem (such a black and/or white values changing), then I'm happy to look into it.
Alright, I actually got myself a test pattern, and here's what I see:

collink.exe -v3 -3m -qu -G -Ib:2.2 -iaw -et -Et Rec709.icm profile.icm 3DLUT.icm
collink.exe -v3 -3m -qu -G -Ib:2.2 -ip -et -Et Rec709.icm profile.icm 3DLUT.icm
collink.exe -v3 -3m -qu -G -Ib:2.2 -ip -et Rec709.icm profile.icm 3DLUT.icm

So dropping -Et is definitely wrong, despite making the sample I was looking at before look much better, but you can also clearly see that using -ip raises the black level substantially. Note that there are 200 black pixels on the left side of the gradient, and 200 white pixels on the right side.
Quote:
Originally Posted by gwgill

BTW. there seems to be a bug in the way MadTPG disables the 3dLut that could have a serious effect on measurements made using dispread. This bug may be throwing a lot of confusion into things.
I think I'll repeat calibration and profiling tomorrow just to make sure this didn't cause the problems I saw with -iaw, though I doubt it'll solve the -ip black level problem.

Edit: Actually, I don't see the same difference on my laptop, so there might be something weird about this profile. Let me know if you'd like me to attach it.
Edited by VerGreeneyes - 9/2/13 at 6:45pm
So, madshi's suggested -iaw -et -Et is the correct method? TV levels in and out?
Quote:
Originally Posted by paulkono

So, madshi's suggested -iaw -et -Et is theI correct method? TV levels in and out?
I don't recommend -aw since the white point can be slightly misaligned between calibration and profiling. -ir is better in that it leaves the white point determination strictly to the calibration.
That might be so in theory, but in my experience -iaw simply produces "better" results compared to -ir, and that has been confirmed by some other users, too. Maybe it depends on how much gamut clipping there is (quite a lot in my case). Maybe -ir works better if the display is able to handle the full source gamut without clipping. I don't know. I can only say what worked best for me.
Quote:
Originally Posted by paulkono

So, madshi's suggested -iaw -et -Et is the correct method? TV levels in and out?
As far as the -et -Et part goes, yes. In terms of gamut clipping I got the most visually pleasing result with -ip, but that may have been because of the mysteriously raised black level. I'm reprofiling my desktop monitor today and seeing if that remains.

Edit: Welp, I repeated calibration and profiling and made new 3DLUTs.. and now the situation is reversed! -ip now has the correct, dark black and -iaw now has the raised black level. So uh, just use whichever works for you I guess.

Edit2: Got another profile and averaged it together with the last one (using 'average' from ArgyllCMS), and now -iaw and -ir win compared to -ip again. So there must be something finicky about these profiles.

Edit3: Averaged together 4 profiles, and now a gradient test I have looks the same for -iaw, -ir and -ip. Testing a movie, -iaw and -ir look the same; -ip has a higher black level, but -iaw and -ir look a bit grainy near black (which might be correct). Not sure if I'll try to go for 8 profiles considering how long each of these takes to get, but the fact that the situation keeps changing does kind of intrigue me.
Edited by VerGreeneyes - 9/4/13 at 6:57pm
I will show what results I achieve with:
Code:
dispwin.exe -v -c

dispcal.exe -v -qh -X WLEDFamily_07Feb11.ccss -gs -w 0.3127,0.3290 "dispcal"

targen.exe -v -d3 -G -s40 -g128 -f2000 "MadVR"

colprof.exe -v -qh -bl -aX "MadVR"

collink.exe -v -3m -qh -et -Et -Ib:2.2 -G -a dispcal.cal -iaw Rec709.icm MadVR.icm 3DLUT.icm


GFX, TV and madVR set to 0-255

Someone who can tell what is going wrong?
New Posts  All Forums:Forum Nav:
Return Home
Back to Forum: Display Calibration

### AVS Top Picks

AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS