Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Yes, this flavor of 4K->1080p downscaling is based on the idea of working directly with the 4:2:0 YUV data encoded in the H.264 file. Since the UV chroma data is already subsampled at half the horizontal and vertical resolution as the Y luma data, the chroma data could be used directly as 1080p 4:4:4 UV data without resampling it. The luma macroblocks would be decoded into 8-bit monochromatic pixels. Each 2x2 block of 8-bit luma pixels would then be summed to produce a single 10-bit subsampled luma pixel. The major advantage is that the original precision of the data samples is preserved without averaging - the only thing that is downscaled is the spatial resolution of the image.Not sure if that's actually true. Remember, this is 4:2:0 chroma sampling we're talking about. That means that while luma may be 10-bit, chroma is still 8-bit - one chroma value every 4 pixels.
There seems to be some controversy and varied opinion about the validity of this concept. I don't yet have an opinion. But I do have a question.Yes, this flavor of 4K->1080p downscaling is based on the idea of working directly with the 4:2:0 YUV data encoded in the H.264 file.
... Each 2x2 block of 8-bit luma pixels would then be summed to produce a single 10-bit subsampled luma pixel. The major advantage is that the original precision of the data samples is preserved without averaging...
The 5d-RGB bloke has started development...
http://www.eoshd.com/content/12594/exclusive-first-app-resample-panasonic-gh4-4k-8bit-10bit-444
You're confusing dynamic range with bit-depth. The theoretical discrepancy you describe results in a loss of 0.3% at the bright end of the luma dynamic range, which is equivalent to clipping the highlights at 99.7 IRE instead of 100. In practice, neither the camera sensor nor the human eye can resolve such a minute difference in highlight intensity. Aside from this imperceptible discrepancy, with pixel summing the sensor's entire dynamic range is preserved intact at 10-bit resolution, all the way down to the noise floor in the darkest shadows. The reason there is no loss of data is because each 4-pixel sum is accumulated in a 10-bit register, but not averaged (i.e. it's not divided by 4). The result is an undegraded, downscaled 10-bit luma signal that ranges from 0 - 99.7 IRE.This may not entirely be true. You can add 4 time 255 but you will never get 4 * 256 -1.
If data was preserved more accurately, you would get a real 10 bit value, but with 8 bits for individual values, always something is lost. If All would have x,3 then the total value would be 4 times x + 1,2. You'd lose the 0,2 of course, but you would have the extra 1. You lose that now.
In practice, neither the camera sensor nor the human eye can resolve such a minute difference in highlight intensity.
Are you just trolling us or what? If it's all ruined for you because the 10-bit summed pixel values only go up to 1020 instead of 1023, you'll probably go ballistic over this:Anyway, you won't get a fully 10-bit value at all, because there are at least 3 values that you will never get.
Are you just trolling us or what? If it's all ruined for you because the 10-bit summed pixel values only go up to 1020 instead of 1023, you'll probably go ballistic over this:
The 8-bit luma values are produced by debayering and binning the sensor's 12-bit sensels into a 4K array of pixels. The results are then quantized into 8-bit H.264 macroblocks at 4K resolution. Since the 8-bit round-off errors you're referring to are distributed in a numerically even manner, they statistically cancel out whenever pixels are combined to produce a lower resolution version of each frame. That's why their 8-bit precision is not degraded by subsampling.If you want to take out the error component, you will have to average the data. You then get a more realistic 8-bit value, which may or may not differ from any 8-bit value acquired in another way.
What you don't seem to understand is where the extra 2 bits of precision comes from in the summed 10-bit subsampled pixels. It's not in the least significant bits - their statistical precision is neither degraded nor improved. Where you get an additional 2 bits is in the most significant bits, which now range up to 1020 rather than 255. That, by definition is a 10-bit result, subsampled from 4K down to 1080p, with no loss of precision in the numerical results.
No, it's not numerical precision that is lost, it's only the top 1% of your numerical range that is lost (9 values out of 1000). As I explained earlier, that's like clipping your output to 99 IRE rather than 100, a virtually imperceptible difference.You take 10 numbers ranging from 0-9999 ("12 bit"). You reduce this to 10 numbers ranging from 0-99 ("8 bit"). Now you take 10 of those to form one number ranging from 0-999 ("10 bit"), you think. (You take 10 because these digits are not bits.)
But because those numbers are rounded or truncated to integer values, you will never get the values 991 to 999. It's obvious you lose precision here.
That's true only when all ten original pixels contain precisely the same numerical value. In real life, due to minute variations in light dispersion and sensor noise, a cluster of photosites will only rarely produce identical readings. When you sum them all together, those variations are combined without loss in precision, which effectively filters out the high-resolution noise just as a single large photosite would have done.But the same goes for all those values that are in the range 0-999. You add 10 of them, but if you originally had 10 values of 2345, the result will be 230 and not 234 or 235 which you might expect.