or Connect
AVS › AVS Forum › Display Devices › Display Calibration › The VideoEq -- A low cost external grayscale/gamma/cms tool
New Posts  All Forums:Forum Nav:

The VideoEq -- A low cost external grayscale/gamma/cms tool - Page 2

post #31 of 714
Thread Starter 
Quote:
Originally Posted by dpnaylor View Post

I'm guessing If I go this route that I am going to have to change my Calman home license to the enthusiast version to support the VideoEQ pro?

Okay, it's starting to sound like you need CalMAN 4 to use the VEq. You don't. Until we have a chance to use the stand-alone CMS tool it's not clear that it would be worth it to get an enthusiast license. For a pro who wants to reduce cal time to "half an hour" direct control is great. For a typical home user -- asking if it's worth the extra dollars -- the stand-alone tool sounds sufficient.
post #32 of 714
As usual two differing opinions on whatever gets asked on here.

How would I be able to feed my VideoEQ with 10 bits? My existing BluRay player (Sony BDP-S350) outputs at 8 bit unless I'm mistaken. What do I need to look for to achieve this (bearing in mind adding another VP wouldn't be preferable, but perhaps if I had to use something like DVDO Edge to acheive this then it could be worth considering)?
post #33 of 714
Thread Starter 
Quote:
Originally Posted by Kelvin1965S View Post

How would I be able to feed my VideoEQ with 10 bits?

Get a new BD player. They've gotten quite inexpensive and many/most do Deep Color.
post #34 of 714
Quote:
Originally Posted by bodosom View Post

Okay, it's starting to sound like you need CalMAN 4 to use the VEq. You don't. Until we have a chance to use the stand-alone CMS tool it's not clear that it would be worth it to get an enthusiast license. For a pro who wants to reduce cal time to "half an hour" direct control is great. For a typical home user -- asking if it's worth the extra dollars -- the stand-alone tool sounds sufficient.

The VideoEq will ship with its own windows app for controlling the grayscale/gamma at 11 points and 6 axis CMS for RGBCMY Hue, Sat, Brightness kind of like a windows based remote control via USB.

What CalMAN v4 adds to the mix is you can control the VideoEq directly within our charts as well as all of the other video processors and displays that have external control via USB/RS-232.
post #35 of 714
Quote:
Originally Posted by derekjsmith View Post

The VideoEq will ship with its own windows app for controlling the grayscale/gamma at 11 points and 6 axis CMS for RGBCMY Hue, Sat, Brightness kind of like a windows based remote control via USB.

What CalMAN v4 adds to the mix is you can control the VideoEq directly within our charts as well as all of the other video processors and displays that have external control via USB/RS-232.

Thanks Derek for clearing that up....Can't wait to hear more about this. It sounds like people are starting to chime in.
post #36 of 714
Quote:
Originally Posted by bodosom View Post

Okay, it's starting to sound like you need CalMAN 4 to use the VEq. You don't.

yep, I was merely replying in regards to dpnaylor's question about CalMAN Home.
post #37 of 714
Derek you mention in the YouTube video above that you're working with display manufacturers to allow CalMAN4 to directly control the display's CMS so you can use the same click-and-drag interface that's available for the VideoEq series - are you able to expand on that at all? I'd love to see CalMAN4 working directly with my RS35, and I'm sure there are plenty of other people here who own displays with full CMS's that would love some more info.

I'm sure I'm grasping at straws here and that you're not able to comment yet, but I figured I'd ask the question anyways because the prospect is very, very exciting.
post #38 of 714
Quote:
Originally Posted by Kelvin1965S View Post

How would I be able to feed my VideoEQ with 10 bits?

BD players can produce 4:2:2 YCbCr HDMI output, which is always 12-bit (and existed years before Deep Color). Players typically use just 8 out of the 12 bits and pad the lowest 4 bits with zeros. Nevertheless, the signal is 12-bit. Therefore, when you feed a 4:2:2 YCbCr signal to the VideoEq, the VideoEq is receiving a 12-bit signal, and the VideoEq is producing a 12-bit signal.

The question is: How many of those 12 bits is the VideoEq actually using?

(and how many is your display using?)
post #39 of 714
Quote:


BD players can produce 4:2:2 YCbCr HDMI which is always 12-bit output...

Isn't BD source encoded 8-bit 4:2:0 just like DVD? So even if a player is outputting more than 8-bits, it's not like it's 'real' information that was source encoded?

Dave
post #40 of 714
Quote:
Originally Posted by dlarsen View Post

Isn't BD source encoded 8-bit 4:2:0 just like DVD? So even if a player is outputting more than 8-bits, it's not like it's 'real' information that was source encoded?

Dave

Yes, but with the VideoEQ limiting its output bit-depth to the input bit-depth, you may not have any more data going in, but you will have more coming out of the VideoEQ. (and you need more precision if you're making adjustments, otherwise you're throwing away steps of gradation)
post #41 of 714
Quote:


you may not have any more data going in, but you will have more coming out of the VideoEQ.

I understand that. My point was that at best it's synthesized data, not real native data that was source encoded. The source is 8-bit 4:2:0. You can't really turn that into 12 bit 4:4:4 as you can't pull data that wasn't in the source out of thin air.

Dave
post #42 of 714
Thread Starter 
Quote:
Originally Posted by dlarsen View Post

Isn't BD source encoded 8-bit 4:2:0 just like DVD? So even if a player is outputting more than 8-bits, it's not like it's 'real' information that was source encoded?

Dave

Even more generally anytime you're doing integer arithmetic you want to work with as much precision as possible to minimize rounding errors (which in some circumstances are perniciously non-random). Hence the desire for the VEq to accept 8 bits but do everything in 16-bit and them send the maximum the display will accept. Since it doesn't work that way (at this time) you have to force it into > 8-bit mode. At least we hope it's not just truncating the input to 8 doing the math and then padding the results to > 8.
post #43 of 714
Quote:
Originally Posted by dlarsen View Post

I understand that. My point was that at best it's synthesized data, not real native data that was source encoded. The source is 8-bit 4:2:0. You can't really turn that into 12 bit 4:4:4 as you can't pull data that wasn't in the source out of thin air.

Dave

It's not pulling more data out of the source, it's avoiding errors from adjusting things via the LUT and giving you more control over it.

If you have 8-bit data in, and 8-bit data out, adjusting any one point is going to remove steps of gradation.

With 8-bit data, you have 0-255 as possible ranges for data.
Say you have slightly too much red at 50%stim, to adjust that via a LUT you change it from 128,128,128 to 127,128,128, removing the extra red from that point.

However, this means you now have both inputs of 128,128,128 and 127,127,127 with a red point being output as 127 so you have effectively thrown away a step of gradation and created (slight) posterisation.

If you treated the values as 10-bit though, even simply taking input value ×4, you could have:

512,512,512 (128) input being output as 511,512,512 , 510,512,512 or 509,512,512
With 508,508,508 (127) being left alone.

So with 10-bit you have lowered the amount of red at 50% but you still have two distinct points instead of compressing them both to the same value, and you have finer control over the LUT.

The more you change the LUT, the more damaging it will be. This is why I suspect that I will not be able to eliminate the posterisation I'm seeing. (though tweaking the LUT has certainly improved things)


And while I won't go into it here, even if the data is stored as 8-bit 4:2:0 YCbCr on the disc, you need much more precision to get that data displayed accurately on your screen.
post #44 of 714
Quote:


It’s not pulling more data out of the source,

Agreed. It can't, as it was never there to begin with.

Quote:


The more you change the LUT, the more damaging it will be. This is why I suspect that I will not be able to eliminate the posterisation I'm seeing.

Also agreed. Adding psudeo, synthetic bits can't really do that much. The source had 220 valid steps and had its chroma resolution sub sampled. That damage is done and is unrecoverable.

The box may be dandy but I don't think it can turn 8-bit 4:2:0 into 10 or 12 bit 4:4:4. You can't make a silk purse out of a sows ear.

Dave
post #45 of 714
It wouldn't be adding data, it would let you shift it around (what a LUT does) without overlapping other data. (posterisation)

If you keep 8-bit as 8-bit, any change you make is going to overlap another value, reducing the available number of steps of gradation.

If you have 8-bit in and 10-bit out, you can make changes and still retain the original 256 steps, just shifted around a bit. (because you now have 1024 positions to move them to instead of 256)
post #46 of 714
Quote:
Originally Posted by andrewfee View Post

It wouldn't be adding data, it would let you shift it around (what a LUT does) without overlapping other data. (posterisation)

If you keep 8-bit as 8-bit, any change you make is going to overlap another value, reducing the available number of steps of gradation.

If you have 8-bit in and 10-bit out, you can make changes and still retain the original 256 steps, just shifted around a bit. (because you now have 1024 positions to move them to instead of 256)

You have to understand that Dave doesn't believe working in 8-bit causes banding problems or is a bottleneck. Your explanations will be wasted. But you are completely correct, and it's why you want to maintain more than 8-bits past any kind of LUT processing step like messing with gramma, etc or you end up with a lot less than 8-bits effectively because you end up skipping levels or crushing levels into the same value.
post #47 of 714
Quote:
Originally Posted by andrewfee View Post

This is why I suspect that I will not be able to eliminate the posterisation I'm seeing.

Doesn't "8 bit in" -> "LUT correction" -> "8 bit out" also create banding? Or is that the same as posterisation?
post #48 of 714
Quote:


If you have 8-bit in and 10-bit out, you can make changes and still retain the original 256 steps, just shifted around a bit.

You only had 256 (220 valid) unique steps in the Y channel to begin with. While you may be able to put them into more discrete bins, You’ll still only have 220 unique valid Y information steps. If you’re experiencing posterisation because the source was 8 bit, then that posterisation will still be there. Because it was encoded in the source at 8-bit. Just because you can step on a stair twice or sidestep, it doesn’t make the staircase any finer or bigger.

Quote:


You have to understand that Dave doesn't believe working in 8-bit causes banding problems or is a bottleneck.

If you think that adding bits to the back end can overcome the limitations that were encoded and distributed in the source because it was only 8-bits, then I think you’ll be very disappointed that this won’t be turning your 8-bit 4:2:0 video into 10 or 12 bit 4:4:4. 220 valid unique original steps will still be 220 valid unique steps. Thin air, sows ear, free lunch…

Dave
post #49 of 714
Thread Starter 
Okay, move along, nothing to see here....
post #50 of 714
Quote:
Originally Posted by dlarsen View Post

You only had 256 (220 valid) unique steps in the Y channel to begin with. While you may be able to put them into more discrete bins, You’ll still only have 220 unique valid Y information steps. If you’re experiencing posterisation because the source was 8 bit, then that posterisation will still be there. Because it was encoded in the source at 8-bit. Just because you can step on a stair twice or sidestep, it doesn’t make the staircase any finer or bigger.

If you remap stuff in only 8-bit then you end up with a lot fewer than 254 unique steps. That's why going to 10 bit is very advantageous.

Quote:


If you think that adding bits to the back end can overcome the limitations that were encoded and distributed in the source because it was only 8-bits, then I think you’ll be very disappointed that this won’t be turning your 8-bit 4:2:0 video into 10 or 12 bit 4:4:4. 220 valid unique original steps will still be 220 valid unique steps. Thin air, sows ear, free lunch…

Dave

That's not what he's saying and you know it.

If you are going to process the video, you want to be doing it in more than 8-bit, and you want to keep it in more than 8-bits all the way to the end. Otherwise you end up with effectively less than 8-bit.

It's that simple. It's been explained to you for several years. If you don't understand why, or refuse to accept it, fine. But please don't start another argument about it here and sink yet another thread.
post #51 of 714
I'll try my hand: If you map 8 bits of data onto 8 bits of correction, the resulting waveform has much more than 8 bits of precision. Like in the decimal world, multiply 34 by 13. Both have 2 significant digits. But the result is 442. This are 3 significant digits. And, that new significant digit is valid. It isn't made up. It isn't spurious. It is REQUIRED to carry the complete, true result.

The same is true when applying LUT correction to a binary value. If you just truncate the result off, you're throwing away valid results of the CORRECTED signal, not the original signal. The resulting wave-form will have steps it shouldn't have.
post #52 of 714
Oops, sorry if I've derailed the thread.

It sounds like it might be worth me switching to 4:2:2 output on my player (or some future 'better' player) as my HD350 will accept this number of bits anyway, if it helps with the VideoEQ. This would mean not using my Lumagen at all as it's DVI and thus limited to 8 bit (though I haven't noticed banding/posterisation using it to correct my gamma, so maybe I'm not discerning enough to worry about it ).
post #53 of 714
Quote:


If you are going to process the video, you want to be doing it in more than 8-bit, and you want to keep it in more than 8-bits all the way to the end. Otherwise you end up with effectively less than 8-bit.

This seems like a very easy concept to grasp. If you are going to do non-linear transformations, you're going to want 'n' extra bits to hold onto the floating point values during the computation. To do otherwise means that you are completely truncating valid data, and to make matters worse this type of error is compounded with each intermediate calculation before the final value is computed.

I think (hope) we can all agree that:

3.9 + 5.9 + 9.9 = 20 (rounded to nearest integer)
is more correct than
3 + 5 + 9 = 17
where each floating point value is first truncated to an integer value
post #54 of 714
Quote:
Originally Posted by derekjsmith View Post

Quote:
Originally Posted by Erik Garci View Post

Along those lines, 4:2:2 YCbCr is always 12-bit on HDMI (and existed years before Deep Color), so will the VideoEq take full advantage of all 12 bits, or will it just pad the lowest 4 bits with zeros (as most devices do)?

Internally it uses 16 bit processing so no loss in signal. But the LUT is 10 bit and the CMS is 12 bit. So with the LUT on a 12 bit signal you will get padding on the gamma/grayscale processing.

The quote above is from the earlier thread. It seems that the 10-bit LUT is the bottleneck that limits the VideoEq's output to just 10 bits (padding the lowest 2 bits with zeros).

Now that the VideoEq is being released, maybe someone can post a more detailed answer to my question.
post #55 of 714
I don't want to de-rail this thread any more (but what the hell), but I think of the 8/10/12 bit-ness issue as this: We are trying to avoid 8bit per channel transformed into effectively 7 bits per channel. If you don't have better resolution in your transforms, and you don't output in higher bits that you input, you actually risk degrading below the original bit-depth. No one is trying to get -more- bit depth out of this, we simply want to preserve what we have.

My solution is to route all my sources through a receiver which will pad all sources to 10bits per channel no matter what the input is. I am hoping that 10bits in/out the VideoEQ is enough to not visibly degrade 8bit per channel source data.
post #56 of 714
Quote:
Originally Posted by amt View Post

I don't want to de-rail this thread any more (but what the hell), but I think of the 8/10/12 bit-ness issue as this: We are trying to avoid 8bit per channel transformed into effectively 7 bits per channel. If you don't have better resolution in your transforms, and you don't output in higher bits that you input, you actually risk degrading below the original bit-depth. No one is trying to get -more- bit depth out of this, we simply want to preserve what we have.

My solution is to route all my sources through a receiver which will pad all sources to 10bits per channel no matter what the input is. I am hoping that 10bits in/out the VideoEQ is enough to not visibly degrade 8bit per channel source data.

One thing to mention when you talk about bit depth, remember that 8 bit is 256 steps, video is only 220 steps (240 if you include WTW as valid signal). so there is already some wiggle room. A 7 bit signal is only 128 steps, so even with pretty aggrssive correction you'll probably still have 200+ steps, so at worst it's more like 7.6 bit

But yeah 8bit in 8bit out is going to lose some data, but everything in video is a compromise, the question is does the value of correction outweight the loss of detail correcting 8bit to 8bit causes (of couse you need higher precision internal processing). From all the demo's I've seen the answer is undoubtly yes.
post #57 of 714
Quote:
Originally Posted by sotti View Post

the question is does the value of correction outweight the loss of detail correcting 8bit to 8bit causes (of couse you need higher precision internal processing). From all the demo's I've seen the answer is undoubtly yes.

I agree! I have a Lumagen Vision with my RS1. I get banding. I also get greens I can stomach. The color correction and gamma control is TOTALLY worth the banding.
post #58 of 714
Quote:
Originally Posted by Erik Garci View Post

The quote above is from the earlier thread. It seems that the 10-bit LUT is the bottleneck that limits the VideoEq's output to just 10 bits (padding the lowest 2 bits with zeros).

Now that the VideoEq is being released, maybe someone can post a more detailed answer to my question.

The VideoEQ uses a 10-bit LUT with values from 0-1023 in the format:
Code:
[LUT],Red,Green,Blue,Gamma
0000 = ,0000,0000,0000,0000
0001 = ,0001,0001,0001,0000
0002 = ,0002,0002,0002,0000
0003 = ,0003,0003,0003,0000
0004 = ,0004,0004,0004,0000
0005 = ,0005,0005,0005,0000
0006 = ,0006,0006,0006,0000
0007 = ,0007,0007,0007,0000
0008 = ,0008,0008,0008,0000
0009 = ,0009,0009,0009,0000
0010 = ,0010,0010,0010,0000
I believe the CMS matrix is calculated in 12-bit and is stored as:
Code:
[CMS],A,B,C,D
R000 = ,004096,000000,000000,000000
R004 = ,000000,004096,000000,000000
R008 = ,000000,000000,004096,000000
R012 = ,000000,000000,000000,000001
G000 = ,000000,000000,000000,000000
G004 = ,000000,004096,000000,000000
G008 = ,000000,000000,004096,000000
G012 = ,000000,000000,000000,000001
B000 = ,000000,000000,000000,000000
B004 = ,000000,004096,000000,000000
B008 = ,000000,000000,004096,000000
B012 = ,000000,000000,000000,000001
C000 = ,000000,000000,000000,000000
C004 = ,000000,004096,000000,000000
C008 = ,000000,000000,004096,000000
C012 = ,000000,000000,000000,000001
M000 = ,000000,000000,000000,000000
M004 = ,000000,004096,000000,000000
M008 = ,000000,000000,004096,000000
M012 = ,000000,000000,000000,000001
Y000 = ,000000,000000,000000,000000
Y004 = ,000000,004096,000000,000000
Y008 = ,000000,000000,004096,000000
Y012 = ,000000,000000,000000,000001
I'm not very familiar with CMS matrices and there are no tools available from AV Foundry yet to adjust the CMS, so I don't know how it actually works, and haven't had time to experiment with it.

I imagine that it is processed in 12-bit and then rounded down to 8/10-bit for output.

The output format is limited by the input format, so if you have 10-bit going into the VideoEQ, you get 10-bit out. If you have 8-bit going in, you get 8-bit out. (even though the LUT is 10-bit) I can only use RGB in my setup, so I don't know if YCbCr will count as a 12-bit input.


Currently, I've just spent a fair bit of time this afternoon taking measurements and adjusting a LUT by hand from 0-15% in 1% steps, and then 15-100% in 5% steps to ensure that if there is posterisation visible, it is not a result of how they were being calculated below 10%.

I have the data, but I need to create another spreadsheet that will turn the 33 points of data I have into a 1024-point LUT. Once I've done that, I'll be able to determine whether or not I keep the VideoEQ in my video chain.

Having the display this linear is amazingmy CRT has never looked this good. However, the amount of posterisation I've seen with my previous LUTs is too much to ignore. If this doesn't reduce it to an acceptable level, I'm not sure I want to keep it. One of the main reasons I'm still using CRT now is that any digital' display I've had/seen has shown too much posterisation.
post #59 of 714
One thing to bear in mind.

Most digital consumer displays struggle to be completely transparent to 8bit anyway.

The best can get close ( the JVC RS projectors seem quite good in this regard) but most probably won't disclose a small increase in posterising on most imagery.

This doesn't negate the need to strive for transparency but the real world impact may be negligible for most people with current displays.
post #60 of 714
Andrewfree, is the RGB signal you are sending 8 bit?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › The VideoEq -- A low cost external grayscale/gamma/cms tool