|
So for the last couple of years I've been a little bit dissatisfied with GSL's internet streams. They look washed-out. By that I mean that the blacks look kind of gray and the colors look dull.
Today, as I was watching the GSL finals stream on Twitch.tv, which also had this problem, I realized what they're doing wrong.
To explain it requires some knowledge about how analog video encoded the tonal ranges of broadcast images, and how that legacy is still poking its head into modern video production.
The original analog video broadcast standard transmitted each line of video as a continuous, varying signal. You could think of the brightness of each point on that line as a voltage. So, while there were 525 discrete lines of video in the frame, within a line there was just a continuously varying voltage representing brightness.
Because this analog signal was designed to be transmitted via radio, over the air, and picked up by TV owner's antennas, noise was a problem. This noise came from many places, including signal leakage by other electronic equipment, weather effects, and astronomical effects like interaction between the sun and the ionosphere.
So, the designers of analog video defined "black" to be a signal level somewhere above the 0 point, so that noise would have less effect on the darkest darks in the scene. "White" was defined to be a particular intensity of signal above that, but of course there were no limitations to how strong the signal could be. The TV's automatic gain control was expected to scale the highest signals to be white, but there was no assurance that a stronger signal wouldn't get through.
When a color signal was added to video in the late 50s, it was added in a backward-compatible way, so that it could be broadcast alongside the luminance signal that had already made up black-and-white TV. This color signal decomposed into two components -- a blue/yellow channel and a green/red channel. The color space for this was referred to as YUV, with Y representing luminance, U representing blue/yellow, and V representing red/green.
In the early days of digital video in broadcasting, those lines of analog information in each broadcast frame were divided up into pixels, and each pixel represented by a triplet of values, representing Y, U, and V. At first, these channels were (at best) 8 bits each. However, because analog video allowed "sub-black" values and "super-white" values, the black to white range was encoded between 16 and 235, leaving 0-15 for sub-blacks and 236-255 for super-whites.
So, plenty of systems were developed that mapped black to 16 and white to 235, with the intention that they'd be correctly mapped into analog broadcast levels when converted back into viewable (and at that point, analog) video.
This standard has carried forward to today. Most broadcast video systems use a 16-235 range for their black-white range, and retain capability for sub-blacks and super-whites. Even newer systems with a lot more than 8 bits per channel retain proportional chunks of their ranges for sub-blacks and super-whites.
The problem comes when converting video encoded in this way for viewing on a computer. The sRGB color space, which is currently the standard color space for almost all display monitors, modern Macs, and Windows PCs, encodes black at 0 and white at 255 with no allowance for sub-black or super-white.
Thus, it's necessary for video engineers converting signals from broadcast systems to view on computer systems to stretch that 16-235 range to 0-255 at some point in the process. Many video editing packages know about this conversion and offer some control over it, but when preparing images for a stream that go from broadcast equipment to, say, a Flash encoder, someone has to manually intervene to set it up correctly.
As DJWheat pointed out on the most recent Live on Three, GOMTV's production for the GSL at IPL 5 has been excellent. However, because of their emphasis on TV broadcasting, it's quite likely that they have overlooked this issue, particularly because the impact on the look of their images is disappointing, but not dramatic. It's possible that nobody with a broadcast engineering background has ever looked at their converted Internet stream.
I'm contemplating how to communicate this to the GOMTV folks, but I'm concerned that the language barrier and the subtlety of the technical discussion involved will lead to nothing. As a professional with many years of experience in digital imaging who has had to deal with these issues for work, I can say that these matters are not well-understood in many cases even by the people who need to know about them to produce the best-quality output.
So, any thoughts are welcome.
Edit: I have examined a range of GOMTV VODs as well as the Twitch.tv recording of tonight's broadcast and none of them exhibit this problem. However, I have a screenshot from the live broadcast of the award ceremony tonight that exhibits it. Note that I have seen this consistently in their live streams, but looking at their VODs, they all look good.
![[image loading]](http://i.imgur.com/SAlWe.png)
And here's this same image corrected assuming that 16 is a saturated black and 235 is a pure white:
![[image loading]](http://i.imgur.com/cOUPn.png)
Here, by the way, is a similar image off the Twitch.tv replay. It's so far in the other direction that I kind of think someone manually applied an adjustment to fix it:
![[image loading]](http://i.imgur.com/cUJVc.png)
In the histogram of the image, the darkest values start around 17 and the brightest appear at about 250, with most of the whites occurring at 229 and below but some geting a little brighter. This tells me that the problem is probably NOT doubled-up, but is likely present.
The fact that the VODs do not illustrate the problem suggests that there may be some difference between their live-streaming conversion workflow and their VOD recording workflow.
Edit 2: I did mail the GOMTV account on TL asking them to take a look at this blog and to pass it along to their technicians. Maybe it may help!!?
 
|
I'll throw out the additional observation that it's precisely GOMTV's emphasis on broadcast television and their use of professional equipment that makes them susceptible to this problem!
Edit: Wow, thanks for featuring this blog post within minutes! Hopefully this helps get these thoughts to the GOMTV folks.
I want to point out one additional fact: I took a few screenshots of the GSL stream today and opened them up in Photoshop to look at the histogram, which shows how values in the image were distributed between 0 and 255. It was very clear that the darkest blacks were elevated and the highest whites were lowered a bit. I only had a few minutes to look at this, so I couldn't check the exact values, but it suggests that something like what I describe is going on. Most typical Twitch.tv streams broadcast using Xsplit or whatever do not have this problem.
Edit 2: I have edited the OP to include a screen shot along with its corrected version.
|
Ha. As someone who knows about this stuff, you might be spot on here. I, too, have the "something's odd" feeling on GOM's stream. However, it never occurred to me that it might be the colour range. As a Free Quality viewer, I simply assumed it gave the impression because of the poor resolution.
Great job finding out, and I think you've done the explanation quite well. As to the problem of communicating with GOM, no idea.
|
I came to this blog expecting jokes about how tasteless has lost his passion. I am disappointed.
|
I'm working on including some pictures to show what I mean. IBringUFire: Thanks for the confirmation. I think the thing to do is link this blog to Mr. Chae in a PM and hope he can pass it along to someone who might find it useful. Kerotan: Tasteless may be susceptible to jet lag, but I don't think he's lost his passion! :D
|
After some thought, I think your best bet would be to go through Blizzard. It's in their best interest to make SC2 better so they would get the issue solved the quickest.
Edit: nVidia says it's called Dynamic Range:
![[image loading]](http://i.imgur.com/xcalV.png)
|
iTzSnypah: I have some back-channel options to pass this info along through Blizzard, but I guarantee that they're inundated with a lot more customer feedback by far than GOMTV is, so starting with GOMTV might be a better bet.
|
On December 02 2012 20:39 iTzSnypah wrote:
Edit: nVidia says it's called Dynamic Range:
That's one term for it, but I've seen it called various things. I've seen "YUV" used for the narrower range and "YUV-full" used for the 0-255 range. I'm not sure there's consistent terminology.
However, I am certain that it's an issue on their end. In fact, looking at the values in the file I'm examining, it looks like this problem might be doubled-up, that is, that the image values may be compressed into a narrower range like 32-223 or something like that. I'm not sure about this -- I'm installing Photoshop on a different computer now to have a look.
|
Annoyingly, I seem to have accidentally deleted or otherwise lost my screenshot from the award ceremony that illustrated this. Also, I notice that the Twitch.tv VODs do not have this problem, while the live broadcast on Twitch.tv did! How strange!
Edit: Located it, it's now in the OP
|
This YUV range is not the cause of problem you are talking about. Every single video you have seen on your TV was in the 16-235 range, and didn't look "washed-out". You might have a better monitor than usual, but for most monitors, it will not change anything.
The washed-out aspect is more likely to originate in the encoding.
|
Note: I originally said that blacks were adjusted by varying the "gain" on channels in a TV set. The actual parameter is "bias." "Gain" affects the white levels. Sorry, it's been a while since I've had to deal with these issues myself.
On December 02 2012 21:49 Denar wrote:
This YUV range is not the cause of problem you are talking about. Every single video you have seen on your TV was in the 16-235 range, and didn't look "washed-out". You might have a better monitor than usual, but for most monitors, it will not change anything.
The washed-out aspect is more likely to originate in the encoding.
Thanks for the comment, but it's unfortunately not completely correct. You are right that it's an encoding issue, but encoding is all we're discussing here, specifically the encoding specification for the video.
Televisions are specifically set such that the black level (which is 16 in the usual broadcast encoding) is the darkest value that can be displayed. Broadcast color bars include both sub-black (0) and black (16) bars, and the usual procedure is to adjust the TV's channel bias so that in each channel the sub-black and black are visually indistinguishable. There's a white bar that's handled somewhat differently, in that its luminosity is measured by the person adjusting the monitor.
Here's an example of what the SMPTE color bars look like. In the lower right you can see the sub-black, black, and slightly above black bars. On a properly adjusted TV broadcast reference monitor, the black and sub-black are not visually distinguishable, but because you're looking at this image on a computer monitor with software that assumes a 0-255 black to white range, you can see the difference.
![[image loading]](http://www.mediacollege.com/video/test-patterns/images/colour-bars-smpte-75-640x480.gif)
Images that are displayed on computers that use the sRGB standard peg black at 0, so if you take an image that's encoded in the broadcast (16-235) range and display it using software that assumes an input source that's sRGB, you're going to get washed-out blacks and muted whites. You're also going to get minor color shifts that are a result of sRGB not matching the HD standard (called Rec. 709) but unless you're using a color chart to compare you're unlikely to notice those differences.
In my work, we use high-end broadcast equipment to generate our image output, and the movies that are generated for looking at our work in progress are in the 16-235 range because they're intended for display on video equipment that assumes that. When we send out to a client, we have to manually convert these images to 0-255 so that they appear similar on our client's computers to what they look like on our video monitors. The reason is because the client's computers assume a 0-255 encoding for black-white while our video equipment assumes 16-235.
This effect is a real thing. On occasions when we've forgotten this step, clients have complained that the blacks do not look completely black.
|
On December 02 2012 22:00 Lysenko wrote:Show nested quote +On December 02 2012 21:49 Denar wrote:
This YUV range is not the cause of problem you are talking about. Every single video you have seen on your TV was in the 16-235 range, and didn't look "washed-out". You might have a better monitor than usual, but for most monitors, it will not change anything.
The washed-out aspect is more likely to originate in the encoding. Thanks for the comment, but it's unfortunately not completely correct. You are right that it's an encoding issue, but encoding is all we're discussing here, specifically the encoding specification for the video. Televisions are specifically set such that the black level (which is 16 in the usual broadcast encoding) is the darkest value that can be displayed. Broadcast color bars include both sub-black (0) and black (16) bars, and the usual procedure is to adjust the TV's channel gain so that in each channel the sub-black and black are visually indistinguishable. There's a white bar that's handled somewhat differently, in that its luminosity is measured by the person adjusting the monitor. Here's an example of what the SMPTE color bars look like. In the lower right you can see the sub-black, black, and slightly above black bars. On a properly adjusted TV broadcast reference monitor, the black and sub-black are not visually distinguishable, but because you're looking at this image on a computer monitor with software that assumes a 0-255 black to white range, you can see the difference. Images that are displayed on computers that use the sRGB standard peg black at 0, so if you take an image that's encoded in the broadcast (16-235) range and display it using software that assumes an input source that's sRGB, you're going to get washed-out blacks and muted whites. You're also going to get minor color shifts that are a result of sRGB not matching the HD standard (called Rec. 709) but unless you're using a color chart to compare you're unlikely to notice those differences. In my work, we use high-end broadcast equipment to generate our image output, and the movies that are generated for looking at our work in progress are in the 16-235 range because they're intended for display on video equipment that assumes that. When we send out to a client, we have to manually convert these images to 0-255 so that they appear similar on our client's computers to what they look like on our video monitors. The reason is because the client's computers assume a 0-255 encoding for black-white while our video equipment assumes 16-235.
Ok, I see. Nice to learn something today
|
 Yeah, this stuff can be very hard to get one's head around.
Here, by the way, is what those color bars should look like (or close to it) on a properly adjusted broadcast monitor:
![[image loading]](http://i.imgur.com/V6nw7.gif)
Edit: If you ever wondered what those color bars are for, hey, that's one major thing!
Another thing they've been used for in the past is that the color channel for analog TV required manual balancing of the U and V channels, and that would be done by hitting a special button on the display monitor to only show the blue channel, and adjusting the balance between U and V until alternate bars all looked the same brightness. I would expect that this wouldn't be necessary for digital TV, because Y, U, and V are all maintained as separate channels in transmission.
Edit 2: While I was viewing the GSL stream on a TV set, it was being sent to the TV via HDMI from a Mac laptop's Mini DisplayPort output and run through a converter. In that connection, it's pretty clear that all these issues are worked out by the various standards that define how these systems work. Images or movies that looked good on the laptop's display looked fine on the TV, but something that looked washed-out on the display looked washed-out on the TV as well. It may well be that the relevant standards are taking the 0-255 on the Mac monitor and converting them to 16-235 for transmission over the HDMI cable, but if so it's transparent and the TV handles it appropriately.
Edit 3: WOW look at how the midtone gray on the left matches the value of the blue in the TL forum theme!
|
|
|
|
|
Amazing how you came up with this, hope GOM checks it out and fixes their broadcasts.
|
I love learning new things. Thanks so much for this really interesting post!
|
Wow, i'm blown away with your knowledge bombs
I'll look in the AMD Graphic Driver later this evening and see if there is a setting which can somehow workaround until you reached out on GOM!
Edit:
AMD Driver setting:
+ Show Spoiler +
|
I've never really noticed anything (always assumed any quality issues were due to the free "sq" stream).
On December 02 2012 23:26 AmericanUmlaut wrote:
I love learning new things. Thanks so much for this really interesting post!
|
On December 03 2012 00:25 y0su wrote:I've never really noticed anything (always assumed any quality issues were due to the free "sq" stream). Show nested quote +On December 02 2012 23:26 AmericanUmlaut wrote:
I love learning new things. Thanks so much for this really interesting post!
I might have assumed the same thing if I had been watching the free streams, but I've been a paying subscriber to GOMTV and while the resolution is great for the better streams, this issue is still there.
GOMTV is improving their streams in a number of ways for 2013, so I hope they can perhaps address this as well, particularly if it's just a software configuration fix!
|
|
|
|
|
|
EPT
![[image loading]](http://i.imgur.com/keKbF.png)
