MadVR - ArgyllCMS - Page 46 - AVS Forum
Forum Jump: 
 57Likes
Reply
 
Thread Tools
post #1351 of 2777 Old 12-28-2013, 07:29 AM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
for what it's worth, here is what my grayscale looks like without dispcal (based on a 2 or 3 point grayscale adjustment written to the EEPROM).




The ridiculously low delta E at 10% are because the formula takes into account lightness, and as you can see, the display is pretty crushed. I later increased the OSD contrast to max, and the new white luminance is just over 100 cd/m2.
spacediver is online now  
Sponsored Links
Advertisement
 
post #1352 of 2777 Old 12-28-2013, 07:39 AM
Member
 
VerGreeneyes's Avatar
 
Join Date: May 2013
Posts: 112
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by spacediver View Post

Is there an option to have it just try to meet D65 at each step (except for the first step, where doing so would raise the black level), instead of this gradual "chromaticity blending" method? (I may have misunderstood what you meant, however).
dispcal uses a power function to determine how much weight to give to the chromaticity of white and that of black at each point - by default the power it uses is 4, but you can adjust the power with the -A flag. A power of 1 will make it cross over from the chromaticity of white to black linearly, whereas higher powers will have a more rapid crossover near black. So if you just want it to maintain the chromaticity of white everywhere except at black, pass it some high number (-A16, say).
Quote:
Originally Posted by spacediver View Post

If you limited the range of your LUT, then you'd leave these "walls" uncorrected! What am I missing here?
Sorry, I think I was unclear here. What I mean is that the output LUT will start at RGB(0.1,0.1,0.1) and end at RGB(0.9,0.9,0.9) because anything below or above these values will look the same anyway. It doesn't actually enforce this, but the fit will naturally converge to limits at the edges of the black and white walls.
Quote:
Originally Posted by spacediver View Post

I have a feeling I'm conflating bit depth with precision. Is 16 bit precision doing the calculations in 16 bit to avoid accumulation of rounding errors, and then presenting the final result in an 8 bit depth?
In Windows, the videoLUT APIs all take 3x256 16-bit unsigned integers (so in the range 0-65535) - but there's nothing to guarantee the display or graphics card (whichever is responsible for applying the values; I'm not sure which) use the full 16 bits internally in their calculations. I would imagine that the graphics card takes care of it for VGA and can use the full 16-bit values, but that's just a guess. On LCDs with a digital interface, I think the monitor is responsible for applying the LUT, but they tend to use 8-bit or even 6-bit values to set the transparency of each subpixel. They can approximate the full 16-bit values using dithering, but whether they do probably varies between monitors.

Note also that there's a potential mismatch here between the way dispcal measures its corrections using dispwin or madVR, and the precision with which the videoLUT will get applied. madVR uses high precision processing internally and uses dithering when displaying the test patches, but that dithering may be different from what your display ends up doing with the videoLUT.
VerGreeneyes is online now  
post #1353 of 2777 Old 12-28-2013, 08:05 AM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
Quote:
Originally Posted by VerGreeneyes View Post

dispcal uses a power function to determine how much weight to give to the chromaticity of white and that of black at each point - by default the power it uses is 4, but you can adjust the power with the -A flag. A power of 1 will make it cross over from the chromaticity of white to black linearly, whereas higher powers will have a more rapid crossover near black. So if you just want it to maintain the chromaticity of white everywhere except at black, pass it some high number (-A16, say).

Fantastic, thanks. Sorry, I should have read the documentation more carefully - this was stated very clearly in it!
Quote:
Originally Posted by VerGreeneyes View Post

Sorry, I think I was unclear here. What I mean is that the output LUT will start at RGB(0.1,0.1,0.1) and end at RGB(0.9,0.9,0.9) because anything below or above these values will look the same anyway. It doesn't actually enforce this, but the fit will naturally converge to limits at the edges of the black and white walls.

Perhaps I don't understand LUTs as well as I thought. My model of how it all works is something like this:

(for simplicity, assuming 10 steps instead of 256)

display luminance function (arbitrary units) before loading gamma ramp (I've bolded the walls)

1, 1, 1, 4, 5, 6, 7, 10, 10, 10

desired luminance function

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

gamma correction ramp:

1, 2, 3, 1, 1, 1, 1, 0.8, 0.9, 1

end result will be the desired function. I don't understand why the walls "will look the same anyway".

Quote:
Originally Posted by VerGreeneyes View Post

In Windows, the videoLUT APIs all take 3x256 16-bit unsigned integers (so in the range 0-65535) - but there's nothing to guarantee the display or graphics card (whichever is responsible for applying the values; I'm not sure which) use the full 16 bits internally in their calculations. I would imagine that the graphics card takes care of it for VGA and can use the full 16-bit values, but that's just a guess. On LCDs with a digital interface, I think the monitor is responsible for applying the LUT, but they tend to use 8-bit or even 6-bit values to set the transparency of each subpixel. They can approximate the full 16-bit values using dithering, but whether they do probably varies between monitors.

Interesting. So even in an environment where there are only 256 possible steps, the step sizes may in some cases be specified with 16 bit precision. I'd never thought about that.
Quote:
Originally Posted by VerGreeneyes View Post

Note also that there's a potential mismatch here between the way dispcal measures its corrections using dispwin or madVR, and the precision with which the videoLUT will get applied. madVR uses high precision processing internally and uses dithering when displaying the test patches, but that dithering may be different from what your display ends up doing with the videoLUT.

ok, so if I use the -dmadvr switch during the generation of the .cal file, then I will have generated a correction profile that is potentially more accurate. How do I then go about incorporating it into MadVR without a 3dLUT? ( up until now I've been using dispwin to load the profile). I'm guessing I would have to create a linearized 3DLut, and then append the .cal file to it?
spacediver is online now  
post #1354 of 2777 Old 12-28-2013, 09:49 AM
Member
 
VerGreeneyes's Avatar
 
Join Date: May 2013
Posts: 112
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by spacediver View Post

Perhaps I don't understand LUTs as well as I thought. My model of how it all works is something like this: ...
It's more like this:
Code:
Input  Measured lum  Desired lum  Calibrated input
    0             0            0          3.000000
    1             0           25          3.444444
    2             0           50          3.888889
    3            45           75          4.333333
    4            90          100          4.777778
    5           135          125          5.222222
    6           180          150          5.666667
    7           225          175          6.111111
    8           225          200          6.555556
    9           225          225          7.000000
The first value for the calibrated input could be anywhere between 0 and 3 without affecting the luminance, and the last value could be anywhere between 7 and 9, but the fit is more likely to converge to the given values.

Quote:
Originally Posted by spacediver View Post

ok, so if I use the -dmadvr switch during the generation of the .cal file, then I will have generated a correction profile that is potentially more accurate. How do I then go about incorporating it into MadVR without a 3dLUT?
You don't have to do anything - just make sure the .cal file is loaded into your videoLUT and all of madVR's output will be transformed by the LUT before it appears on your monitor.
VerGreeneyes is online now  
post #1355 of 2777 Old 12-28-2013, 10:12 AM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
I think I just had an insight. The correction factors aren't applied directly to luminance. That makes no sense. They're applied to the RGB values themselves.

So, in your example, if input 5 corresponds to RGB 130 130 130, and your measured luminance is 135, and you want 125, you can't just calculate it easily. You'd have to have a model of how the display deals with RGB signals (i.e. the display's luminance function). Or you could use brute trial and error. From the verbose output of dispcal, I gather it's a combination of both.

Ok, so suppose you figure out exactly how to scale the RGB signal such that it produces the desired luminance. In the case of input 5, the calibrated input value reads 5.222. I'm having difficulty interpreting what this number means. Does it mean that the new RGB signal should be 130-5.222 = 124.777??
Quote:
Originally Posted by VerGreeneyes View Post

You don't have to do anything - just make sure the .cal file is loaded into your videoLUT and all of madVR's output will be transformed by the LUT before it appears on your monitor.

Ah ok, so I'll keep doing what I'm doing (loading it with dispwin).

I've been going through some wallpaper photos, and I've noticed that in some images, there are what appear to be quantization artifacts in the mid-upper ranges. It's hard to be sure, as not all images show it. It could be the case that I'm just revealing "flaws" that weren't visible before. I may design some saturation and gamma test ramps in inkscape so I can explore further, and/or look at those photos on other displays. The low tones look fantastic though.
spacediver is online now  
post #1356 of 2777 Old 12-28-2013, 10:37 AM
Member
 
VerGreeneyes's Avatar
 
Join Date: May 2013
Posts: 112
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by spacediver View Post

I think I just had an insight. The correction factors aren't applied directly to luminance. That makes no sense. They're applied to the RGB values themselves.
That's right.
Quote:
Originally Posted by spacediver View Post

Ok, so suppose you figure out exactly how to scale the RGB signal such that it produces the desired luminance. In the case of input 5, the calibrated input value reads 5.222. I'm having difficulty interpreting what this number means. Does it mean that the new RGB signal should be 130+5.222 = 135.222?
It just maps the input value 5 to 5.222 - in our contrived example, there were only 10 such values, but in the .cal file there will be 3x256 values: one for each 8-bit input value. It just looks up the calibrated value corresponding to the 8-bit index of the uncalibrated value.
VerGreeneyes is online now  
post #1357 of 2777 Old 12-28-2013, 10:44 AM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
ahhhh, I get what you originally meant about the walls now. Mapping those RGB levels to new RGB values (which themselves produce the same luminance) ain't gonna accomplish so much as a squirrel's fart when you get towards the deeper ends of those walls, especially when your instruments aren't capable of resolving subtle differences in luminance that may actually exist.

The situation isn't as simple as I had naively imagined - I get why you recommended dispcal as opposed to the manual method.

Thanks for your patient tutelage tongue.gif
spacediver is online now  
post #1358 of 2777 Old 12-30-2013, 06:05 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
I've a question related to the MadVR filter settings. I can appreciate the need for image scaling, and the potential value of chroma upsampling (trying to learn more about how the latter achieves its goals).

Thing is, I have a CRT monitor. From what I understand, a CRT naturally scales content better than any algorithm can. If this is true, then am I compromising my potential quality by enabling these algorithms? If so, how would I configure MadVR to let my CRT handle the scaling naturally? Does this question even make sense?
spacediver is online now  
post #1359 of 2777 Old 12-30-2013, 06:30 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,477
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 64 Post(s)
Liked: 132
CRTs don't "scale", they can simply display different resolutions. They don't have a fixed physical resolution like LCDs or Plasmas have. Whether it makes sense or not to let madVR upscale with a CRT monitor I cannot say. It depends on too many things. I would recommend to simply try different settings and choose the one which looks best to your eyes.
madshi is offline  
post #1360 of 2777 Old 12-30-2013, 06:51 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
Good point. I made the stupid assumption that my CRT was upscaling things in the past with other video players, but of course it wasn't, as the display resolution didn't switch. Which means that the software (i.e. VLC) was doing the scaling. I just did a quick test, using VLC, watching some 720p content in 1280x800 vs 1920x1200. Couldn't discern a difference. I'll set MadVR to switch resolutions automatically and do some proper testing. Thanks for the post.
spacediver is online now  
post #1361 of 2777 Old 12-30-2013, 06:51 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by VerGreeneyes View Post

In Windows, the videoLUT APIs all take 3x256 16-bit unsigned integers (so in the range 0-65535) - but there's nothing to guarantee the display or graphics card (whichever is responsible for applying the values; I'm not sure which) use the full 16 bits internally in their calculations.
How many bits resolution you actually get depends on the graphics card, the video path to the display, and the display itself.

VGA output will typically be between 8 and 12 bits. (My NVidia GeForce 8600 GT seems to have 10 bit D/A converters.)

[ Note I'm talking about the 1D LUT entry precision here, not the frame buffer depth. Support for deep frame buffers in the OS, applications and hardware is a whole other topic... ]

Typical DVI output is limited to 8 bits, unless you have a rather exotic combination of video card and display that is using dual link DVI to transmit 16 bits per component (this would be very unusual).

Display Port supports greater than 8 bits.

HDMI can also support more than 8 bits.

If your instrument is repeatable and has enough precision and your display is stable enough, you can estimate the actual precision by running "dispcal -R"
gwgill is offline  
post #1362 of 2777 Old 12-30-2013, 07:22 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
Just did the dispcal -R, and it estimated an effective LUT entry bit depth of 10 bits.

Using DVI-VGA, Geforce GTX 660, windows XP, GDM-FW900


Putting this into the context of 1d LUT precision vs frame buffer: This means that my display can interpret signals from the video card and quantize them into voltage with a precision of 10 bits. But in terms of the frame buffer being only 8 bits, this means that only 2^8 different pixel values are viable (per color channel). In other words, I can configure my LUT using only 256 steps, but I can choose between 1024 step sizes. Have I got that right?

Also, noticed something very cool, and I think this is related to the 10 bit LUT capability of my display.

I can turn my brightness right down to 0, so that a lot of detail is crushed. But then if i use the gamma slider in Nvidia control panel (or the brightness slider), I can bring back all the detail without any quantization artifacts. I've heard reports of people with LCD displays (in particular, one with 6 bit + 2bit temporal dithering) experiencing quantization artifacts the moment they adjust gamma outside of the OSD presets, whether it be through dispwin, or through the nvidia control panel.
spacediver is online now  
post #1363 of 2777 Old 12-30-2013, 08:19 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by spacediver View Post

In other words, I can configure my LUT using only 256 steps, but I can choose between 1024 step sizes. Have I got that right?
Yes
gwgill is offline  
post #1364 of 2777 Old 12-30-2013, 08:46 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
I guess this means that my CRT would be able to handle at least a 10 bit frame buffer. Very cool. I know CRTs are capable of an arbitrary bit depth in principle (depending on the voltage amplification circuitry), but there was always the question of whether, given that it's an advanced CRT, there may be some circuitry that constrains it to 8 bits. It's been very hard to test this, as implementing a video pipeline that is more than 8 bits is a royal pain the ass, as you're aware. Using your software (even thought it's an estimate) is the first time I've been able to get some kind of answer, so thanks for that.
spacediver is online now  
post #1365 of 2777 Old 12-31-2013, 07:24 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
I do not want to restart the good old question, but I recently simply set my contrast to 100, and my brightness to 44 to get the highest possible CR I have ever seen on my set - 2650:1 and black level point of 0.037!!!!!!!. Then I simply used CalMAN and calibrated with software to get 2 profiles - one with BT gamma and one with power law gamma. Doing so preserved my CR perfectly! With ArgyllCMS, I would always do both - calibrate and profile to get a 3DLUT, which would always raise black levels and yield 1700:1 CR. Afterwards, I would simply lower my brightness and up my conrtast to offset the black level rise and contrast contraction. However, past 2000:1, accuracy begins to decline drastically. I remember reading that using dispread or profiling alone, without dispcal calibration, will prevent black level point rise and contrast reduction/contraction. So, I should be able to simply do the same thing I did with CalMAN and set contrast to 100, brightness to 44, and just run a dispread?
MonarchX is offline  
post #1366 of 2777 Old 12-31-2013, 07:36 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
I had no issues with dispcal raising my black level once I learned how to use it. What switches did you use?
spacediver is online now  
post #1367 of 2777 Old 01-01-2014, 09:17 AM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
If you look through the thread - you will find that i have done a LOT of testing. I tried just about every switch and setting there is. For MadVR, the only one that doesn't significantly raise my black level, but does cut my CR from 2650:1 to 1750:1 is dispcal.exe -v -dmadvr -c1 -yn -Yp -X CCFLFamily_07Feb11.ccss -qh -m "-w0.3127,0.3290" -G2.4 -f0 -k0 -A4.0 "LUT_name" and for desktop use - dispcal.exe -v -d1 -c1 -yn -m -Yp -X CCFLFamily_07Feb11.ccss -qh "-w0.3127,0.3290" -G2.4 -f0 -k0 -A4.0 "LUT_name"

I hope dispread won't contract my CR! I'll report back after I run it.
MonarchX is offline  
post #1368 of 2777 Old 01-01-2014, 12:06 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
I think I used:

dispcal -qu -A16 -g2.4 -k0 -f0 LUT_name
spacediver is online now  
post #1369 of 2777 Old 01-01-2014, 01:56 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
-qu cuts my CR even more than -qh! What is -A16?

It all depends on the display I think. There must be something it thinks that isn't correct when my CR is that high. And yet, CalMAN v5 manages to create a 1DLUT that fully corrects my gray scale gamma (to BT.1886 and to power law 2.2), WB, and luminance, with the highest dE of 0.3 across 21 5% steps. I don't know why ArgyllCMS cannot do the same and gwgill put me on his ignore/block list because he can't take criticism and too proud to accept apologies. I understand why ArgyllCMS cannot produce a power law 2.2 gamma as the system was designed from ground up to be truly accurate, something that isn't really possible with power law gamma 2.2 when black level point is higher than 0.00. However, BT.1886 gamma shouldn't be cutting CR and raising black level point either - CalMAN LUT preserves my CR all the way with either power law or BT gamma and just accurate gray gamma and luminance, but also accurate red, green, and blue luminance and red, green, and blue gamma.

I just tried doing dispread without dispcal, and it cut my CR from 2650:1 to 2300:1 and raised black level point slightly. Since my TV is old and I consider CR to be extremely important, I want it to be as high as it can possibly be! There is no reason to cut it.

I wish there was a way profile with dispread.exe using CalMAN 1DLUT that already has fully calibrated WB, gamma, and luminance and preserves CR. All I really need now from ArgyllCMS is the CMS calibration - saturation, hue, etc. Are there switches that would leave gray scale completely alone and just do the CMS?


EDIT: using dispread profiling without dispcal calibration also resulted in seriously messed up blacks. Some of them turned browns, others green and blue. Its for 0-5%. Is there a way to manually edit madVR 3DLUT or edit the dispread profile to correct that error? I can't really complain because this software is free, but being free is the only way people will use it.
MonarchX is offline  
post #1370 of 2777 Old 01-01-2014, 03:54 PM
Senior Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 217
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 51 Post(s)
Liked: 43
I've updated the dispcalGUI snapshot. Notable changes:
  • Profile verification feature renamed to "measurement report" and moved to its own window (you still access it via the "Tools" menu). The new functionality enables (among other things) madVR 3D LUT verification. Setup in a nutshell: Choose any testchart (e.g. verify_video.ti1 or verify_video_extended.ti1 for a quick check. Both of these charts contain grayscale and saturation sweeps, the extended version adds additional 75% primaries/secondaries, more grayscale, near black and near white steps as well as 18 colorchecker patches). Choose the same profile that was used as source during 3D LUT creation (e.g. Rec709.icm) as simulation profile. Enable "use simulation profile as target" to enable madVR 3D LUT (be sure madVR is set up appropriately and that you are using the madVR display in dispcalGUI and that madTPG is running). If you created the 3D LUT with BT.1886 mapping, choose the same settings (also use the same target profile) as was used during 3D LUT creation.
  • Measurement reports now contain a few additional simple graphs (CCT, gamma, RGB gray balance and gamut). In the gamut graph you can hover over points to highlight reference and measured points (the larger circle is the reference), use the mousewheel to zoom, and click and drag to pan the viewport. Double click inside the graph to reset it.
  • The testchart editor now allows adding of saturation sweeps and reference patches if using a preconditioning profile and adaptation at 100%.
fhoech is offline  
post #1371 of 2777 Old 01-01-2014, 07:04 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
Quote:
Originally Posted by MonarchX View Post

-qu cuts my CR even more than -qh! What is -A16?

You used the -A switch in your own string. You don't know what it does?
spacediver is online now  
post #1372 of 2777 Old 01-01-2014, 07:04 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
Thanks for the update! Those are some very convinient features.


Is it possible to make dispread.exe skip 0-10% WB calibration? I think that either my TV or my colorimeter are not working right at that step because my blacks have too much red in them or not enough blue. I think its my i1D3 because I noticed the same behavior on my other monitor too and a buddy of mine with a plasma TV reported the same issue. Funny, but this doesn't happen when I use dispcal before using dispread. Why is that? I used to get a near-perfect calibration and perfectly neutral blacks when I was pressing "Calibrate and Profile" in dispcalGUI which would use dispcal.exe and dispread.exe. However, using dispread.exe alone without dispcal, my blacks are far from neutral. With CalMAN DDC 1DLUTs, I can manually edit different IRE RGBs, but what about ArgyllCMS? Is there a way to manually edit information?
MonarchX is offline  
post #1373 of 2777 Old 01-01-2014, 07:40 PM
Member
 
VerGreeneyes's Avatar
 
Join Date: May 2013
Posts: 112
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by spacediver View Post

You used the -A switch in your own string. You don't know what it does?
Just FYI, this guy was very rude to Graeme (the creator of ArgyllCMS) and has also gotten into various confusing and contradictory discussions with other people. Graeme blocked him and I eventually followed suit. I'm not saying don't help him, but if he gets on your nerves.. well, this forum has a function for that.
VerGreeneyes is online now  
post #1374 of 2777 Old 01-01-2014, 08:20 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
Yes, this is a support thread dedicated to those who don't have any problems and those who do must be doing something wrong. This is why this software remains and will remain 100% free. Its not like other paid software, designed for many people who can get support for their problems any day and never be blocked when they are frustrated because the help provided requires even more help just to understand it. The developer isn't even aware of what the GUI designed for his software can actually do, even though he advises to use it and mocks people by asking them if they realize that dispcalGUI is a GUI for ArgyllCMS. That's all one needs to know to figure out his character. Taking into consideration testing results only from few select people and completely ignoring efforts of others with not such great results alone guarantees that there is no future for this CMS, even though its a great CMS!
MonarchX is offline  
post #1375 of 2777 Old 01-01-2014, 08:24 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
So - is there a way to edit WB data manually for 0-7.5% IRE? My colorimeter can't read accurately that low. I don't see a Low-Light Handler option either.
MonarchX is offline  
post #1376 of 2777 Old 01-01-2014, 08:35 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
Quote:
Originally Posted by MonarchX View Post

Yes, this is a support thread dedicated to those who don't have any problems and those who do must be doing something wrong.

The fact that you don't understand the switches you're using shows that you're not really in a position to be criticizing the software.
spacediver is online now  
post #1377 of 2777 Old 01-01-2014, 09:58 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
But that fact doesn't negate anything that I said. I've tried just about any combination of switches and posted my results. Whatever though - Zoyd demonstrated that black levels do rise regardless of switches you use and he's an expert on these things without a doubt. Even using dispread.exe alone also creates a slight rise. But I actually do want people to ignore my results, so the they falsely assume that this program works for all just as well as it works for the very few who have no issues at all, attempt to put a price on it just to see it fail miserably.

At this point all I want to know is how to make manual adjustments to dispread WB data for 0-7.5% IRE. CalMAN lets you adjust data manually, but I doubt ArgyllCMS can...
MonarchX is offline  
post #1378 of 2777 Old 01-01-2014, 10:29 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
If all you're interested in is WPB and gamma, have you tried skipping the 3d LUT stuff, and instead, just using dispcal to generate the .cal file, and dispwin to load it into video lut? Maybe the issue with raised black levels wouldn't present itself there, not sure though.
spacediver is online now  
post #1379 of 2777 Old 01-01-2014, 10:48 PM
 
MonarchX's Avatar
 
Join Date: Jul 2012
Posts: 669
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
I already have that done. I AM interested in 3DLUTs and black level rise is not the current issue as I easily solved it by decreasing brightness and increasing contrast, but I couldn't go past 2000:1 CR without losing accuracy. With dispread alone I am finally managing to get close to 2500:1 CR, but at the cost of bad WB for levels 17 and 18. They are brown-black instead of neutral black. This happens because my i1D3 colorimeter cannot be trusted for sub-5% IRE calibration. That is why it suggested to calibrate 0-10% or at least 0-5% using your eyes online. However, I can't do that with ArgyllCMS 3DLUT or can I? I can only hope that there is a way to manually edit the WB info to add some blue to levels 17 and 18! I know that supposedly you can't tell the difference with such dark levels, but I can.
MonarchX is offline  
post #1380 of 2777 Old 01-01-2014, 10:54 PM
Advanced Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 897
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 74
Quote:
Originally Posted by MonarchX View Post

I already have that done. I AM interested in 3DLUTs and black level rise is not the current issue as I easily solved it by decreasing brightness and increasing contrast, but I couldn't go past 2000:1 CR without losing accuracy. With dispread alone I am finally managing to get close to 2500:1 CR, but at the cost of bad WB for levels 17 and 18. They are brown-black instead of neutral black. This happens because my i1D3 colorimeter cannot be trusted for sub-5% IRE calibration. That is why it suggested to calibrate 0-10% or at least 0-5% using your eyes online. However, I can't do that with ArgyllCMS 3DLUT or can I? I can only hope that there is a way to manually edit the WB info to add some blue to levels 17 and 18! I know that supposedly you can't tell the difference with such dark levels, but I can.

are you working in 16-235, or 0-255?

And why do you keep using the term IRE?
spacediver is online now  
Reply Display Calibration

User Tag List

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