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

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)?

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.

yep, I was merely replying in regards to dpnaylor's question about CalMAN Home.

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.

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?)

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)

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.

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


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

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.

Doesn't "8 bit in" -> "LUT correction" -> "8 bit out" also create banding? Or is that the same as posterisation?

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 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

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.


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.

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.

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 ).

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

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.

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.

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.

The VideoEQ uses a 10-bit LUT with values from 0-1023 in the format:
I believe the CMS matrix is calculated in 12-bit and is stored as:
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.

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.

Andrewfree, is the RGB signal you are sending 8 bit?