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

MadVR - ArgyllCMS - Page 5

post #121 of 1700
Quote:
Originally Posted by zoyd View Post

One last question regarding BT.1886, is the -I B switch in combination with Rec709.icm source profile exactly equivalent to using a source profile with technical BT.1886 embedded within it (assuming one could do that)?

Yes I think so. The Rec709 profile has the Rec709 transfer curve in it, but the BT.1886 mode applies an inverse Rec709 transfer curve and then the black point adjustment and 2.4 power curve. (In theory this could be done in XYZ space, but it seemed to make more sense to do it in the input space RGB).

So the intended effect is for the source profile (== emulated display) to have the Rec709 primaries + BT.1886 transfer curve.
post #122 of 1700
Thread Starter 
@Graeme

Thanks for you recent update, I will try to find some time to test in the next couple of days.

I have settled on using a custom testchart with 5 white patches, 256 neutral patches, and 3000 iterative patches. Takes quite a bit of time but I've achieved excellent results with it. Will post result chart soon. I will experiment with a 17^3 multidimensional testchart in the future just to see if it will lower dE even more.
Code:
targen.exe -v -d3 -e5 -s0 -g256 -m0 -f3260 -A0.1 -W "3000_g256_3260"
targen.exe -v -d3 -e5 -s0 -g256 -m17 -f0 -W "17^3_g256_5163"

Quick question for sanity sake, I don't have to create the testcharts on the PC that I'm running my profile on, correct?

I really appreciate the work you have put into ArgyllCMS to generate a compatible 3DLUT for MadVR use. Even my wife can tell the difference after the ArgyllCMS 3DLUT correction is put into use. There is definitely donation coming your way. (Amount pending wife's approval tongue.gif)
Edited by N3W813 - 5/14/13 at 12:36pm
post #123 of 1700
Quote:
Originally Posted by N3W813 View Post

I will experiment with a 17^3 multidimensional testchart in the future just to see if it will lower dE even more.
Regular array points are the least efficient, and risk "resonance" effects due to their uniform spacing. (ie. they can exacerbate curve fitting ringing). I'd suggest body centred cubic
(targen -b N) as a better, regularly spaced test set, if you want to play with an alternative to
the default OFPS (Optimised Farthest Point Sampling).
Quote:
Quick question for sanity sake, I don't have to create the testcharts on the PC that I'm running my profile on, correct?
Not at all. As long as the display path operates the same way, you could profile with one PC, and then transfer the resulting 3dLut to another PC.
Quote:
There is definitely donation coming your way.
All donations appreciated :-) :-) :-)
post #124 of 1700
Excellent guide, I left it running yesterday night and can't wait to get home today to see the results :-)

Can you include in the topic what pre-calibration steps are necessary (or if none)? I'd imagine before running this calibration, the user would need to adjust brightness / contrast / sharpness, and maybe set the panel to movie mode with a color temperature close to 6500k?

Would it also be valuable to perform any sort of grayscale calibration with HCFR before doing this, or is it better to leave the display at the default configuration?

Thanks!
post #125 of 1700
Is there a way to solve this? I do not understand so much of it and probably a bit difficult to explain it with my English skills ... but assume that it is because my TV does not have a wide enough color gamut?



post #126 of 1700
Quote:
Originally Posted by cfelicio View Post

Excellent guide, I left it running yesterday night and can't wait to get home today to see the results :-)

Can you include in the topic what pre-calibration steps are necessary (or if none)? I'd imagine before running this calibration, the user would need to adjust brightness / contrast / sharpness, and maybe set the panel to movie mode with a color temperature close to 6500k?

Would it also be valuable to perform any sort of grayscale calibration with HCFR before doing this, or is it better to leave the display at the default configuration?

Thanks!

My best judgment is that it is best to adjust contrast, brightness and sharpness before ArgyllCMS.
post #127 of 1700
Thread Starter 
Quote:
Originally Posted by cfelicio View Post

Excellent guide, I left it running yesterday night and can't wait to get home today to see the results :-)

Can you include in the topic what pre-calibration steps are necessary (or if none)? I'd imagine before running this calibration, the user would need to adjust brightness / contrast / sharpness, and maybe set the panel to movie mode with a color temperature close to 6500k?

Would it also be valuable to perform any sort of grayscale calibration with HCFR before doing this, or is it better to leave the display at the default configuration?

Thanks!

If you are using your PC with other video players that do not support MadVR (ie. WMC, WMP, PowerDVD, etc.), then it would be best if you can calibrate your TV first using it's internal controls. This way you can get accurate reproduction with those non-MadVR apps and better reproduction with MadVR supported players.
Quote:
Originally Posted by MSL_DK View Post

Is there a way to solve this? I do not understand so much of it and probably a bit difficult to explain it with my English skills ... but assume that it is because my TV does not have a wide enough color gamut?

Solve what? Your chart looks great. wink.gif Do you have the dEs for the saturation points? The only 2 points that are kind of off are 100% sat red and 100% sat blue and it looks like that's limited by the capability of your display. 3DLUTs cannot 'enlarge' the native gamut of your display.
post #128 of 1700
Quote:
Originally Posted by N3W813 View Post

Solve what? Your chart looks great. wink.gif Do you have the dEs for the saturation points?

Yes
Code:
2.1  0.9     2.1     0.6     0.6     0.1
Quote:
Originally Posted by N3W813 View Post

The only 2 points that are kind of off are 100% sat red and 100% sat blue and it looks like that's limited by the capability of your display. 3DLUTs cannot 'enlarge' the native gamut of your display.

That's what I thought ... and yes very logical that it can not be solved ... when my TV can not display more than it can, right?
post #129 of 1700
Thread Starter 
Quote:
Originally Posted by MSL_DK View Post

Yes
Code:
2.1  0.9     2.1     0.6     0.6     0.1
That's what I thought ... and yes very logical that it can not be solved ... when my TV can not display more than it can, right?

Right, you can't make something out of nothing. Your dEs are already fine, all under 3. Even if you lowered the 2.1 to =<1, you most likely will not visually perceive a difference.
post #130 of 1700
Quote:
Originally Posted by N3W813 View Post

Right, you can't make something out of nothing. Your dEs are already fine, all under 3. Even if you lowered the 2.1 to =<1, you most likely will not visually perceive a difference.

Okay smile.gif I will try to put myself into what the different commands do. I have a hard time finding a good starting point for dispcal and the end result for gamma which starts at 2.2 and decreases to 1.9 at 20IRE and rises in 30IRE to 2.2. I think the problem was created when Graeme made ​​this change, but are not sure "2013-05-11 - ArgyllCMS beta binaries updated. Graeme Fixed issue with elevated black points, derfor Black Point Compensation option is no longer needed in DispcalGUI. (Step B10 ) "before starting gamma at 2.35 10IRE and decreased to 2.2 at 10IRE
post #131 of 1700
Quote:
Originally Posted by MSL_DK View Post

I have a hard time finding a good starting point for dispcal and the end result for gamma which starts at 2.2 and decreases to 1.9 at 20IRE and rises in 30IRE to 2.2.

BT.1886 black point matching is not designed to result in a constant gamma on a log/log
plot, since the pure power curve gets scaled and truncated.

The "-Ib" mode aims for the 50% input to result in the specified ("-i b:N.N") or default
(2.2) gamma (What I'm calling "effective gamma"). The log/log gamma will be different at
other input levels if your display is in this world (ie. not theoretical :-), and hence has a non-zero black point. This is all designed to make it look as it should.
post #132 of 1700
Quote:
Originally Posted by cyberbeing View Post

That seems to be the case, but I'm wondering why? Is it a problem with my patch set, my measurements, or a bug in colprof/collink code?

Is there anything I can do myself to attempt to fix it?
I think that you are the one best placed to track it down. My usual approach is to do some spot
checking using spotread and xicclu, although tracking subtle errors can be hard given reading inconsitency.
Quote:
It it even possible to objectively assess CIECAM02 quality?

Yes, but it wouldn't be easy. To a degree, it has to be taken on faith that the color scientists
who developed it have done their homework. (There are a bunch of papers + Mark Fairchild's Color Appearance Models book provides a lot of background and history.)
Quote:

I must have gone through ~20-30 different variations of CIECAM02 3DLUT since the parameters are confusing. The more I read about CIECAM02, the more I think it's not designed to be used in the static way you've implemented it for anything but gamma correction. The CIECAM02 parameters seem like they need to adapt dynamically to the exact properties of each and every single image frame of a video. In particular the surround parameter, I believe is supposed to be content adaptive.
This is partially correct (in particular what I've called 'display flare' is actually dependent
on what's being displayed, which is why I've defaulted it to zero, so as not to adversely affect
overall dark images), but there is a lot more to doing this type of thing in an image dependent way
- see iCam, which is a image dependent scheme based on CIECAM http://www.cis.rit.edu/fairchild/PDFs/PRES06.pdf.

But no, the surround is not regarded as being image dependent. As far as I know, CIECAM02 is not an image content dependent model, and represents the general state of the observer, independent of any particular image they are looking at. You might find my interpretation on page 49 of this ArgyllCMS tutorial http://www.argyllcms.com/doc/FCMS2010_ArgyllTute.pdf I put together a while ago relevant(although it doesn't explain the distinction I'm now making between Glare and Flare).
Quote:

My interpretation:
Image white = TV/Monitor Peak Luminance
Adaptation luminance = Ambient Light
Background = Image Luminance (median) / Peak Luminance (Film: ~20%, Japanese Anime ~40%)
Surround = Needs to be content/pixel adaptive? Otherwise it seemed to describe the luminosity from
the Background parameter.
Surround is generally assumed to be 20% of the peak luminance.
Quote:
What is the source of the pre-canned profiles, I looked and I couldn't find them in the CIECAM02
specification? Do they trigger options not shown by collink -v?
They are from a variety of sources, including various industry standards and rules of thumb.
Quote:
I assume there is no way to force the current CIECAM02 options in collink to do this?
No, it's not setup like that.
Quote:
I thought those were only for BT.1886 style curves? I was attempting to mimic that REC709 ambient light scaling which Dispcal uses. Was there a way to do this without enabling the entire CIECAM02 color appearance model?
I'd imagine the effect would be very similar, since the use of CIECAM02 in dispcal was just a mechanism to convert the ambient reading into a gamma shaped curve.
post #133 of 1700
Quote:
Originally Posted by cyberbeing View Post


Thinking about this a bit more, should I be changing the scope of the CIECAM02 adaption from the TV/Display+Video+Room (as above) to just TV/Display+Room, ignoring the video properties?
The effects on the reproduction are all about the difference between source and destination viewing conditions, in exactly the same way that the overall color transformation is the result of the differences between source and destination color profiles.

This is complicated somewhat by the exact nature of the encoding - does it represent something like the original scene ("scene referred"), or does it represent an appearance on something like a display ("rendered"). These each have different (assumed) viewing conditions.
Quote:

Graeme can you explain why "Argyll Usage Scenarios" use the CIECAM02 parameters how they do in relation to my confusion over proper use of the parameters if I desired to fine-tune them for my exact viewing conditions?

In the pure CIECAM scenario:
Code:
collink -v -c tv -d md -d a:7 -G -i la Rec709.icm TV.icm HD.icm

the video is assumed to be encoded as per Rec709 in typical TV studio ("bright") conditions, and displayed on a TV in typical dim viewing conditions with low ambient light (hence -c tv -d md + tuning). The resulting adjustment darkens the original, to take account of the dim adapation, in a similar (but different in details) fashion to how the classic video "2.2 power encoding + 2.4 power decoding" has traditionally made this adjustment.

In the hybrid scenario:
Code:
collink -v -I b -c md -d md -d a:10 -G -i la Rec709.icm TV.icm HD.icm

the traditional gamma mismatch is used to re-render the "bright studio" video encoding down to "BT.1886 standard" like viewing conditions, and the CIECAM02 then used to fine tune from that to the actual viewing conditions. Hence -c md -d md + tuning.
post #134 of 1700
Quote:
Originally Posted by cyberbeing View Post

Collink could then use these display measurement verified corrections to fine-tune/offset the 3DLUT for better results?
You mean, like this: http://www.argyllcms.com/doc/refine.html ?

(Refine isn't really suitable for use with video at present unless there is a source profile that represents the target behaviour - ie. fakeread would need modifying to add the BT.1886 etc. source adjustment to be able to create the target readings.)
Quote:
A variation of this idea, would be to treat collink as a virtual measurement instrument, and use a modified version of ccxxmake to create a matrix correction file with a physical instrument (i.e. i1pro) used as the reference?
I guess I'm not really following you on this one.
post #135 of 1700
I've found CIECAM02 and its recent developments an interesting read. In their introduction of CIECAM02, they say this about the 'background' parameter:
Quote:
For viewing images (Fig. 2.3), this element can be the average Y value
for the pixels in the entire image, or frequently, a Y value of 20, approximate an L*
of 50 is used.
So maybe that was what cyberbeing was referring to. Their section on extensions of CIECAM02 is especially interesting, though I don't know if you could implement any of it in Argyll and still be spec compliant with ICC v4 smile.gif
post #136 of 1700
Quote:
Originally Posted by VerGreeneyes View Post

In their introduction of CIECAM02, they say this about the 'background' parameter:
Quote:
For viewing images (Fig. 2.3), this element can be the average Y value
for the pixels in the entire image, or frequently, a Y value of 20, approximate an L*
of 50 is used.
So maybe that was what cyberbeing was referring to.
Right, but the nature of the device link or 3dlut is per pixel transformation, so there is no scope for image dependent or spatial transformations, so such factors have to reduced to a constant.
Quote:
Their section on extensions of CIECAM02 is especially interesting, though I don't know if you could implement any of it in Argyll and still be spec compliant with ICC v4 smile.gif
I'm not sure what you mean. ArgyllCMS is currently ICCV2, and has supported CIECAM02 for some time. In fact the research in ref. 54 noted in the Luo & Li chapter is a result of my efforts to turn CIECAM02 to practical use in ICC profiles.
post #137 of 1700
Quote:
Originally Posted by gwgill View Post

Right, but the nature of the device link or 3dlut is per pixel transformation, so there is no scope for image dependent or spatial transformations, so such factors have to reduced to a constant.
Right, yeah. Only something like a media player would be able to take this into account. And even then, it would have to offer mean Y for every frame as a source for a CIECAM02 shader or something (performing forward and inverse transforms with the adjusted viewing conditions). Not sure how that would even look, and I can't even reason out whether the dynamic Y would be used at the forward or the inverse transform, but it might be a fun experiment.
Quote:
Originally Posted by gwgill View Post

I'm not sure what you mean. ArgyllCMS is currently ICCV2, and has supported CIECAM02 for some time. In fact the research in ref. 54 noted in the Luo & Li chapter is a result of my efforts to turn CIECAM02 to practical use in ICC profiles.
Ah! I had no idea that research was yours, excellent smile.gif I thought that ICCv4 mapped colors to CIECAM02 as an intermediate color space between input and output. Is that what ICCv2 does too, or am I way off?
post #138 of 1700
Thanks for helping out. I finished the calibration last night, and I must say the results are very pleasing, with still a few points to clarify if possible, considering I'm a newbie at this and want to make sure I did things correctly. smile.gif

First, the system and method I used:

TV: An old Samsung LN40A550 LCD
HTPC: AMD A6-5400k with Jriver Trial
Spec: Colormunki Photo
Outputs / Inputs: Everything RGB 4:4:4 0-255
Colorimeter: Colormunki Create (clone of i1d2)


I set the TV to defaults (Movie Mode, no dynamic contrast, etc). Then I adjusted it using brightness / contrast. Also put in the mode closest to 6500k at 100 IRE (in my case, Warm1), and backlight somewhat close to 120cd/m2 (I have a reasonably dark room for watching, but not pitch black).

I warmed up the TV for 30 minutes with both calibration devices on it.

Then I ran dispcalgui, created a correction for the colorimeter based on the colormunki photo, and ran the calibration with high quality and Massive testchart for LUT profiles.

After it was done, I created a few 3dluts to test, based on the commands your provided:

1 - Regular, based on collink.exe -v -3m -qh -et -Et -Ib:2.2
2 - 188622, based on collink.exe -v -3m -qh -et -Et -IB:2.2
3 - 188624, based on collink.exe -v -3m -qh -et -Et -IB:2.4


After it was all done, I launched Jriver and applied each profile on several sources based on scenes I'm familiar with, and usually have either a lot of contrast (like a face on the sun with a shadow on the side), or dark scenes (inside a tavern), etc.

My initial impression is that BT 1886 with 2.2 gamma gave the most pleasing results. But it also gave a feeling sometimes of the blacks not being as deep as before.

As a final step, I re-ran the white and black clipping patterns (from AVSHD), and found something odd: With the profile applied, the flashing bars on the black pattern are now brighter, and in can see the 16 bar flashing again. Should I reduce the brightness and redo the calibration, or is this normal?

On the white clipping pattern, the bars are not "greyish" anymore, and I feel they got a bit of a yellow tone to them. To confirm, I removed the 3dlut and the bars immediately went back to grey. Can someone try this, and see if you get similar results?


As a last step, I used HCFR + the Spec to measure greyscale / primaries / secondaries and compare. I took measurements for everything running from Jriver (with AVSHD) for all the 3dluts mentioned above, as well as for the display without any 3dlut applied (uncallibrated).

From these results, looks like things got better. If someone has hcfr installed, can you have a look at my results and provide an opinion if these numbers look good, in particular the contrast curve?


Thanks so much for your help!

calibrationresults.zip 63k .zip file
post #139 of 1700
Hi,

Do you set MadVR (MPC-HT) to output at 24p to avoid 3:2?
Do you use another PC to run HCFR to read colorimeter (i1D3 or Colormunki )?
Do you use 2nd monitor just for HCFR that is set at 60Hz?

I can't get good readings when HCFR runs with PC display refresh at 24Hz output, but it's Ok when PC display is set to 60Hz.

thanks.
post #140 of 1700
Thread Starter 
Quote:
Originally Posted by N3W813 View Post

@Graeme
RE: Results of using “Black point compensation” in DispcalGUI profiling (step B.10)

From your discussion with cyberbeing in the MadVR thread over at Doom9, you stated that the ‘Black point compensation’ (BPC) option in DispcalGUI is an option you “can’t ever imagine using.” But from my calprofs last night on my Sharp LE640 TV (16-235 only, -E switch used for both dispcal and dispread), the black level is raised significantly without the BPC option enabled. Viewing a black clipping pattern (flashing steps from 2-25) with BPC disabled, black is shown at bar 11 instead of 16.

Readings of reference video black 16
Before cal/profile – 0.016 fL
With 3DLUT, BPC disabled – 0.032 fL
With 3DLUT, BPC enabled – 0.014 fL
Quote:
Originally Posted by gwgill View Post

The problem with "BPC off" I think is due to a mistake on my part - I was converting the display point to input space (Rec709) using a reverse lookup of the input profile that clipped to the input gamut, and if the display black point is not neutral (as is the case here), the clipping brightened up the black point a lot to get it in gamut.

I'll change the code somewhat to clip it in a different way, that doesn't brighten it up as much. If this still proves to be objectionable, then rather than try to correct the black point neutrality as much, I can try blending it to the true black point (but once again, inaccuracies in the readings and profile model near the black point can mess this up somewhat.)

Quote:
Originally Posted by cfelicio View Post


As a final step, I re-ran the white and black clipping patterns (from AVSHD), and found something odd: With the profile applied, the flashing bars on the black pattern are now brighter, and in can see the 16 bar flashing again. Should I reduce the brightness and redo the calibration, or is this normal?

@Graeme

Looks like black and near black levels are still being significantly elevated when 'Black Point Compensation' is disabled on DispcalGUI. I am confirming the same result as cfelicio; flashing bars all the way down to RGB 10 viewing the black clip pattern. Calibration/profile files attached.

collink.exe -v -3m -qh -et -Et -Ib:2.2 -G -ial Rec709.icm [icm_in_zip].icm madvr.icm

sharp_le640.zip 911k .zip file

Quote:
Originally Posted by mikek753 View Post

Hi,

Do you set MadVR (MPC-HT) to output at 24p to avoid 3:2?
Do you use another PC to run HCFR to read colorimeter (i1D3 or Colormunki )?
Do you use 2nd monitor just for HCFR that is set at 60Hz?

I can't get good readings when HCFR runs with PC display refresh at 24Hz output, but it's Ok when PC display is set to 60Hz.

thanks.

Then run HCFR at 60. wink.gif Revert back to 24 when you are done with your calibration. Changing refresh rate should not affect color reproduction. smile.gif
post #141 of 1700
Quote:
Originally Posted by mikek753 View Post

Hi,

Do you set MadVR (MPC-HT) to output at 24p to avoid 3:2?
Do you use another PC to run HCFR to read colorimeter (i1D3 or Colormunki )?
Do you use 2nd monitor just for HCFR that is set at 60Hz?

I can't get good readings when HCFR runs with PC display refresh at 24Hz output, but it's Ok when PC display is set to 60Hz.

thanks.

My TV doesn't support 24p, so I output 60Hz, but I have Smooth Motion enabled on Madvr.

I'm running a laptop with HCFR, and measuring the TV using the AVSHD patterns smile.gif
post #142 of 1700
N3W813,

Thanks for the reply.
How do you validate / read result of your profile in MadVR by HCFR? This is where I got confused rolleyes.gif
Do you play test patterns in mpc-ht?
Is it set to output at 24Hz to TV?
How at the same time your HCFR reads TV color output?

Do you set MadVR to output 16-235 to your Elite?

Mike.
post #143 of 1700
Thread Starter 
Quote:
Originally Posted by mikek753 View Post

How do you validate / read result of your profile in MadVR by HCFR? This is where I got confused rolleyes.gif

I use Calman on a secondary laptop to verify my results.
Quote:
Do you play test patterns in mpc-ht?

I use Zoom Player with MadVR on the HTPC to play the test patterns.
Quote:
Is it set to output at 24Hz to TV?

Doesn't matter for me. My meter (i1D3) can read reliably at 24 or 60.
Quote:
How at the same time your HCFR reads TV color output?

Don't quite understand this question. wink.gif
Quote:
Do you set MadVR to output 16-235 to your Elite?

Yes, I set output to 16-235 in MadVR.
post #144 of 1700
Quote:
Originally Posted by N3W813 View Post

I use Calman on a secondary laptop to verify my results.
I use Zoom Player with MadVR on the HTPC to play the test patterns.
Doesn't matter for me. My meter (i1D3) can read reliably at 24 or 60.
Don't quite understand this question. wink.gif
Yes, I set output to 16-235 in MadVR.

thanks a lot.
This explains to me a lot tongue.gif
I don't think that your i1D3 reads at 24 as you run HCFR on another PC / laptop. It reads from your Elite that outputs at 120-240Hz, while I think i1D3 syncs at 60
In my case, when I set display output to 24 on HCFR system I got different readings and the most impacted were 30% and below.
I don't know, but it was look like HCFR was very slow to read from TV or that was i1D3, I can't tell.
If you have time - could you try to use your HCFR at 24Hz? My HTPC display can be set at 24, but my laptop display only 50 and 60.

I think using dedicated laptop to run HCFR is right way to go.

Mike.
post #145 of 1700
Over the past few weeks I've been having a major problem with dispread occasionally producing "XYZ ### is not valid" error after reading the last patch and showing "The instrument can be removed from the screen." which causes it to not write a TI3 file at all. This has to be the 5th time I've seen this error since I started trying to measure >1000 patch sets, and has wasted many hours of time, and even more when it occurs again on another random XYZ number when I re-start readings from scratch. I'd rather dispread just retry or discard this one "invalid" value, and still write the other 1000-4000 valid patch measurements to a TI3 file.

Another problem I've been seeing on large patch sets is "Sample read failed due to communication problem. Hit Esc or Q to give up, any other key to retry:" which indefinitely pauses measurements until I hit a key to retry. Since this usually seems to occur 1 to 5 times on larger patch sets, I would like to see an option for all the tools to automatically retry up to N times for each patch before producing this error message asking for user input. I've also seen a couple times that dispread failed to resume properly after pressing a key, instead of retrying with the normal adaptive integration time, it displays the next few patches too quick to read (couple ms), but overall this particular sub-problem is more rare.


@Graeme Gill

If you could produce a new build which has a workaround for these two errors, I'd be thankful. Currently this has put a major roadblock in my experimentation with various patch sets, attempting to improve profile quality.
post #146 of 1700
Quote:
Originally Posted by cyberbeing View Post

Over the past few weeks I've been having a major problem with dispread occasionally producing "XYZ ### is not valid" error after reading the last patch and showing "The instrument can be removed from the screen."

First report of this kind I've received. It could be system dependent, and therefore tough to track down. What operating system are you running on ? (MSWindows ??). What instrument ?
(If it's an i1pro, what revision ?). What options did you use ? Have you ever captured debug
output when this happens ? (ie. run "dispwin -D5 etc etc 2> log.txt")
Quote:
I'd rather dispread just retry or discard this one "invalid" value, and still write the other 1000-4000 valid patch measurements to a TI3 file.
I will do that - I can make it just omit those patches. It will still fail fatally if it's the white patch that is invalid. It's hard to hypothesis what would cause this problem, since it basically means a patch failed to be read at all.
Quote:
Another problem I've been seeing on large patch sets is "Sample read failed due to communication problem. Hit Esc or Q to give up, any other key to retry:" which indefinitely pauses measurements until I hit a key to retry. Since this usually seems to occur 1 to 5 times on larger patch sets, I would like to see an option for all the tools to automatically retry up to N times for each patch before producing this error message asking for user input.
Is this connected with the above ? ie. do you only get an invalid patch if you get a communication problem ?
Quote:
If you could produce a new build which has a workaround for these two errors, I'd be thankful. Currently this has put a major roadblock in my experimentation with various patch sets, attempting to improve profile quality.
The first I can do, the second is not so easy, and indicates a far more serious problem.

[ The only thing that it reminds me of is a problem with the ColorMunki spectrometer in which temperature drift would cause it to fail to read, but I can't recall if that was reported as a communication problem or something else, and it would not recover without a recalibration. ]
Edited by gwgill - 5/17/13 at 1:31am
post #147 of 1700
@gwgill, maybe a good solution would be to simply wait 10 seconds whenever a fatal error occurs (any of those reported by cyberbeing), after those 10 seconds simply try again. Repeat that 5 times. If it still fails, show a message box and allow the user to retry or abort.
post #148 of 1700
Quote:
Originally Posted by gwgill View Post

First report of this kind I've received. It could be system dependent, and therefore tough to track down. What operating system are you running on ? (MSWindows ??). What instrument ?
(If it's an i1pro, what revision ?). What options did you use ? Have you ever captured debug output when this happens ? (ie. run "dispwin -D5 etc etc 2> log.txt")

Windows 7 SP1 x64 (HPET enabled, useplatformclock = yes)
Gigabyte GA-Z77X-UD3H (occurs with both VIA and Intel USB ports)
i1pro rev D (605xxx serial)
dispread -v -w -H -F -k

I've not captured a debug log. I'll start running dispwin with -D5 from now on until I catch the problem.

Quote:
Originally Posted by gwgill View Post

Is this connected with the above ? ie. do you only get an invalid patch if you get a communication problem ?

Well I always seem to get communication errors on the same run as an invalid XYZ error, but I can also sometimes get multiple communication errors during a run without an invalid XYZ error.

Very random in nature, since I just finished measuring a 3844 patch set (targen -d3 -e20 -s81 -g81 -b9 -f3844 -c 512_pre.icm GDM-F520_5-16-2013_3844) without either error just now.
Attempt prior on the same patch set had 3 communication errors but not invalid XYZ.
First attempt had 6 communication errors and an invalid XYZ error at the end.

[Edit: Unrelated to this, but is there anything which can be done to improve tone/gradient smoothness (prevent banding) with XYZ cLUT ICC profiles? Even with this massive patch set, my LAB cLUT profiles are ~10x smoother than the XYZ cLUT on full color spectrum gradients. High values of colprof -r didn't seem to make any difference. Why can LAB profiles re-map out-of-gamut colors while retaining tone smoothness while XYZ profiles are seemingly unable to?]

It doesn't seem to have any direct relationship to number of patches, since the communication errors can occur anywhere (beginning, middle, end) of a patch set.

I would estimate a 0.1% chance of it occurring for every patch, so statistically the likelihood of encountering it just increases with more patches.

Quote:
Originally Posted by gwgill View Post

[ The only thing that it reminds me of is a problem with the ColorMunki spectrometer in which temperature drift would cause it to fail to read, but I can't recall if that was reported as a communication problem or something else, and it would not recover without a recalibration. ]

I've been slowly moving towards improving my temperature fluctuation situation as I've started measuring these very time consuming larger patch sets, but unfortunately I've seen both these errors in all the below situations on my GDM-F520 CRT.

Hand-holding my i1pro in direct contact mode

Held in place by masking tape in direct contact mode.

Held by a makeshift "i1pro holder+stand" ~1 inch from display (not in direct contact).
__
Edited by cyberbeing - 5/17/13 at 5:55am
post #149 of 1700
Quote:
Originally Posted by N3W813 View Post

Looks like black and near black levels are still being significantly elevated when 'Black Point Compensation' is disabled on DispcalGUI. I am confirming the same result as cfelicio; flashing bars all the way down to RGB 10 viewing the black clip pattern. Calibration/profile files attached.

I'm noticing a bit of strange behavior with black levels as well, after trying to use dispcal before collink once again.


"collink -a disp.cal" + Linear VideoLUT has a much higher black level than "collink" without "-a" + Dispcal VideoLUT.


"collink -IB -a disp.cal" clips at 10 on the black clip pattern. (Black = ~0.096 cd/m2 w/ Linear VideoLUT)

"collink -Ib:2.4 -a disp.cal" clips at 13 on the black clip pattern. (Black = ~0.066 cd/m2 w/ Linear VideoLUT)

"collink -IB" clips at 16 on the black clip pattern. (Black = ~0.043 cd/m2 w/ Dispcal VideoLUT) <- Nominal result

"collink -Ib:2.4" clips at 20 on the black clip pattern. (Black = ~0.043 cd/m2 w/ Dispcal VideoLUT)


Despite how DispcalGUI's "Black Point Compensation" seems to be helping a few others, it doesn't seem to be making any difference when I re-tested these 4 cases with a Lab cLUT profile.

Note: Black level pre-calibration ~0.034 cd/m2 | dispcal -G2.4 -f0 | targen -d3 -e20 -s81 -g81 -b9 -f3844 -c 512_pre.icm | Lab cLUT used as collink destination display ICC profile
__
Edited by cyberbeing - 5/17/13 at 4:50pm
post #150 of 1700
I do not know how to explain myself. But did not think it looks right with ArgyllCMS

Without ArgyllCMS. Gamma = 2.2



With ArgyllCMS. Gamma = 2.2
Code:
collink.exe -v -3m  -qh  -et  -Et  -Ib:2.2 -G  -ial  Rec709.icm  display.icm  madvr.icm



New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS