4 ms·

Very cool, undersampling of color still exists in modern codecs, if you see something like YUV420 that means there's 2 chroma (color) pixels for every 4 luminan

by tcas 11y ago

Very cool, undersampling of color still exists in modern codecs, if you see something like YUV420 that means there's 2 chroma (color) pixels for every 4 luminance (brightness) pixels: http://i.stack.imgur.com/U7hxZ.png http://i.stack.imgur.com/U7hxZ.png Since our eyes are more preceptive to detail rather than absolute color, you can lower your bitrate without perceived video quality.

CyberDildonics 11y ago
More specifically our eyes see luminance more than hue or saturation, and the change of gradients more than gradients or absolute values.
- deleted 11y ago
  [deleted]
theoh 11y ago
Sun's forgotten (I believe) Cell codec used the colour cell idea even more directly: http://docs.oracle.com/cd/E19957-01/802-1318-10/ug11cell.html http://docs.oracle.com/cd/E19957-01/802-1318-10/ug11cell.htm... "A cell encoder breaks the video into cells. A cell is 16 pixels, arranged in a 4x4 group (Figure B-1). Cells are encoded into the bytestream in scanline order, from left to right and from top to bottom. The basic encoding scheme used in both versions of Cell is based on an image coding method called Block Truncation Coding (BTC). The 16 pixels in a cell are represented by a 16-bit mask and two intensities or colors. These values specify which intensity to place at each of the pixel positions. The mask and intensities can be chosen to maintain certain statistics of the cell, or they can be chosen to reduce contouring in a manner similar to ordered dither. The primary advantage of BTC is that its decoding process is similar to the operation of character fonting in a color framebuffer. The character display process for a framebuffer takes as input a foreground color, a background color, and a mask that specifies whether to use the foreground or background color at each pixel. Because this function is so important to the window system, it is often implemented as a display primitive in graphics accelerators. The Cell compression technique leverages these existing primitives to provide full-motion video decoding without special hardware or modifications to the window system."
- kayamon 11y ago
  This is very, very similar to DXT encoding that all GPUs use (and is also how the ZX Spectrum's hardware worked).
gilgoomesh 11y ago
A lot of these "rules" with color use some broad generalizations. When you work with video compression a lot, you start training yourself to see color differently and the illusions begin to fall apart. For me: I really don't enjoy looking at 4:2:0 or 4:1:1 chroma subsampling (4:2:2 usually doesn't cause problems) 4:2:0 sort of works for live scenes which don't typically have sharp chroma boundaries but when you see solid red/blue graphics superimposed over a scene, the blocky bleed of color across the scene is like knives in my eyes.
- coldpie 11y ago
  I'm interested in this. When you said, "When you work with video compression a lot," what did you mean? Working with video compression at an algorithm level, or applying different compressions to the same video and comparing the results, or something else?
  - gilgoomesh 11y ago
    The middle one ("applying different compressions to the same video and comparing the results"). I write streaming video servers. An aspect of the job is continuously optimizing parameters and codecs to satisfy PSNR and perceptual video quality test cases across a large library of test files. It's not a fun aspect of the job.
- theandrewbailey 11y ago
  > but when you see solid red/blue graphics superimposed over a scene, the blocky bleed of color across the scene is like knives in my eyes. I still wonder why that happens to red, mostly because it looks like someone's bleeding everywhere. I don't seem to notice it for green or blue. At first I thought it was the downsampling, but it has to be something else (a combination, maybe?), since JPEG seems to handle downsampled red comparatively better when highly compressed. Right now, I just think it's a flaw in H.264, it's encoders and/or decoders.
  - gilgoomesh 11y ago
    Bleed definitely happens with blue too but since solid blue chrominance is less common in graphics (graphics tend to use brighter sky/azure/royal blue) whereas solid red is quite common. But bleed won't happen with green because green is basically the luminance channel in YCbCr/YUV. This means that green runs at full sample resolution compared to red and blue which run at 50% to 25% resolution (depending on subsampling).

by tcas 11y ago

CyberDildonics 11y ago

More specifically our eyes see luminance more than hue or saturation, and the change of gradients more than gradients or absolute values.

deleted 11y ago
[deleted]

theoh 11y ago

Sun's forgotten (I believe) Cell codec used the colour cell idea even more directly: http://docs.oracle.com/cd/E19957-01/802-1318-10/ug11cell.html http://docs.oracle.com/cd/E19957-01/802-1318-10/ug11cell.htm... "A cell encoder breaks the video into cells. A cell is 16 pixels, arranged in a 4x4 group (Figure B-1). Cells are encoded into the bytestream in scanline order, from left to right and from top to bottom. The basic encoding scheme used in both versions of Cell is based on an image coding method called Block Truncation Coding (BTC). The 16 pixels in a cell are represented by a 16-bit mask and two intensities or colors. These values specify which intensity to place at each of the pixel positions. The mask and intensities can be chosen to maintain certain statistics of the cell, or they can be chosen to reduce contouring in a manner similar to ordered dither. The primary advantage of BTC is that its decoding process is similar to the operation of character fonting in a color framebuffer. The character display process for a framebuffer takes as input a foreground color, a background color, and a mask that specifies whether to use the foreground or background color at each pixel. Because this function is so important to the window system, it is often implemented as a display primitive in graphics accelerators. The Cell compression technique leverages these existing primitives to provide full-motion video decoding without special hardware or modifications to the window system."

kayamon 11y ago
This is very, very similar to DXT encoding that all GPUs use (and is also how the ZX Spectrum's hardware worked).

gilgoomesh 11y ago

A lot of these "rules" with color use some broad generalizations. When you work with video compression a lot, you start training yourself to see color differently and the illusions begin to fall apart. For me: I really don't enjoy looking at 4:2:0 or 4:1:1 chroma subsampling (4:2:2 usually doesn't cause problems) 4:2:0 sort of works for live scenes which don't typically have sharp chroma boundaries but when you see solid red/blue graphics superimposed over a scene, the blocky bleed of color across the scene is like knives in my eyes.

coldpie 11y ago
I'm interested in this. When you said, "When you work with video compression a lot," what did you mean? Working with video compression at an algorithm level, or applying different compressions to the same video and comparing the results, or something else?
- gilgoomesh 11y ago
  The middle one ("applying different compressions to the same video and comparing the results"). I write streaming video servers. An aspect of the job is continuously optimizing parameters and codecs to satisfy PSNR and perceptual video quality test cases across a large library of test files. It's not a fun aspect of the job.
theandrewbailey 11y ago
> but when you see solid red/blue graphics superimposed over a scene, the blocky bleed of color across the scene is like knives in my eyes. I still wonder why that happens to red, mostly because it looks like someone's bleeding everywhere. I don't seem to notice it for green or blue. At first I thought it was the downsampling, but it has to be something else (a combination, maybe?), since JPEG seems to handle downsampled red comparatively better when highly compressed. Right now, I just think it's a flaw in H.264, it's encoders and/or decoders.
- gilgoomesh 11y ago
  Bleed definitely happens with blue too but since solid blue chrominance is less common in graphics (graphics tend to use brighter sky/azure/royal blue) whereas solid red is quite common. But bleed won't happen with green because green is basically the luminance channel in YCbCr/YUV. This means that green runs at full sample resolution compared to red and blue which run at 50% to 25% resolution (depending on subsampling).