HCFR - Open source projector and display calibration software
621 - 640 of 13756 Posts
Joined
·
2,237 Posts
The reference points I provided next to my meter measures are what they provided. You can see that the correction for white x is. 007, y is 0.
They provided the same info for RGB.
The reference points I provided next to my meter measures are what they provided. You can see that the correction for white x is. 007, y is 0.
They provided the same info for RGB.
Will both the retail and the OEM version of the i1 display will work with the new version of HCFR? I'm considering upgrading my d2, but the OEM must be purchased with Chromapure or CalMan. At this point, with the add on licenses price is just getting out of my affordability range for a hobby. I can likely get a retail version for @ $210-$250, where as $420-$589 is the OEM with CP or CM software.
Will both the retail and the OEM version of the i1 display will work with the new version of HCFR? I'm considering upgrading my d2, but the OEM must be purchased with Chromapure or CalMan. At this point, with the add on licenses price is just getting out of my affordability range for a hobby. I can likely get a retail version for @ $210-$250, where as $420-$589 is the OEM with CP or CM software.
Joined
·
2,237 Posts
OK, this is my first try with matrix math. Here is what I did.
Instead of just using the xy values for WRGB as measured for the two probes, I 'assumed' the reference probe was at Rec709 spec. I then used the correction I was given to create the WRGB xy values that my probe would measure.
Example: white x correction was .007 and y correction was 0 based on .309/.329 for my D3 and .316/.329 for the reference . So I 'shifted' reference to Rec709 spec and used .313/.329 and for my 'measured' probe I used .306/.329. When my probe reads .306/.329 the white point is actually spot on at .313/.329. I don't know enough about matrix math to know if this creates an error, but since those are actually the measurements that would be obtained, I was thinking it wouldn't matter. It just helped me 'see' what I had to do about my measurements in the matrices.
So, after going through my maiden voyage into matrix math, Google and I came up with this final value for R. I had some difficulty deciding how to do in Eqn. 8 the ^ -1. The matrix below is based on this interpretation:
R = Nrgb x (Mrgb ^ -1)
and not R = (Nrgb x Mrgb)^ -1
For those who have seen these corrections entered, does this look like a reasonable one given the xy corrections I've already posted for WRGB?
1.024 0.000 0.000
0.000 0.994 0.000
0.000 0.000 0.987
OK, this is my first try with matrix math. Here is what I did.
Instead of just using the xy values for WRGB as measured for the two probes, I 'assumed' the reference probe was at Rec709 spec. I then used the correction I was given to create the WRGB xy values that my probe would measure.
Example: white x correction was .007 and y correction was 0 based on .309/.329 for my D3 and .316/.329 for the reference . So I 'shifted' reference to Rec709 spec and used .313/.329 and for my 'measured' probe I used .306/.329. When my probe reads .306/.329 the white point is actually spot on at .313/.329. I don't know enough about matrix math to know if this creates an error, but since those are actually the measurements that would be obtained, I was thinking it wouldn't matter. It just helped me 'see' what I had to do about my measurements in the matrices.
So, after going through my maiden voyage into matrix math, Google and I came up with this final value for R. I had some difficulty deciding how to do in Eqn. 8 the ^ -1. The matrix below is based on this interpretation:
R = Nrgb x (Mrgb ^ -1)
and not R = (Nrgb x Mrgb)^ -1
For those who have seen these corrections entered, does this look like a reasonable one given the xy corrections I've already posted for WRGB?
1.024 0.000 0.000
0.000 0.994 0.000
0.000 0.000 0.987
Joined
·
242 Posts
I tested different meter options, same result. Im 99,9% sure it will be fixed with longer read time. For sure it is not usable at all like this with spyder 4 over 50% IRE.
ill try get somone to help me finding those files for you.. im no good at that stuff..
I tested different meter options, same result. Im 99,9% sure it will be fixed with longer read time. For sure it is not usable at all like this with spyder 4 over 50% IRE.
ill try get somone to help me finding those files for you.. im no good at that stuff..
Joined
·
6,804 Posts
I don't follow why you are assuming anything, you have the actual measured and reference points. The x,y shifts will be different depending on where you are in the gamut, that's why you need the matrix.
Your interpretation of where the inverse goes is correct but all matrix entries should have a non-zero entry so something didn't work. If you want a shortcut plug the measured and reference points in HCFR and it will do the calculation for you.
I don't follow why you are assuming anything, you have the actual measured and reference points. The x,y shifts will be different depending on where you are in the gamut, that's why you need the matrix.
Your interpretation of where the inverse goes is correct but all matrix entries should have a non-zero entry so something didn't work. If you want a shortcut plug the measured and reference points in HCFR and it will do the calculation for you.
Joined
·
1 Posts
This new version of HCFR with my new Spyder Pro 4 is a awesome setup.
Over the years ,I have being preforming lots of different calibrations on my LG 47 LCD and it never look this good.
![]()
I too had the problem of the meter not showing up in the drop down list.
After some hours, I realize that Windows was automatically loading a driver that the program will not see the meter.
I went to the Device manager and pointed to the driver in the HCFR folder.
It worked !!
Thank you so much for this software update.
John G
Over the years ,I have being preforming lots of different calibrations on my LG 47 LCD and it never look this good.
I too had the problem of the meter not showing up in the drop down list.
After some hours, I realize that Windows was automatically loading a driver that the program will not see the meter.
I went to the Device manager and pointed to the driver in the HCFR folder.
It worked !!
Thank you so much for this software update.
John G
There are 2 places where a correction is made, the matrix correction/meter calibration code within HCFR which uses a (currently slightly broken) 4 colour method and the ccss code in argyll for the i3pro which uses a least squares method. The first lot of code doesn't use secondaries.
John
There are 2 places where a correction is made, the matrix correction/meter calibration code within HCFR which uses a (currently slightly broken) 4 colour method and the ccss code in argyll for the i3pro which uses a least squares method. The first lot of code doesn't use secondaries.
John
I've been playing around with this a bit today and I looked at your results. I get an R matrix of
1.041734 -0.00457 -0.01165
0.012072 0.992504 -0.00335
-0.00652 0.007879 0.979193
But (and it's a fairly big but) this matrix shouldn't be used as a simple adjustment matrix in the current HCFR. There is some renormalization that needs to be done (the sentence below equation 10 in the paper)
Say you start with meaured xyY, save the Y for later work out xyz then multiply by the above matrix to give abc then work out the adjusted xyY as x = a/(a+b+c) y = b/(a+b+c) Y=Y from before. Without the last bit that matrix would make things worse, say using your red example of measured 0.633, 0.334, using the matrix gives abc of (.6575, 0.3390, 0.0308) which then gives xy of 0.64, 0.33 as expected, but if you just applied that matrix to the XYZ values the error goes up.
Obviously I'm looking at fixing this in HCFR so that it all works properly.
John
I've been playing around with this a bit today and I looked at your results. I get an R matrix of
1.041734 -0.00457 -0.01165
0.012072 0.992504 -0.00335
-0.00652 0.007879 0.979193
But (and it's a fairly big but) this matrix shouldn't be used as a simple adjustment matrix in the current HCFR. There is some renormalization that needs to be done (the sentence below equation 10 in the paper)
Say you start with meaured xyY, save the Y for later work out xyz then multiply by the above matrix to give abc then work out the adjusted xyY as x = a/(a+b+c) y = b/(a+b+c) Y=Y from before. Without the last bit that matrix would make things worse, say using your red example of measured 0.633, 0.334, using the matrix gives abc of (.6575, 0.3390, 0.0308) which then gives xy of 0.64, 0.33 as expected, but if you just applied that matrix to the XYZ values the error goes up.
Obviously I'm looking at fixing this in HCFR so that it all works properly.
John
Joined
·
475 Posts
Adjusting RGBHighEnd using the 80% screen works fine with my i1D3 (HCFR 3.0.4.0)
When adjusting RGBLowEnd using the 30% screen, Red and Blue fluctuate a lot and I can't get a stable setting. I try to set it, but once I go back, it's off again. Not sure if this is an issue with the software (i.e. the duration of the reading) or the hardware... or if it's normal?
When adjusting RGBLowEnd using the 30% screen, Red and Blue fluctuate a lot and I can't get a stable setting. I try to set it, but once I go back, it's off again. Not sure if this is an issue with the software (i.e. the duration of the reading) or the hardware... or if it's normal?
It's normal. Adjustments to RGBHighEnd will affect the RGBLowEnd quite a bit, so you need to iterate between the two in order to converge on the optimal setting. Adjustments to RGBLowEnd are also more sensitive than to RGBHighEnd.
Right at the optimal settings, a single step adjustment of RGBLowEnd in R or B can generate a 4% - 8% overswing in either direction on my Samsung ES8000. Sometimes moving the green up or down by one will then allow you to move the red or blue RGBLowEnd sliders without generating as much of a swing...you're a little limited by how much you can move the green slider though, as this affects the overall luminance quite a bit and leads to possibly undesired alterations in gamma....
It's normal. Adjustments to RGBHighEnd will affect the RGBLowEnd quite a bit, so you need to iterate between the two in order to converge on the optimal setting. Adjustments to RGBLowEnd are also more sensitive than to RGBHighEnd.
Right at the optimal settings, a single step adjustment of RGBLowEnd in R or B can generate a 4% - 8% overswing in either direction on my Samsung ES8000. Sometimes moving the green up or down by one will then allow you to move the red or blue RGBLowEnd sliders without generating as much of a swing...you're a little limited by how much you can move the green slider though, as this affects the overall luminance quite a bit and leads to possibly undesired alterations in gamma....
Joined
·
6,804 Posts
refresh mode on plasma:
5-6% red fluctuations at 20% and 30% stimulus. it tends to be stable for several reads and then fluctuates for 2-3 reads and becomes stable again. I think everything from 5-30% needs better optimization of integration time for plasma use.
refresh mode on plasma:
5-6% red fluctuations at 20% and 30% stimulus. it tends to be stable for several reads and then fluctuates for 2-3 reads and becomes stable again. I think everything from 5-30% needs better optimization of integration time for plasma use.
Joined
·
475 Posts
Sorry, don't know how to explain it except in basic terms so this may get wordy. BTW, I'm using i1D3 in Refresh mode and HCFR 3.0.4.0
When I use the 80% window to adjust RGBHighEnd, the Red, Green and Blue Bars are very stable. At worst they may change by 1% in either direction but most of the time it will stay where I set it, even if I need to go back to tweak the settings after making changes in RGBLowEnd.
When I use the 30% window to adjust RGBLowEnd, the Red Bar bounces the most so it's next to impossible to adjust. If I'm patient, there will be periods where it seems to settle down so I'll make my setting (i.e. 100%) , but it doesn't take long for it to start bouncing again. Problem is the next time it settles down it won't be at the same setting... it could settle down at 104% or 95%... you just never know. When I watch it bounce, it goes anywhere from 93% to 106% and it doesn't necessarily do it in single percentages... it could change from 99% to 104% instantly. Blue isn't as bad but it's still unstable enough to drive you bonkers.
Sorry, don't know how to explain it except in basic terms so this may get wordy. BTW, I'm using i1D3 in Refresh mode and HCFR 3.0.4.0
When I use the 80% window to adjust RGBHighEnd, the Red, Green and Blue Bars are very stable. At worst they may change by 1% in either direction but most of the time it will stay where I set it, even if I need to go back to tweak the settings after making changes in RGBLowEnd.
When I use the 30% window to adjust RGBLowEnd, the Red Bar bounces the most so it's next to impossible to adjust. If I'm patient, there will be periods where it seems to settle down so I'll make my setting (i.e. 100%) , but it doesn't take long for it to start bouncing again. Problem is the next time it settles down it won't be at the same setting... it could settle down at 104% or 95%... you just never know. When I watch it bounce, it goes anywhere from 93% to 106% and it doesn't necessarily do it in single percentages... it could change from 99% to 104% instantly. Blue isn't as bad but it's still unstable enough to drive you bonkers.
621 - 640 of 13756 Posts
Join the discussion
Join now to ask and comment!