What are people's opinions on this? I'm thinking they should have included optional 10 bit color in the original blu-ray specs. I know 8 bit can be dithered for improvement but not without adding a certain amount of noise.

What are people's opinions on this? I'm thinking they should have included optional 10 bit color in the original blu-ray specs. I know 8 bit can be dithered for improvement but not without adding a certain amount of noise.

For simplicity of computer processing I wish they had gone straight to 16 bit color. It would not have taken any more bandwidth since it could be easily quantized down to an effective 8 bits during compression if needed but would still allow 16 bit processing everywhere else. Experiments with X264 have shown that causes generally more efficient compression.

- Tom

What are people's opinions on this? I'm thinking they should have included optional 10 bit color in the original blu-ray specs. I know 8 bit can be dithered for improvement but not without adding a certain amount of noise.

They should, but you must also take into account that from the beginning they aimed BD as a mpeg2 format only. And BD50 were not at the same "production level" it is today as it were when they started to work on the spec for BD.

So for BD25 and Mpeg2, 10-12 bits doesnt seem to be as attractive as it would have been on a BD50 with AVC or VC1.

Also add that they could have added 4:2:2 or 4:4:4 for the format.

10bit 4:2:2 would have been much better then 8bit 4:2:0.

Id like to see the difference first before making an opinion. I believe Windows 7 will finally support color depths past truecolor(8-bit) so maybe that will push the industry.

There are no 10-bit decoder chips available today. None. Given that the format has been around for 7 years, I'd have to say they pretty much made the correct decision.

Also, you can't do 10-bit in MPEG-2 or VC-1. It's just not supported and never will be. Only H.264.

Ron

There are no 10-bit decoder chips available today. None. Given that the format has been around for 7 years, I'd have to say they pretty much made the correct decision.

Also, you can't do 10-bit in MPEG-2 or VC-1. It's just not supported and never will be. Only H.264.

Ron
http://nabshow2009.bdmetrics.com/PDT-363760/CoreEL-Technologies-Pvt-Ltd/Single-chip-1080p60-H-264-High-Profile-Decoder.aspx

Product Name: Single chip 1080p60 H.264 High Profile Decoder

H.264 High Profile video decoder supporting 8, 10, 12 bit resolution for 4:2:0, 4:2: 2 and 4:4:4 chroma formats for video resolution from QCIF to HDTV 1920 x 1080p @ 60fps. Solution for Xilinx Virtex-5 FPGAs.

It says it has decoding support for 8, 10 and 12 bit. Oh and it can decode 1920x1080p60 too.

Also, you can't do 10-bit in MPEG-2 or VC-1. It's just not supported and never will be. Only H.264.
That's not a problem since they can use H.264.

Also, you can't do 10-bit in MPEG-2 or VC-1. It's just not supported and never will be. Only H.264.


If someone had demanded 10bit support, im sure they would have found a solution for it.


I was once in a projectgroup to purchase a "large" quantity of optical sights. One of the demands we had was the sights energy source was to last 10 years fully on. One manufacturer didnt like that because their sight was batterydriven. But nobody forced them to sell their product, if they didnt want to. But suddenly they had developed a sight with 10 years batterylife.

Never underestimate the power of money. ;)

Yes, I believe this was a big oversight. Consider that most digital movie theaters today are essentially showing HD resolution video (2K = 2048x1080) to huge auditoriums of happily paying customers. As I understand, the only real differences between HD and 2K are the lower compression level and extra color information (4:4:4?) in 2K.

If they'd just been forward thinking enough to include better color support at the start, I think Blu-ray would have been just about perfect at birth. Well, the upcoming 3D extensions may be cool too. :)

Yes, I believe this was a big oversight. Consider that most digital movie theaters today are essentially showing HD resolution video (2K = 2048x1080) to huge auditoriums of happily paying customers. As I understand, the only real differences between HD and 2K are the lower compression level and extra color information (4:4:4?) in 2K.

If they'd just been forward thinking enough to include better color support at the start, I think Blu-ray would have been just about perfect at birth. Well, the upcoming 3D extensions may be cool too. :)

Those differences are a lot greater than you make them out to be:

10 and 12 bit color depth = greater grey scale and many more colors


Motion JPEG 2000

Motion JPEG 2000 (often referenced as MJ2 or MJP2) is the leading digital cinema standard currently supported by Digital Cinema Initiatives (a consortium of most major studios and vendors) for the storage, distribution and exhibition of motion pictures. It also is under consideration as a digital archival format by the Library of Congress. It is an open ISO standard and an advanced update to MJPEG (or MJ), which was based on the legacy JPEG format. Unlike common video codecs, such as MPEG-4, WMV, and DivX, MJ2 does not employ temporal or inter-frame compression. Instead, each frame is an independent entity encoded by either a lossy or lossless variant of JPEG 2000. Its physical structure does not depend on time ordering, but it does employ a separate profile to complement the data.

http://en.wikipedia.org/wiki/JPEG_2000#Motion_JPEG_2000

Can we actually see the difference between 8 bit dithered and 10 bit? Have any studies been done?

Can we actually see the difference between 8 bit dithered and 10 bit? Have any studies been done?Did some searches and it seems its debatable. After all 8-bit color is called 'Truecolor' because it is/was perceived as being a true representation. There is I believe a demand for 10-12 bit color panels in the professional field so Im assuming there is a noticeable difference.

Supposedly the human eye can only see up to 10 million (http://www.pburch.net/dyeing/dyelog/B1063361308/C128544578/E1447734446/) colors.

Did some searches and it seems its debatable. After all 8-bit color is called 'Truecolor' because it is/was perceived as being a true representation. There is I believe a demand for 10-12 bit color panels in the professional field so Im assuming there is a noticeable difference.

Supposedly the human eye can only see up to 10 million (http://www.pburch.net/dyeing/dyelog/B1063361308/C128544578/E1447734446/) colors.

Interesting. What about 8 bit dithered? By adding a little noise can they achieve near 10 bit resolution?

I rather have full 0-256. 16-235 doesn't make sense anymore.

. As I understand, the only real differences between HD and 2K are the lower compression level and extra color information (4:4:4?) in 2K.



Different colorspaces and dynamic range. 2k DCi is not video.

Can we actually see the difference between 8 bit dithered and 10 bit? Have any studies been done?

If you are watching a digital panel most of the supposed bit depth limitations of 8bit are actually down to the display not the 8bit source. You have to pay a huge amount of wonga to get 8bit transparency on a digital display: most LCDs only manage 6bit at best. Even with a 10bit source you are unlikley to appreciate much difference.

10bit is only really useful if they use it to encode more dynamic range than nominal video currently offers (the dynamic range on display slides around a lot on video depending on picture content: this is one reason film seems far more stable in terms of rendering a scene from shot to shot) .

Moving from 4:2:0 to even 4:2:2 would probably be more beneficial in picture terms.

I've watched commercial HD releases on a Barco DP100 which is transparent way above 8bit ( not like to say exactly) and the instances of perceived limitations of 8bit were so rare as to be inconsequential.

I rather have full 0-256. 16-235 doesn't make sense anymore.

Would probably push the dynamic range unreasonably through the mach banding threshold. Video is actually higher dynamic range than PC level (with a notional 0-1 dynamic range mapped to a 0-255 encoding scheme) and is consequently "better" perceptually encoded (more of the time) to limit banding visibility.

I rather have full 0-256. 16-235 doesn't make sense anymore.It does for sampled video (studio cameras, telecines, etc.). One has to remember the front end of these devices are analog. For proper adjustments the tech must be able to see levels below the “normal” black level (16, 10h) and above the “normal” white level (235, EBh). Also overshoots and undershoots due to processing must be accounted for.

From SMPTE-274M (http://www.smpte.org/home/):
5.4 To ensure the proper interchange of picture information between analog and digital representations, signal levels shall be completely contained in the range specified between reference black and reference white specified in 7.7 and 10.5, except for overshoots and undershoots due to processing.

Greyscale sensitiveness of the human eye

If the shades of grey are presented as a continuous gradient (ie a situation where it is possible to assess relative grey values) performance improves dramatically and it is possible to differentiate over 1024 grey levels.

http://www.bio.net/bionet/mm/bioforum/1995-July/015286.html

My experience is that 8 bit/primary color (i.e. 24 total bits = 16.7million colors, not accounting for gamut colorspace limitations) is sufficient to avoid banding.

There are plenty of examples where a nice gradual gradient _IS_ preserved, so it obvioulsy is sufficient. In most cases it appears to be something else in the chain that causes the issues, either mastering (rouding error, color space conversion, bit-starved encoding, etc...) or display (player, LCD panel, etc...).

I think Mr. D's comments are right on there.

-sc

My experience is that 8 bit/primary color (i.e. 24 total bits = 16.7million colors, not accounting for gamut colorspace limitations) is sufficient to avoid banding.

There are plenty of examples where a nice gradual gradient _IS_ preserved, so it obvioulsy is sufficient. In most cases it appears to be something else in the chain that causes the issues, either mastering (rouding error, color space conversion, bit-starved encoding, etc...) or display (player, LCD panel, etc...).

I think Mr. D's comments are right on there.

-sc

So what happens when you put up the SMPTE Color Bars test pattern and look closely at the areas where one color bar touches another. ;)

My experience is that 8 bit/primary color (i.e. 24 total bits = 16.7million colors, not accounting for gamut colorspace limitations) is sufficient to avoid banding.

There are plenty of examples where a nice gradual gradient _IS_ preserved, so it obvioulsy is sufficient. In most cases it appears to be something else in the chain that causes the issues, either mastering (rouding error, color space conversion, bit-starved encoding, etc...) or display (player, LCD panel, etc...).

I think Mr. D's comments are right on there.

-scOr the camera itself. Some low light situations can also cause some bad image effects.

That depends entirely on the encoding and display chains.

An abrupt transition such as that and the resulting aliasing is completely tangental to bit depth.

-sc

10 bit cameras and tv sets have become mainstream so of course we need a source as well

10 bit cameras and tv sets have become mainstream so of course we need a source as well

No you don't. You need 10bit for a robust post production chain. You don't need it for consumer sources. Throwing more bits at it won't help especially.

Or the camera itself. Some low light situations can also cause some bad image effects.

That's a capture issue and throwing more bits at that after mastering is unlikely to help. The original footage is going to be at least 10bit anyway so if its banding its going to band regardless.

So what happens when you put up the SMPTE Color Bars test pattern and look closely at the areas where one color bar touches another. ;)

You see component subsampling artifacts...not a bitdepth issue.

I've watched commercial HD releases on a Barco DP100 which is transparent way above 8bit ( not like to say exactly) and the instances of perceived limitations of 8bit were so rare as to be inconsequential.

But you are saying limitations are there. Has anyone ever conducted any kind of blind testing experiments with HD video between say 8 bit and 10bit?

But you are saying limitations are there. Has anyone ever conducted any kind of blind testing experiments with HD video between say 8 bit and 10bit?

The compromises inherent in 8bit consumer sources are minor compared with the practical advantages of only having to move 8bit around a video pipeline.

8bit video is designed to be sufficient to represent a reasonable intensity range whilst keeping the image below the percieved mach banding threshold.I've viewed 8bit against 10bit video on a variety of displays and the percievable difference is negligible even at large screen sizes.If you AB certain imagery then you might percieve a difference but that's unlikely to be something as coarse as widespread posterising.

As I've said the coarse banding artifacts that most people see are a symptom of inadequate display precision not the source.

10bit gets you robustness and can be useful in the case of an aggressive pre-display CMS application: even then given a suitably transparent display and careful image pipeline the advantages will be minor compared with the practicalities of having to pass 10bit about.

To make 10bit worthwhile it would be better to encode a larger dynamic range to make meaningful use of the increase in precision.

I've viewed 8bit against 10bit video on a variety of displays and the percievable difference is negligible even at large screen sizes.I'm not trying to argue against your position, but I would interested to hear which displays, specifically, and which screen sizes, specifically. My personal experience, using DLP Cinema projectors on everything from 16- to 50-foot wide screens, is somewhat different.

Barco DP100 , Toshiba HDDVD player. 30ft screen (diagonal)
(zero banding except where its obviously inherent in the source material: ie Planet Earth)

HDcam 10 bit 4:2:2
10bit log film scans lutted to a relevant print model.

(AB same feature film from all three sources)

JVC DILA projectors (including the older HD10k) ( not transparent to 8bit but get quite close compared to other consumer level displays).

Plasma (not seen a plasma I could say is any more transparent than about 6bit)

Barco DP100 , Toshiba HDDVD player. 30ft screen (diagonal)
(zero banding except where its obviously inherent in the source material: ie Planet Earth)

HDcam 10 bit 4:2:2
10bit log film scans lutted to a relevant print model.

(AB same feature film from all three sources)
If I have calculated correctly the DP100 can produce at least two and perhaps three times the DCI mandated brightness on that screen. Were you viewing at such a brightness level or did you turn the lamp down to get 14 ft-L? I would expect to see a difference on the brighter screen. Regardless, brightness might be part of the problem in a home environment; LCD and plasma screens are generally much brighter than what we see in a theater, allowing source problems to be seen that would otherwise go unnoticed.

The projector is profiled and 3dluted to Kodak spec for print film and Rec.709 as required by material. Its plenty bright and in a professional viewing theater (pitch black not safe to move around in). The material included shots I created and was very familiar with.

I was also able to bang the gamma around interactively. The 8bit didn't have any banding issues. Chroma subsampling issues were apparent though.

I also watched SD from dvd on it : soft and a bit mushy for my liking but again nothing untoward from the 8bit precision.

Using HD10ks in smaller viewing theatres ( again profiled and lutted): they band slightly even with 10bit material, they don't really show any difference in regard to 8bit or 10bit source , banding is down to the end precision of the display.

I have also AB'd 10bit against 8bit material on broadcast displays (CRT and LCD) and again not observed anything that makes me think the 8bit was massively compromised in terms of visible banding.

Another issue with 8 vs 10 bit is grain/noise. This adds inherent dithering which diminishes the usefulness of extra bit depth for display. Production using higher bit depth helps to keep the grain/noise from getting worse with subsequent processes such as color correction and scaling. As mentioned displays which require exponential gamma correction, especially consumer devices, often have coaser steps in the dark areas than 8 bit and require dither noise to prevent contouring. The display's steps actually need to be finer than 8 bits because of the LUT required for gamma correction.

My answer is that he format should have supported 10 bit. The reason is simple. The source material to the encoder almost always is encoded in 10 bits. To convert that to 8 bits, one must dither. Dither is random noise and as such, reduces efficiency/increase compression artifacts. In other words, you are not really saving 2 bits worth of bandwidth. You are probably giving that much back in the form of efficiency loss.

And of course, not everyone knows how to dither properly and instead, we get banding.

As to displays not handling it, when these formats were being thought of, few if any 1080p displays existed. Yet that is the resolution was picked. So to me it is not material what the display can do today. The discs should be able to take advantage of improved technology there.

Note that there are compatible ways to add 10 bits, 4:2:2, 4:4:4 to existing specs without breaking the player. We were prototyping a solution like this with VC-1 by keeping the extension streams private to VC-1. In that manner, no spec change was required at all. Normal decoders would decode 8 bit streams. Advanced decoders would decode the secondary layer(s) and add them into the base.

To get a quick solution to market, the plan was to enhance the PC players first since VC-1 could be decoded in the processor and hence, it could be updated easily.

The project was abandoned by the blueprint above can be applied still (to all three codecs if one wanted). I wish BDA was working on this instead of 3-D....

8-bit handled properly is sufficient for low-dynamic-range systems, which is the norm, in my opinion. As display CRs continue to increase and HDR displays enter the marketplace, 8-bit will no longer remain sufficient. It certainly is visibly insufficient for HDR display.

I don't have an opinion on the move to 10-bit for current systems since I don't have a comparison that I can make in the home with 10-bit content. However, having seen some AB comparisons of 4:2:0 versus 4:2:2, I find it difficult to believe a move to 4:2:2 would be at all visibly different. I am not convinced that increasing chroma resolution would provide any visual benefits at all. But I am open to being proved wrong on this. But even comparing 4:2:0 to 4:4:4, I find it nearly impossible to see any difference with the images overlayed on each other and instantly switched. With the images side-by-side it would be totally impossible to see the difference.

Given that, and how little really has to occur for 8-bit content to become weak, I would probably have to lean towards moving to 10-bit before I would think moving beyond 4:2:0 would make any difference. I don't know that 10-bit would provide a visual improvement for proper systems, but for systems where 8-bit is being tampered with and running into banding issues, it would make the pipeline more robust anyway.

However, I would be very hesitant to advocate for either of these moves, which require more bitrate and storage space since there still are significant issues with poor quality BDs due to overcompression, so putting further strain there might do more harm than good in other ways, at least in real practice.

On the issue of 4:2:2/4:4:4, it is true that having higher chroma resolution is usually something needed in post work with chroma keying and such. However, more and more we see computer generated movies. As such, the transitions between colors start off sharp when rendered, but then get filtered away in the process of being encoded. You can see an example of this in SMPTE color bars. Look at the edges of the color blocks and you clearly see that more resolution is needed to resolve them as well as gray patches.

Yes, overcompression can be a problem. But I imagine anyone targeting these advanced features to get even better picture, would be the last person to also do a bad job in encoding it. They could be free to jettison extras, spend more time tuning the compression, etc. to get the best picture quality possible.

Just last week I exchanged email with someone who wanted to encode 10-bit 4:2:2 material and was surprised BD could not handle it.

Note that there are compatible ways to add 10 bits, 4:2:2, 4:4:4 to existing specs without breaking the player. We were prototyping a solution like this with VC-1 by keeping the extension streams private to VC-1. In that manner, no spec change was required at all. Normal decoders would decode 8 bit streams. Advanced decoders would decode the secondary layer(s) and add them into the base.

To get a quick solution to market, the plan was to enhance the PC players first since VC-1 could be decoded in the processor and hence, it could be updated easily.

The project was abandoned by the blueprint above can be applied still (to all three codecs if one wanted). I wish BDA was working on this instead of 3-D....

I didn't know this was possible. I also wish they were working on this. Do you think at some point they will?

Seeing how no one is working on it, and silicon time frames being measured in 18 months to two years, I would say we are at least 3 years away from something like that coming -- most likely longer.

Seeing how no one is working on it, and silicon time frames being measured in 18 months to two years, I would say we are at least 3 years away from something like that coming -- most likely longer.

IMO - longer than that as 3D on BD is going to take center stage next year.

Agreed. The only good news is that anyone building dual-decoders for 3-D, will also have ample computational horsepower to also handle 10 bit and 4:4:4 (in none-3-D mode).

Note that there are compatible ways to add 10 bits, 4:2:2, 4:4:4 to existing specs without breaking the player. We were prototyping a solution like this with VC-1 by keeping the extension streams private to VC-1. In that manner, no spec change was required at all. Normal decoders would decode 8 bit streams. Advanced decoders would decode the secondary layer(s) and add them into the base.
Wouldn't the problem with adding 10 bit capability as an extension be that it wouldn't be as efficient. And wouldn't the 8 bit part that both normal & advanced players now need to not be dithered? So on normal players it could mean they see banding when they didn't before for similar movies? Though it could make them want to upgrade to the 10 bit capable players.
Agreed. The only good news is that anyone building dual-decoders for 3-D, will also have ample computational horsepower to also handle 10 bit and 4:4:4 (in none-3-D mode).
And be able to do double the frame rates in non-3D mode (eg. 1080p48 - though doubling the interlaced formats might be more difficult as ideally you'd probably want the x2 to put each interlaced half of 50i/60i together (eg. of an original 1080p50/60 source) to be 50p/60p instead of doubling to be 100i/120i)

Wouldn't the problem with adding 10 bit capability as an extension be that it wouldn't be as efficient.
It would be less efficient mostly due to the problem below. But backward compatibility is super important. Otherwise, hardly anyone would release content in this new format and the chicken and egg problem would kill its prospects quickly.

And wouldn't the 8 bit part that both normal & advanced players now need to not be dithered?
You have a good point but it doesn't have to be that way. You have a choice here. To do as you state and gain efficiency for the 10-bit coding and let existing users suffer (anyone who would care would upgrade to 10-bit capable systems). Or go ahead and dither and increase the payload for the 10-bit extension. I am oversimplifying here but assuming dither messes with 1.5 bits of 8-bits, then your extension stream goes from 2 bits to 3.5 bits. If you always used the same algorithm for dither, then perhaps the compression algorithm for the extension could be optimized for it to reduce the impact some. And to the extent some pixels in the image are not changed due to dither, or changed with fewer bits (or fraction thereof), you also save that.
So on normal players it could mean they see banding when they didn't before for similar movies? Though it could make them want to upgrade to the 10 bit capable players.
Exactly. We would have a soft motivation for consumers to move up.

On the issue of 4:2:2/4:4:4, it is true that having higher chroma resolution is usually something needed in post work with chroma keying and such. However, more and more we see computer generated movies. As such, the transitions between colors start off sharp when rendered, but then get filtered away in the process of being encoded. You can see an example of this in SMPTE color bars. Look at the edges of the color blocks and you clearly see that more resolution is needed to resolve them as well as gray patches.
.

I'm not sure I agree with any of this. Professional CGI is normally handled in HDR with at least 16bit precision (32bit is the norm in most large budgetr films). This usually ends up in a 10bit log final deliverable. The CGI is usually higher precision and dynamic range than the 35mm photography to expedite the color matching.

As for 10bit video I think its a complete waste of precision for a consumer deliverable. Its a massive data cost for what is gpoing to be a negligble difference to most people. I can't tell the difference between 8 and 10bit video unless I'm very familiar with it ( ie: I made it) and that's on professional displays with transparency up to about 12bit ( that will cost you $1million by the way).

If you are going to move from 8bit to 10bit don't waste all that precision with something as limited as video use it to encode more dynamic range in the first place.

If you are going to move from 8bit to 10bit don't waste all that precision with something as limited as video use it to encode more dynamic range in the first place.

Isnt 10bit more dynamic range in the first place? since the white and black are the absolutes.

I'm not sure I agree with any of this. Professional CGI is normally handled in HDR with at least 16bit precision (32bit is the norm in most large budgetr films). This usually ends up in a 10bit log final deliverable. The CGI is usually higher precision and dynamic range than the 35mm photography to expedite the color matching.
I said nothing about bit-depth in my explanation but rather the need for higher sample rate for chroma. CGI is not rendered at 4:2:0. When converted to this for BD encode, you will lose the sharp edges.

As for 10bit video I think its a complete waste of precision for a consumer deliverable. Its a massive data cost for what is gpoing to be a negligble difference to most people.
It is not actually. If you take 10-bit data, convert it to 8-bit with dither, it will take roughly the same bandwidth than if you just encoded the original 10-bit signal. Reason is that the added dither noise is difficult to compress. So you lose efficiency with 8-bit relative to original 10-bit.

Even if the above were not the case, the difference is anything but "massive." We are talking about two extra bits relative to 8.

As for it not mattering to most people, well, why not tell me who is buried in Grant's tomb :). Of course it doesn't matter to most people. Heck, the increased resolution of BD doesn't matter to many people. But we are on AVS where people wonder about the last bit of quality and may have the equipment to see it. The example I gave about 10-bit/4:2:2 was regarding a projector manufacturer who had built in that capability and wondering how to get content for it.

If you are going to move from 8bit to 10bit don't waste all that precision with something as limited as video use it to encode more dynamic range in the first place.
99% of the system doesn't really care what it is coding. Certainly the codecs don't. It is only at the output stage where the meaning is attached to the bits. So if the system were designed to have 10-bit capability, you could accomplish what you state.

Isnt 10bit more dynamic range in the first place? since the white and black are the absolutes.

Its exactly the same dynamic range with increased precision: white and black same place same range just more discrete steps inbetween.

I said nothing about bit-depth in my explanation but rather the need for higher sample rate for chroma. CGI is not rendered at 4:2:0. When converted to this for BD encode, you will lose the sharp edges




My point is that the CGI is not limited next to photographic imagery so the same is equally true with photographic imagery.

I actually consider moving to 4:2:2 more beneficial than moving to 10bit.



It is not actually. If you take 10-bit data, convert it to 8-bit with dither, it will take roughly the same bandwidth than if you just encoded the original 10-bit signal. Reason is that the added dither noise is difficult to compress. So you lose efficiency with 8-bit relative to original 10-bit.

Even if the above were not the case, the difference is anything but "massive." We are talking about two extra bits relative to 8

Ah come on you are moving from 255 code values to 1023. Moving that amount of data whilst maintaining processing precsion in realtime for consumer markets? For an visual improvement that is at best subtle even on displays costing $1million. I doubt anyone is going to see 10bit as worthwhile until we move to higher dynamic ranges than current video offers.



As for it not mattering to most people, well, why not tell me who is buried in Grant's tomb :). Of course it doesn't matter to most people. Heck, the increased resolution of BD doesn't matter to many people. But we are on AVS where people wonder about the last bit of quality and may have the equipment to see it. The example I gave about 10-bit/4:2:2 was regarding a projector manufacturer who had built in that capability and wondering how to get content for it.


99% of the system doesn't really care what it is coding. Certainly the codecs don't. It is only at the output stage where the meaning is attached to the bits. So if the system were designed to have 10-bit capability, you could accomplish what you state.

10bit gets the consumer less posterising. If they can't see any posterising with 8bit even on displays that are fully transparent to 8bit what's the point of 10bit?

I've watched lots of 8bit 4:2:0 material in professional viewing theaters with top notch displays that are truly transparent above 8bit and I have rarely seen anything that made me think it needed 10bit to mitigate posterising and this is material that in some cases I actually created and spent months looking at. I have seen plenty of occurrences that made me wish for at least 4:2:2 color over 4:2:0.

10bit is not some worthy benefit for the afficienado and discerning videophile . The tiny benefit is vastly outweighed by the practicalities. Its certainly not "pearls before swine".

Its exactly the same dynamic range with increased precision: white and black same place same range just more discrete steps inbetween.

But I would add that higher bit-depth allows for display at higher dynamic ranges because as you increase the dynamic range at the display at a certain point the step-size becomes too large and you get banding again with 8-bit.

8-bit on an actual HDR display looks quite poor partly because of this, because the range is so much expanded. If you actually want to display on a HDR display, then IMO you need 10-bit content minimum, 8-bit doesn't cut it.

So in that sense I suppose that even though the bit-depth doesn't in any way define the DR or the contrast ratios achievable at the display, it is loosely related to just how good that content will look at various CRs.

But I would add that higher bit-depth allows for display at higher dynamic ranges because as you increase the dynamic range at the display at a certain point the step-size becomes too large and you get banding again with 8-bit.

8-bit on an actual HDR display looks quite poor partly because of this, because the range is so much expanded. If you actually want to display on a HDR display, then IMO you need 10-bit content minimum, 8-bit doesn't cut it.

So in that sense I suppose that even though the bit-depth doesn't in any way define the DR or the contrast ratios achievable at the display, it is loosely related to just how good that content will look at various CRs.

I'm not entirely sure we mean the same thing in reference to an HDR display. If you mean a video display with a large contrast range performance then I don't refer to that as HDR.
Its still a video display.


If you map the white point to a reasonable non-maximal white reference such that the peak whites run of into the bleach zone (assuming a display with crazy contrast) you are not going to run into additional bitdepth limitations. There is really no point in trying to make a video dynamic range behave as if its HDR regardless of bitdepth. You might as well worry about video not being linear: misses the point its not linear and its not HDR and its not really anything to do with precision.

If you have a display with such a massive contrast range ( like real life) that it breaks down the entire gamma/perceptual encoding of video intensity its somewhat moot to use it to display video in the first place.

You can have massive dynamic range with small precision ( newsprint) , its just not much use if you want to represent some apples with some light hitting them.

I'm not entirely sure we mean the same thing in reference to an HDR display. If you mean a video display with a large contrast range performance then I don't refer to that as HDR.
Its still a video display.

You're right I was kind of lumping things together unfairly. However, even with current low-dynamic-range displays, there is a kind of limit to the contrast ratio that is attainable that maintains the step-size in 8-bit below the JND threshold. You can obviously have a display with higher CR, but at a certain point the weaknesses of 8-bit become apparent.

I want to be perfectly clear in case someone like tbrunet seizes on this and twists it in some way I do not intent. There is obviously no correlation between the bit-depth of the content and the ultimate contrast-ratio achievable on whatever output device/material/display we're talking about. A light bulb is a 1-bit system with infinite contrast ratio, for example. But there is a relationship between the bit-depth and a display's contrast ratio in terms of how things will look.

You could have say 6-bit content or something, and if the display device is very very limited in contrast ratio, or if you want to say even lower in dynamic range than many current displays, it could look just fine in terms of not seeing discrete steps: no banding. Nothing about it being 6-bit prevents you from displaying it at much higher CR or dynamic range, a large enough range that the step-size is now not fine enough and becomes visible as bad banding.



If you map the white point to a reasonable non-maximal white reference such that the peak whites run of into the bleach zone (assuming a display with crazy contrast) you are not going to run into additional bitdepth limitations.

I'm not completely clear what you mean here.


There is really no point in trying to make a video dynamic range behave as if its HDR regardless of bitdepth. You might as well worry about video not being linear: misses the point its not linear and its not HDR and its not really anything to do with precision.

Well sure, but there is nothing that precludes you from taking a low-dynamic range image from a film source or a photograph or the like and display it on an HDR display. It's not really what is intended by the way the content was created, which is display-referenced for an LDR display that we're familiar with. But there's nothing preventing you from taking any 8-bit video or image content and looking at it on a display with vastly greater dynamic range than normal video displays. This is really all I mean. Displayed over such a vast dynamic range, the step size becomes very coarse, noise becomes exaggerated, and the image can look pretty bad and banding would be pulled out like crazy. There is nothing about 8-bit that prevent it, it's just that there is a relationship between the bit-depth and the kinds of dynamic range it can support at the display while still looking good.


If you have a display with such a massive contrast range ( like real life) that it breaks down the entire gamma/perceptual encoding of video intensity its somewhat moot to use it to display video in the first place.

Well sure, I'm not saying it's a good idea exactly, that's not what is intended by the content, but there is nothing preventing you from doing it. And if you do, you'll see that 8-bit no longer really suffices.

You can have massive dynamic range with small precision ( newsprint) , its just not much use if you want to represent some apples with some light hitting them.

Exactly. There isn't anything inherent to the bit-depth of the content that tells you anything about the dynamic range it has captured or is capable of recreating on some medium. But there is some relationship between the bit-depth and the kinds of dynamic ranges where it will look best.

There is nothing preventing anybody from creating 1 or 2-bit content and showing that on video displays. But you obviously are going to have banding issues if you're trying to create a smooth gradient with only a handful of possible values! But the film Renaissance is an example of something that, while it is 8-bit video, is effectively an extremely low-bitdepth image. Almost everything in the film is either 0% black or 100% black, with a very small amount of stuff that's at like 50%, there may be a little bit more variance than that. It's artistically interesting, but for the same reasons nothing prevents you from doing that over a fairly large contrast range, there's nothing about 8-bit that precludes you from displaying it on an HDR display with an obscene contrast range, it's just that it may not suffice in the way that 8-bit suffices on current LDR displays.

Its exactly the same dynamic range with increased precision: white and black same place same range just more discrete steps inbetween.

Ye, but no matter how much dynamic range you have, white is still white and black is still black.

The more shades you have, the more dynamic range would that give. (if the source is that good of course) Since you have more info in the highlights and shadows.

Ye, but no matter how much dynamic range you have, white is still white and black is still black.

The more shades you have, the more dynamic range would that give. (if the source is that good of course) Since you have more info in the highlights and shadows.

But that's not giving you a greater maximum range between white and black, which is what MrD is saying and he's absolutely correct about that. All greater bit-depth gives you is a finer granularity through that range. But it doesn't in itself give you greater range.

As I tried to explain above though, the finer granularity of more bits does give you the flexibility to display things (and capture things) across a greater dynamic range without running into visual limitations.

But again, there's nothing that prevents 1-bit video from being used across an enormous real-life dynamic range.

But again, there's nothing that prevents 1-bit video from being used across an enormous real-life dynamic range.

Basicly the dynamic range would be the same no matter the bits.

Since nothing can move beyond black or white. And as you point out 1bit can render the 2 absolutes (black and white). But as you increase the bits, you get more values, more values that will be used in both the shadows and the highlights.

So for a lowbit system you would get clipped highlights were a higher bit system will render the same image with values just below the highest value and in that way will render the same highlight with more shades.

So in reality you get more dynamic range without actually getting it.

Basicly the dynamic range would be the same no matter the bits.

Since nothing can move beyond black or white. And as you point out 1bit can render the 2 absolutes (black and white). But as you increase the bits, you get more values, more values that will be used in both the shadows and the highlights.

So for a lowbit system you would get clipped highlights were a higher bit system will render the same image with values just below the highest value and in that way will render the same highlight with more shades.

So in reality you get more dynamic range without actually getting it.

Right, but I think it's wrong to call that greater dynamic range. The range hasn't changed or been increased at all. It's just greater bit-depth, which is self-descriptive already.

It's just that I've wasted inordinate amounts of time arguing this with a certain forum poster who is convinced that the bit-depth determines the contrast ratios or dynamic ranges supported by video when that is not the case, except only in the way I described above which isn't a limit at all, just an intelligent self-imposed consideration.

Right, but I think it's wrong to call that greater dynamic range. The range hasn't changed or been increased at all. It's just greater bit-depth, which is self-descriptive already.



In film terms this would be tonality (shades of grey), and by the analogue nature of film is continuous within the exposure latitude of the film. This unlike the discrete steps of a digital sensor, though I believe as we approach 14 and 16 bit sensors the differences become moot.

ted

OK - based on all of the above posts . . . I will ask . . .

Is Deep Color nothing more than a "snake oil" product?

OK - based on all of the above posts . . . I will ask . . .

Is Deep Color nothing more than a "snake oil" product?

No, but it depends. I would say that often it is sold as some cool feature by people who don't know what they're talking about, TO people who know even less and for whom it will not provide one iota of benefit nor could it, and so in that case yes it's snake oil.

First, to be clear higher bit depths (10 and 12) were supported with 4:2:2 YCbCr since I think the very beginning of HDMI 1.0. Deep color in 1.3 adds higher bitdepth capabilities for 4:4:4 YCbCr and for RGB.

There is no high bitdepth consumer content right now, so the advantages of using higher bitdepth from a content perspective does not exist. However it is beneficial if you're doing any processing, and particularly any remapping of levels (say moving to graphics range, or tweaking gamma, or tweaking black and white points) in the video chain somewhere that sits behind an 8-bit output which is a serious limitation if you're manipulating the video. 8-bit is absolutely fine if you're not futzing with the content, but the moment you start shifting levels around then you end up crushing levels together or skipping treads and you end up with banding. Being able to do processing earlier on in the chain, which you want to do in 10bit or more, and maintain that precision through to the display CAN be significant IF you need to do that.

Then again the last thing is assuming all of that is going on and necessary, does the display have the bit-depth to benefit from it? Most consumer displays don't, and a lot struggle to keep up with just 8-bit, so again it may end up moot anyway.

But if you've got a high-end projector with 12-bit or more (now we're talking linear vs. nonlinear, because you need 12-bit linear practically in the display JUST to keep up with nonlinear 8-bit from the content) to handle higher-bitdepth inputs, and you've got an outboard processor like the radiance where you're maybe implementing a CMS, and tweaking gamma, and playing around with the levels or whatever the case may be, then yes it can be advantageous.

And of course that assumes that you're outputting 4:4:4 or RGB from the processor. If you're outputting 4:2:2, then you could have done that from the beginning of HDMI in 10- or 12 bit anyway so no new thing at all.

For the vast majority of consumer users who get sold on "HDMI 1.2 Deep Color: colors are deeper and more colorfulynesspretty WOW!" that's a load of horse dung, as Patton might put it.

As with anything, something that is narrowly advantageous and worthy in particular situations that can benefit can be sold far more widely than is truly necessary. It's like selling convertibles here in seattle. Not really much of a "feature" here is it... :p But it certainly could benefit the right people in the right places, so it isn't snake oil per se, it's just that it is often sold as a "feature" which makes it snake oil in that particular application, but isn't universally useless. Indeed, it is useful, but only with significant qualifiers.

In film terms this would be tonality (shades of grey), and by the analogue nature of film is continuous within the exposure latitude of the film. This unlike the discrete steps of a digital sensor, though I believe as we approach 14 and 16 bit sensors the differences become moot.

I would very highly doubt there is any visible improvement beyond 10 bits as even the perceivable difference between 8 bits and 10 bits is very small. Lets not forget also that 10 bits is 4 times the depth of 8 bits.

...
There is no high bitdepth consumer content right now, so the advantages of using higher bitdepth from a content perspective does not exist. However it is beneficial if you're doing any processing, and particularly any remapping of levels (say moving to graphics range, or tweaking gamma, or tweaking black and white points) in the video chain somewhere that sits behind an 8-bit output which is a serious limitation if you're manipulating the video. 8-bit is absolutely fine if you're not futzing with the content, but the moment you start shifting levels around then you end up crushing levels together or skipping treads and you end up with banding. Being able to do processing earlier on in the chain, which you want to do in 10bit or more, and maintain that precision through to the display CAN be significant IF you need to do that.
...

And I believe this applies to doing ANY processing in the digital domain, say even adjusting the brightness or contrast on many digital displays with a supposedly all digital path.

- Tom

I would very highly doubt there is any visible improvement beyond 10 bits as even the perceivable difference between 8 bits and 10 bits is very small. Lets not forget also that 10 bits is 4 times the depth of 8 bits.

Though I *like* the look of B&W on Video I have to wonder if this is more an issue of the limitations of the display - current displays being mostly in the 6 bit range rather than the limitations of the eye/brain.

Medical files are in the 16 bit (linear) range are they not - since this makes differences appreciable, and DCI is 12 bit I believe? Feel free to correct me.

ted

Does Deep Color make a decernable difference on a large image (30 feet H) versus a 50 " HDTV?

Medical files are in the 16 bit (linear) range are they not - since this makes differences appreciable, and DCI is 12 bit I believe? Feel free to correct me.

ted

Well DCI can be true 12 bits but is most often processed as 10bit log. Much of the DC color correctors, Lustre, Resolve, Nucoda, Baselight, are all HD video friendly as well. So they work at 10bits but are linear for HD video and log for film. Of course you could work in HD for film as well and just LUT the film record. It's done quite often on indy films.

Does Deep Color make a decernable difference on a large image (30 feet H) versus a 50 " HDTV?

Again, only if it matters based on your processing chain. IF it doesn't matter, then it doesn't matter.

If it does, as with any artifacts, it would be more pronounced and egregious when viewed at a larger viewing angle.

Well DCI can be true 12 bits but is most often processed as 10bit log. Much of the DC color correctors, Lustre, Resolve, Nucoda, Baselight, are all HD video friendly as well. So they work at 10bits but are linear for HD video and log for film. Of course you could work in HD for film as well and just LUT the film record. It's done quite often on indy films.

10bit log needs about 20bits in linear to achieve full transparency. It has to store the full "negative" density without banding : DCi is closer to print and isn't as large a dynamic range as the negative.
Don't think of 10bit log as less than 12bit DCi. Its log to exploit the latitude of film negative in conjunction with the human visual system ( and noise courtesy of the grain). If we had waited until you could get full negative density into a linear format the entire digital post production industry would be about 12 years behind where it currently is.

HD video is "video" not linear ( video isn't linear, whenever people start talking "linear video" to me I know I'm dealing with someone who is going to be a problem). In curve terms video is actually less linear than film.( not that its important)

Many image processing routines are better carried out in linear for both video and log..or anything else that isn't truly linear ( anything involving pixel filtering or interpolation).

Color correction can be done either in linear or non-linear as long as you know what you are doing (its not true at all that you shouldn't grade in log): I actually like to grade in log but I'm somewhat old skool, its easier to relate density back to code values so you can meaningfully work in old style lab incriments ( stops , light) and speak the same language as the dop: although you can relate the same incriments back into linear again if you know what you are doing.

I also don't rely on float and concatenation when I'm grading : again because I'm old skool and learnt on packages that didn't have these safety nets as such I'm always very aware of where my range is from one stage to the next and never grade anything out that I will need to bring back at a later stage.

Nowadays the grading in DI is more based around arbitrary contrast adjustment ( somewhat whacky curves) and is actually more like video grading ( the source material just really becomes an arbitrary latitude range and notionally doesn't have a look that is correct insofar as is desirable ( when it looks right its right). This really becomes apparent when you deal with Red or other digital footage and people ask you what it should look like:its correct when you are happy with the graded look: ungraded its meaningless.

Grain management I also prefer to do in log ( some tools introduce clipped grain values if you work in linear). "Optical" type processes (dissolves, fades) don't look correct if you do them in linear. People are used to seeing that logish film curve play a role in the way the detail in the image fades from old skool optical printing techniques.

I know one guy who spent two months doing all sorts of whacky things to get a bunch of optical shots in a big budget feature looking correct : he was doing them in linear when all he needed to do was stay in log.

I can tell when dissolves and fades are done in linear because of how quickly the bulk of the image detail transitions compared to the whites which seem to hang around: quite an unsettling effect.

Another side effect of this is that the offline refs ( done on video) for the dissolve timings tend to give a different visual result when translated to log/film: many a time I've had to explain this to an avid editor. Once or twice I've given up and just converted the log into video for the transition and then back to log (in float so the conversion is essentially transparent)

You can't strictly work in "HD" for film and then just lut it back for recorder as it will have been clipped. What you can do is work on a rec.709 display with suitable display LUTS for whichever mode you are working in ( so your rec.709 display is now behaving as a print film target) without clipping the film data range to video.

Then to create the video deliverables you can apply the inverse LUT and it will get your print look into rec.709 (with a bit of additional tweaking where its compromised the video too much for certain imagery) Some films are almost graded again into video though.

( I know this from having to generate video refs from film that have to closely match the end video grade: no way you'll get a match if you try and do it by the numbers : clip at 685 and gamma convert , because its essentailly an eyeballed arbitrary curve doing the work). Easier just to eyeball the film into video because that's what the grader actually did in the first place!

You comments are quite correct on all acounts. I was just speaking in very broad terms.

10bit log needs about 20bits in linear to achieve full transparency. It has to store the full "negative" density without banding
Would you have some reference for this? It means that you need 16 times better than CD audio resolution to capture the full range of the negative. That sounds implausible given the medium's dynamic range and noise floor. There are no scanners anyway that can scan (linearly) beyond 14 bit precision.

Would you have some reference for this? It means that you need 16 times better than CD audio resolution to capture the full range of the negative. That sounds implausible given the medium's dynamic range and noise floor. There are no scanners anyway that can scan (linearly) beyond 14 bit precision.

The ancient cineon white-papers quote "14bits" linear as a minimum for 10bit log.
in practice if you linearize a 10bit log image into 16bit and then back and forth a few times you'll soon see a lack of transparency going on even with 32bit float calculations.

The original log specs estimate a 10-stop density range. If you ask most people heavily involved with film scanning they'll say this is more like 11 these days ( the Dmin notion is rapidly being dropped these days as most scanners record useful data below this point inconjunction with film stock improvements).

The figure most commonly quoted to me by people heavily involved in these things is 18-20bits. In practice you will hardly ever see real world imagery that contains more than 14bits however to be truly transparent with a notional 10bit log scan you actually need a bit more than 16bit linear.

Very few people use 16bit linear file formats for film imagery these days , no-one scans 16bit linear for film ( a few do 16bit log) , everything is going to 32bit exr however 10bit log will be around for quite a while yet as its still up to the task whilst 16bit linear is just a little too close for comfort.

The ancient cineon white-papers quote "14bits" linear as a minimum for 10bit log.
in practice if you linearize a 10bit log image into 16bit and then back and forth a few times you'll soon see a lack of transparency going on even with 32bit float calculations.

Rounding errors. But basically 16 bit linear capture and delivery is enough provided all processing in between is transparent, right?

I sort of mentioned it above with my suggestion of all 16 bit but maybe I should try to explain and sell it a bit more.

The resistance to using more bits than needed is based upon the idea that more bits costs more than less bits. But this isn't really true if you look at the encoding process.

It is true that a 16 bit value takes more space (bandwidth) than an 8 bit value. But all delivered video these days uses lossy compression. Lossy compression tries to find ways to throw away information that will not be noticed. The brute force way is to start at the beginning of the chain and round, say, 16 bit video down to only 8 bits. That propagates round off errors thoughout the video processing chain.

However the recommend way to drop the precision values of each pixel or component is though the quantization, see Wikipedia (http://en.wikipedia.org/wiki/Quantization_%28image_processing%29) process that takes place during video compression. At that stage you might say you are encoding at 8 or 16 bit but the actual amount used varies dynamically based upon the desired target bit rate of the output. After encoding even BD video files actually contain much less than 8 bits per pixel. And that is not just clever encoding of all the information. It is clever choices of which info to discard.

There have been studies showing that in many cases you can encode 16 bit video at the same quality as 8 actually using fewer bits. My own guess this is because you avoid the extra artifacts caused by repeated rounding during earlier processing. But either way the final choice of how many bits (and fractional bits) to use is being made by the codec as it compresses, based upon the specified output bit rate.

This changes the economics of the whole process making it more desirable to be more lavish and feed a higher bit depth stream into the encoder.

Sadly however that requires decoders which could then decode the bit stream and most consumer equipment does not. :(

- Tom

Sadly however that requires decoders which could then decode the bit stream and most consumer equipment does not. :(

- Tom
Everything you said is true. The above is key though. If the spec is for 16 bits, then the system must, must, handle the pathological case where all bits are utilized. This means that you need 2X the memory and substantially higher processing power. In addition, the worst case power consumption will also be much higher. Since no input data should smoke the video decoder, then you have to build in additional cooling mechanisms.

In that sense, i think going to 10 bits is sufficient. The extra bits beyond can and will be used in post processing but carrying them in consumer format is hard to justify.

Amir if you were able to create a format from scratch based on your previous experiences how would its specs be?

Everything you said is true. The above is key though. If the spec is for 16 bits, then the system must, must, handle the pathological case where all bits are utilized. This means that you need 2X the memory and substantially higher processing power. In addition, the worst case power consumption will also be much higher. Since no input data should smoke the video decoder, then you have to build in additional cooling mechanisms.

In that sense, i think going to 10 bits is sufficient. The extra bits beyond can and will be used in post processing but carrying them in consumer format is hard to justify.

I'd guess that byte/word oriented computers and equipment (most everything these days) would handle 16 bit more efficiently than 10 anyway. But if we were really worried about red-lining the output values I think AVC already allows you to control min and max quant values and thus limit the output to specified precisions. They are finally encoded as variable length bit strings anyway, even in MPEG-2.

And of course I'm not really suggesting sending 16 bits per value. I just think it should be the job of the encoded to do the needed quantization and we should have a chain that keeps precision as large as possible as long as possible.

Eight bit decoders cannot usually decode 16 bit values, even though I think the only 8 bit MPEG-2 decoder code I ever worked on at did output a 16 bit intermediate value from the dequant step before then rounding it. Seemed a waste.

Heck, I'd even wager we could write 16 bit decoders that gave less posterization when decoding current 8 bit video, say DVD's and BD's.

But I would like to avoid having this conversation again in a few years as we explain why 10 bit decoders can't handle the 16 bit processing we would like to use. ;)

- Tom

I have some questions. Would 10 bit completely eliminate any trace of banding, assuming the original source was at least 10 bit? Is banding primarily the result of the limit of 8 bit or other factors? With 10 bit I'm assuming there would not be a need to dither at all???

Amir if you were able to create a format from scratch based on your previous experiences how would its specs be?
That is a tall order :). Here are some quick thoughts:

1. Resolution independence. There is really no reason to stick to ATSC scan rates. Computer players don't care at all what you encode. In Windows version of VC-1, the max resolution limit is 10,000x10,000 pixels for example (yes, can actually encode at that resolution!). Of course, playback may not maintain the encoded frame rate but maybe it is OK to have a slide show at 5 fps instead of forced 24fps and lower resolution. And then there would be a market and motivation for making faster and better players.

Of course, this would require a scalar to target output device much as we have with GPUs in PCs.

2. Color space independence. Again, the codecs don't really care what color each pixel represents. To that end, I would like to see RGB supported so for computer based animation, we could go from creation to distribution without translation into and out of YUV a hundred times :).

3. Frame rate independence. OK, you get the picture. This is another thing we have in computers which doesn't exist in CE world. I should be able to make a movie like Baraka and have it run at whatever rate I like.

With digital displays, the old notion of frame rates is stale anyway. Computer displays are able to sync to many rates above and beyond ATSC.

To the extent one wants to maintain compatibility, then the player could be free to decimate or interpolate to target rate.

4. 10-bit, 4:4:4 support. We have talked about these before but the latter is needed for #2 to mimic what we have in computers (i.e. 4:4:4 RGB).

5. Player-based adaptive filtering and grain injection. The pressure to please the average Joe forces studios to use dynamic noise reduction. Why not have this be a set of parameters passed on to the player and have it perform the noise reduction appropriately? And if grain is needed, let's inject (pre-programmed) ones in the player, rather than making the encode hard by putting it in upstream.

6. Auto-muting/auto-picture rating. There should be metadata to adapt the picture to a different audience, created by the creating people as they do today for TV and airplane viewing. I used to get tired of telling my kids to "look the other way" for the one or two shots in a movie that was suitable for them otherwise.

7. Simpler interactivity that can actually be reliably tested and deployed.

8. If we have any interactivity, then a way to "just watch the movie" set of metadata that would tell me how to find the entire movie and play it. Cell phones and portable devices are getting HD playback capability and we want them to be able to play the content without the burden of full interactivity.

9. One patent pool for all the technology in there. No paying three times for the same patent used in two parts of the format.

I better stop here before I get myself into more trouble than I already have with this list :).

I have some questions. Would 10 bit completely eliminate any trace of banding, assuming the original source was at least 10 bit? Is banding primarily the result of the limit of 8 bit or other factors?
There is one thing that no one has mentioned yet.
The sources are encoded into 8bit YCbCr, which cannot contain more than 25% of the colors contained in 8bit RGB.
When the image is decoded from 8bit YCbCr and converted to 8bit RGB to feed our displays, only 25% (at best) of the colours available in our displays are used (if they are full 8bit displays, of course). It's like if we consider that our displays are like a swiss cheese, with lots of holes that correspond to the colors that are not contained in the source.
So, with 8bit YCbCr, we can achieve the same dynamic range of 8bit RGB, but cannot achieve its color smoothness. Some of the banding could come from this loss when converting from the RGB masters into 8bit YCbCr...
Only 10bit YCbCr can contain all colors contained in 8bit RGB, although 9bit YCbCr would be pretty close at 99.6%.

Mr.D, in practice, is this really noticeable? Have you compared full 8bit RGB material, vs 8bit RGB after conversion from 8bit YCbCr?

That is a tall order :). Here are some quick thoughts:


I dont hope you charge me for this order. ;)



1. Resolution independence. There is really no reason to stick to ATSC scan rates. Computer players don't care at all what you encode. In Windows version of VC-1, the max resolution limit is 10,000x10,000 pixels for example (yes, can actually encode at that resolution!). Of course, playback may not maintain the encoded frame rate but maybe it is OK to have a slide show at 5 fps instead of forced 24fps and lower resolution. And then there would be a market and motivation for making faster and better players.


I hope "they" make a standard for resolution to a certain framerate. Or else we gonna end with many discussions why movie A got 2K encode were movie B got a 4K encode.

6. Auto-muting/auto-picture rating. There should be metadata to adapt the picture to a different audience, created by the creating people as they do today for TV and airplane viewing. I used to get tired of telling my kids to "look the other way" for the one or two shots in a movie that was suitable for them otherwise.


Didnt they have that on DVD?


7. Simpler interactivity that can actually be reliably tested and deployed.


I would like to add that it shouldnt take away the resume function.


8. If we have any interactivity, then a way to "just watch the movie" set of metadata that would tell me how to find the entire movie and play it. Cell phones and portable devices are getting HD playback capability and we want them to be able to play the content without the burden of full interactivity.


I think some high end players would sell well with this function ;)


9. One patent pool for all the technology in there. No paying three times for the same patent used in two parts of the format.


Sound like world peace would be an easier goal.


I better stop here before I get myself into more trouble than I already have with this list :).

That was fast trouble. ;)

Mr.D, in practice, is this really noticeable? Have you compared full 8bit RGB material, vs 8bit RGB after conversion from 8bit YCbCr?

Not sure what you are asking me.
I've compared RGB to 4:2:0 YCbCr but I was comparing it more from the perspective of component downsampling.

I don't see any difference between 8bit RGB and 8bit 4:4:4 yuv on the various kit I bang about on.

Not sure what you are asking me.
Imagine you have an image in 8bit RGB 4:4:4 that uses all colors available. This would be a 16777216 pixels image, each pixel with a different color.
If we convert this image to 8bit YCbCr 4:4:4, and then back to an 8bit RGB 4:4:4 image, this final image will have less than 25% of the colors of the original image, so some pixels will have the same color. This could result in banding.
I know that it would not be easy to watch an image like this due to its size, but if we cut a 1920x1080 part of it, and then process it like I said, the result should be very similar, the only difference is that it will not contain all the color spectrum available, but only a part of it.

Have you ever tested something like that? If not, is it testable? I would like to know if the resulting banding is noticeable...

Imagine you have an image in 8bit RGB 4:4:4 that uses all colors available. This would be a 16777216 pixels image, each pixel with a different color.
If we convert this image to 8bit YCbCr 4:4:4, and then back to an 8bit RGB 4:4:4 image, this final image will have less than 25% of the colors of the original image, so some pixels will have the same color. This could result in banding.
I know that it would not be easy to watch an image like this due to its size, but if we cut a 1920x1080 part of it, and then process it like I said, the result should be very similar, the only difference is that it will not contain all the color spectrum available, but only a part of it.

Have you ever tested something like that? If not, is it testable? I would like to know if the resulting banding is noticeable...

An interesting question. I don't think I've ever seen any test images of this myself, but in all the literature I've read, this loss is pretty much ignored/tossed aside as not perceptually relevant. Most of the tests are about chroma subsampling, since obviously moving to YCbCr and leaving it 4:4:4 is pointless and theoretically detrimental as you point out.

Have you ever tested something like that? If not, is it testable? I would like to know if the resulting banding is noticeable...

Nope in fact I'm a little confused.

I was always under the impression that mapping back and forth from YCbCr to RGB was essentially lossless. And I'm including working with 10bit log. I've often mapped RGB to YCrCb and back and see zero difference both visually and technically ( this is even with 16bit integer workflow).

In fact I had a big discussion with a color wizard about the first DCi specs that encoded as YCbCr as being compromised as a result and the guy took an opposing stance saying it was perfectly lossless in terms of encoding the RGB.

I can probably do some tests today. I'll dig out "marcie".

I don't think I've ever seen any test images of this myself
I could easily create some test images for this, but I would prefer to perform a comparison with real images, that were never converted to 8bit YCbCr, and, if possible, also with full chroma resolution (4:4:4).
Anybody knows where I can find some images like these?

...in all the literature I've read, this loss is pretty much ignored/tossed aside as not perceptually relevant. Most of the tests are about chroma subsampling, since obviously moving to YCbCr and leaving it 4:4:4 is pointless and theoretically detrimental as you point out.
Some people also feel that the loss is not relevant because the chroma will be subsampled, but that's not correct. In fact, the chroma subsampling could make it worse, because it increases the areas with the same color value, hence the possibility of banding.
Our eyes have less color receptors than luminance receptors, but they are very sensitive to different color tones. Only at low luminance levels the sensitivity for colors diminishes.

I could easily create some test images for this, but I would prefer to perform a comparison with real images, that were never converted to 8bit YCbCr, and, if possible, also with full chroma resolution (4:4:4).
Anybody knows where I can find some images like these?

.

The Kodak LAD chart is useful (10bit log 2k and 4k film scan).

I can do a test with this : map to yuv break concatenation map back to RGB and pull a difference key with the original.

I was always under the impression that mapping back and forth from YCbCr to RGB was essentially lossless.
In theory is lossless, but due to the fact that YCbCr is a much wider space than RGB, when you discretize both with the same number of steps, some of the RGB steps will correspond to the same step in YCbCr. So, when you revert back to RGB, those original different RGB values will be represented by the same RGB value.
I've made some posts a time ago in doom9's forum about this subject, with some numbers. You can take a look here (http://forum.doom9.org/showthread.php?p=1266993#post1266993).

I can probably do some tests today. I'll dig out "marcie".
Dig it.;)
I will also try to create some test images, but it would be preferable to use real world images.

The Kodak LAD chart is useful (10bit log 2k and 4k film scan).
Thanks. Do you have any link from where I could download it?

I also found this (http://www.dancad3d.com/S0410300.HTM) site which have a scanned image converted to 8bit RGB here (http://www.dancad3d.com/LAD2048P.ZIP) and here (http://www.dancad3d.com/LAD1600P.ZIP), and a 16bit RGB here (http://www.dancad3d.com/LAD3906N.ZIP). Unfortunatelly the last is in a proprietary format.

I can do a test with this : map to yuv break concatenation map back to RGB and pull a difference key with the original.
Yes, that will show that the process is not lossless, but will you be able to also view both RGB images and try to see if the difference is noticeable to your eyes?

Thanks. Do you have any link from where I could download it??

Kodak seem to have hidden it somewhere. I have it as a 2k cineon file which I can mail to you if you PM me a suitable address (its 12.2MB).



I also found this (http://www.dancad3d.com/S0410300.HTM) site which have a scanned image converted to 8bit RGB here (http://www.dancad3d.com/LAD2048P.ZIP) and here (http://www.dancad3d.com/LAD1600P.ZIP), and a 16bit RGB here (http://www.dancad3d.com/LAD3906N.ZIP). Unfortunatelly the last is in a proprietary format.

Best get it from the horses mouth mine is from Kodak. I used to have it as 4k and 6k as well not sure where those are though.


Yes, that will show that the process is not lossless, but will you be able to also view both RGB images and try to see if the difference is noticeable to your eyes?

Actually I've just done this and it shows it as lossless.

10bitlog RGB graded into video (my own curve but I alos have it by the numbers according to the ancient cineon log to video conversion which will clip the highlights to a very ugly extent and isn't representative of a modern telecine type process)) , mapped to yuv (I'm using shake which uses its own coeffficients for yuv mapping , not sure what they are exactly ...shouldn't matter for the test).

8bit maths I get a sporadic rounding error of 0.004 code values (normalized 0-1 range) although this may be down to the 0.001 pixel blur I'm doing to break concatenation , I still get the error if I drop out the blur which makes me think its a processing rounding error rather than a symptom of lossiness.

Visual result...no detectable difference.

16bit maths , no error completely lossless even with the blur to break concatenation 0 error across the deck.

Visual result no difference.

I'm looking for a format to post on here that doesn't involve its own rgb to YCbCr type colorspace encoding. I think jpeg does one what about gif?

Ah okay if I do a massive expansion after subtracting the rgb/yuv/rgb conversion from the original rgb I can see rounding errors that get progressively better until they are non-existent at 32bit.

I can also post these but again its only showing rounding errors not rgb/yuv transparency.

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156770&stc=1&d=1257083881

10bitlog rgb to 8bit video rgb (2048x1556 fitted into 768x576)
. I just graded it into video rather than some primitive gamma tweak.

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156112&stc=1&d=1256478198

8bit math rgb to yuv to rgb conversion; no concatenation

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156113&stc=1&d=1256478286

16bit math rgb to yuv to rgb conversion: no concatenation

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156114&stc=1&d=1256478364

32bit math rgb to yuv to rgb conversion; no concatenation

Do bear in mind the difference maps are massively expanded to aid visibility (0.004 is mapping to 1!).
In practice they all look perfectly black prior to expansion.

8bit maths I get a sporadic rounding error of 0.004 code values (normalized 0-1 range) although this may be down to the 0.001 pixel blur I'm doing to break concatenation , I still get the error if I drop out the blur which makes me think its a processing rounding error rather than a symptom of lossiness.
Remember that what is not lossless is RGB->YCbCr->RGB when both RGB and YCbCr have the same bit depth, independently of the precision you use during the conversion.
What you are getting, it's the rounding error that results when storing YCbCr in 8bit (0.004 is ~1/256). After that, when you convert back to RGB, you only get 25% of the original RGB possible values, the other 75% are lost during the rounding errors. This is not clearly visible, because the difference is very small, and generally, in real world images, we don't have large portions of the same exact colors side by side.
I will try to create a test image to let us see this.
Visual result...no detectable difference.
That's what's really important. It's funny that 25% of True Color still is True Color...;)

Do bear in mind the difference maps are massively expanded to aid visibility (0.004 is mapping to 1!).
In practice they all look perfectly black prior to expansion.
I would not expect any different. The differences are always +/- 0.004 in one of the color channels, so, if you output an image of the differences, it would be very hard to notice the +/- 0.004 differences. The expanded image showed that the errors are there.;)

Remember that what is not lossless is RGB->YCbCr->RGB when both RGB and YCbCr have the same bit depth, independently of the precision you use during the conversion.
What you are getting, it's the rounding error that results when storing YCbCr in 8bit (0.004 is ~1/256).


Still not sure I follow you. I'd expect that rounding error regardless with any sort of processing in 8bit precision.

However what I'm doing is converting the 10bit log to 8bit video . Then I'm using inflating precision to do the yuv conversion then I'm deflating back out to 8bit. So I am starting with 8bit and ending with 8bit all I'm doing is upping the precision of the math. Most consumer pipelines will be at least 10bit , notice 16bit isn't enough to be fully transparent anyway.

I'm doing this to show that the yuv conversion itself is lossless, the only loss I'm getting is rounding errors until I reach suitable transparency at 32bit. The yuv conversion itself is lossless. I'm not working in float either as I'm clamping the values to integer after every stage.

The practical visual differences in all cases are as you rightly say imperceptable. However I'm pretty sure the 32bit pipeline shows that the yuv conversion itself is lossless.

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156766&stc=1&d=1257083360
8bit rgb video generated direct from 10bitlog

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156767&stc=1&d=1257083438

same image after an rgb to yuv to rgb conversion: no concatenation: 8bit Math

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156768&stc=1&d=1257083610

same as previous image but 16bit math

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156769&stc=1&d=1257083660

same as previous image but 32bit math.

probably not a visually detectable difference in each case, the difference maps on the previous post are probably more meaningful. However in the interests of completeness I thought I'd provide the end results of each conversion scenario

ah just realised the images are all missing will fix asap.

In converting YCbCr to RGB, you do indeed lose a lot of colors due to the need for clamping. Here is a quick visualization:

http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/Images/ch6_color_models_4.jpg

Of course, you can choose to not clamp the RGB values to normalized 1.0 values in which case, the above restriction would not be there. But this would only be useful for intermediate conversions.

In converting YCbCr to RGB, you do indeed lose a lot of colors due to the need for clamping. Here is a quick visualization:

http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/Images/ch6_color_models_4.jpg

Of course, you can choose to not clamp the RGB values to normalized 1.0 values in which case, the above restriction would not be there. But this would only be useful for intermediate conversions.


All the suff I've done was clamped at every processing stage (10bit log to video in 16bit processing , resize to 768x576 in 16bit linear, deflate to 8bit/16/32 and clamp, conversion to yuv , clamp , 0.001 pixel blur to break concatenation , clamp, convert to rgb , clamp , deflate to 8bit if necessary and then output.

The 32bit precise one is transparent and the others show rounding errors not loss because of the yuv/rgb conversions. Any ideas?

Still not sure I follow you.
Probably I'm not explaining myself correctly (sorry, english is not my native language).
What I am trying to say is this:
(1)start with an 8bit RGB image, stored in file A using 8bit RGB.
(2)read image from file A.
(3)convert the image from RGB to YCbCr
(4)store the YCbCr converted image to file B using 8bit YCbCr
(5)read image from file B
(6)convert the image from YCbCr to RGB
(7)store the RGB converted image to file C using 8bit RGB

No matter what precision you use to perform the conversions in steps (3) and (6), file C will always be different from file A, because of the rounding to 8bit in step (4).
Now, if you pick the file C and perform all steps, from (1) to (7) on it, if you use enough precision during the conversions, you will get the same file at the end, but that's an already flawed file to start with.;)
The rounding that happens in step (4) can reduce the number of different colors, compared with the original image, up to 75%.

Chroma subsampling aside, step (4) are what we get in our DVDs and Blu-rays.

Probably I'm not explaining myself correctly (sorry, english is not my native language).

The rounding that happens in step (4) can reduce the number of different colors, compared with the original image, up to 75%.

.


I get that I fully accept that you will get rounding errors with 8bit material processed with 8bit precision , however my point was that the conversion between rgb to YCbCr is in itself lossless and as I've illustrated given enough precision in the processing in my case 32 bit, you get transparency.

What I'm saying is that the RGB to YCbCr conversion itself is lossless (assuming no subsampling in the chain) and that even with 8bit native you can do it transparently with a precise enough pipeline and even with 8bit the visual impact is imperceptable.

I think Amir is saying that the YCbCr conversion itself is not lossless , maybe the clamp (to 8bit precision?) means he is saying the same thing as yesgrey.

I'm saying the YCbCr conversion is lossless and I'm also saying that 8bit can be processed transparently given enough precision and I'm saying that even when it isn't fully transparent it makes little percievable visual difference ( given that most pipelines in consumer land are at least 10bit).

Discuss?:)

In converting YCbCr to RGB, you do indeed lose a lot of colors due to the need for clamping.
That's true, but you are looking at it from the wrong side...
In the image you have post we can see that the RGB space is fully contained inside the YCbCr space. If you divide both spaces in the same number of blocks, a YCbCr block will be bigger than a RGB block.
If you try to put the RGB blocks inside the YCbCr blocks, some of the YCbCr blocks will contain more than one RGB block, because they are bigger.
Now, imagine that you want to revert the process, but you only can look at the YCbCr blocks... You can't. Some of the YCbCr blocks will correspond to more than one RGB block, you cannot select more than one RGB block, and there is no way for you to know which is the correct RGB block.

In theory is lossless
however my point was that the conversion between rgb to YCbCr is in itself lossless and as I've illustrated given enough precision in the processing in my case 32 bit, you get transparency.
Yes. I have said that from the start (see my quote above).
What you are still missing is that native 8bit material in RGB, when converted to native 8bit material in YCbCr, will not be lossless, no matter what precision you use during the conversion. If, at a later stage, you want to convert that native 8bit material in YCbCr back to 8bit RGB, you will not get the original 8bit RGB material.

Yes. I have said that from the start (see my quote above).
What you are still missing is that native 8bit material in RGB, when converted to native 8bit material in YCbCr, will not be lossless, no matter what precision you use during the conversion. If, at a later stage, you want to convert that native 8bit material in YCbCr back to 8bit RGB, you will not get the original 8bit RGB material.

That's what I'm getting with 32bit precision though. Hence the examples and I'm not using float or concatenating color.

I totally accept that 8bit input processing and output is never transparent. (I've even said 16bit isn't totally transparent)
Even with that though the visual differences can we say are tiny if not entirely theoretically imperceptable?

Where does that leave us in terms of moving consumer video to 10bit??

That's true, but you are looking at it from the wrong side...
In the image you have post we can see that the RGB space is fully contained inside the YCbCr space.
That is not what the picture says. The picture says if you convert YCbCr to RGB, that conversion locks you onto a smaller RGB color space. That is the case due to the way the matrix conversion/clamping is defined by video standards. Not because RGB always has smaller color space.

An RGB sourced image for example, can contain a larger color space than one converted from YCbCr. Indeed, there are values in RGB that would be illegal in YCbCr and would poke out of its cube. This it the reason our photos generated in RGB look as good as they do, unlike what the picture that I post would (incorrectly) imply.

If you divide both spaces in the same number of blocks, a YCbCr block will be bigger than a RGB block.
OK.

If you try to put the RGB blocks inside the YCbCr blocks, some of the YCbCr blocks will contain more than one RGB block, because they are bigger.
Sorry, I can't visualize what you are trying to say. The reverse is of course true in that we do map multiple YCbCr values into one RGB value. So there is a many-to-one relationships.

Now, imagine that you want to revert the process, but you only can look at the YCbCr blocks... You can't. Some of the YCbCr blocks will correspond to more than one RGB block, you cannot select more than one RGB block, and there is no way for you to know which is the correct RGB block.
Anytime you map from one color space to another of different size and shape, you have to figure out what to do with illegal values. In case of video, have two choices:

1. Do the easy thing using clamping. This as I mentioned, will map multiple video values into the same (clamped) RGB value. And as with your audio amplifier reaching clipping, you get distortion at that point.

2. Perform perceptual mapping. Here, instead of mapping 1:1 and then all of a sudden clamping, we can use a visual model and attempt not make this an all or nothing proposition. Think of soft clipping in your amp.

Perceptual mapping is used routinely when we print photos as the RGB space does not map 1:1 (in either direction usually) with what your printer can handle. Of course, there we are in offline mode so we can use more complex algorithms like this. Approximations can be made though, using tables.

That is not what the picture says. The picture says if you convert YCbCr to RGB, that conversion locks you onto a smaller RGB color space. That is the case due to the way the matrix conversion/clamping is defined by video standards. Not because RGB always has smaller color space.

Guys, you're missing what he's saying.

The R'G'B' cube defines real colors that are all addressable. Every R'G'B' triplet is a legitimate color. Y'CbCr is a much larger space in order to contain the full range of possible R'G'B' values. However we have the same number of Y'CbCr triplets as R'G'B' triplets, but the vast majority of legal Y'CbCr triplets are totally outside the R'G'B' cube and are not valid signals. They don't correspond to anything. You could artificially encode them directly as Y'CbCr values for signal testing purposes, but if you begin with an R'G'B' image they will never arise. What this means is that the number of uniquely addressable valid colors (colors inside the R'G'B' cube) that YCbCr can address is far smaller than can be uniquely expressed by R'G'B'. So, for the video range, R'G'B' can address ~10.6 million colors. Video range Y'CbCr defines the same number (technically slightly more because chroma is 16-240, but lets ignore that for simplicity) of legal values, but the vast majority of those Y'CbCr values are totally outside the R'G'B' cube and are not useful for anything. We are left with about 2.75 million Y'CbCr triplets that are valid, that map to legal R'G'B' values.

Think of it this way: the number of legal triplets in each space is the same, but their volume is totally different with YCbCr being volumetrically much much larger. This would be like having the same number of hash marks on two different rulers, but one ruler is 4 times the length. If all we are interested in is the values defined by the range of the shorter ruler, the longer ruler is far inferior in its precision within that shorter range because the marks will be much farther apart and hence coarser. You could measure with much greater precision smaller differences with the smaller ruler (RGB) within the smaller (RGB) range than you could with the longer (YCbCr) ruler. The fact that the longer ruler (YCbCr) can measure things outside the range possible with the shorter ruler (RGB) is irrelevant because we will never have anything longer than the range of the shorter ruler (RGB).


An RGB sourced image for example, can contain a larger color space than one converted from YCbCr. Indeed, there are values in RGB that would be illegal in YCbCr and would poke out of its cube. This it the reason our photos generated in RGB look as good as they do, unlike what the picture that I post would (incorrectly) imply.


(everything past this point assumes nonlinear RGB/YCbCr, so many apostrophes are getting annoying...)

No you have this backwards. YCbCr is much larger than RGB as your illustration shows. But you lose unique colors that you can address in RGB that you cannot in YCbCr because only about 1/4 of the YCbCr range is encompassed by RGB.


OK.

Sorry, I can't visualize what you are trying to say. The reverse is of course true in that we do map multiple YCbCr values into one RGB value. So there is a many-to-one relationships.

No no, it's exactly opposite. There are unique RGB combinations that all get mapped to a single YCbCr value. You can think of it as a finer granularity in RGB that cannot be uniquely addressed by YCbCr. The moment you move to YCbCr you lose 3/4 of your colors that could be uniquely addressed in RGB which cannot be uniquely addressed in YCbCr.


Anytime you map from one color space to another of different size and shape, you have to figure out what to do with illegal values. In case of video, have two choices:

1. Do the easy thing using clamping. This as I mentioned, will map multiple video values into the same (clamped) RGB value. And as with your audio amplifier reaching clipping, you get distortion at that point.

2. Perform perceptual mapping. Here, instead of mapping 1:1 and then all of a sudden clamping, we can use a visual model and attempt not make this an all or nothing proposition. Think of soft clipping in your amp.

Perceptual mapping is used routinely when we print photos as the RGB space does not map 1:1 (in either direction usually) with what your printer can handle. Of course, there we are in offline mode so we can use more complex algorithms like this. Approximations can be made though, using tables.

I'm not sure what you're getting at here. There won't be any clamping/clipping happening here. If you start in RGB, then the full range can be addressed without difficulty, it is only specific colors within that range which can no longer be uniquely addressed. As long as you start in RGB, then you won't get any YCbCr values that would map to illegal RGB triplets so nothing will be clipped. However as I said above, you do lose the fine granuality of RGB because you're losing 3/4 of colors that could be uniquely addressed in RGB that cannot be uniquely addressed anymore with YCbCr. This is why 4:4:4 YCbCr is an inherently inferior colorspace to RGB. The only reason it exists is to be able to chroma subsample to save space.

10bit log RGB starting point.
Down to 8bit video and clamped
inflated to 32bit
into yuv clamped
back out to rgb clamped
deflated to 8bit

no float or concatenation

pixel for pixel same as the input as evidence by difference map.

transparent guys?

That is the case due to the way the matrix conversion/clamping is defined by video standards. Not because RGB always has smaller color space.
Yes, I agree with this. We could choose some matrix coefficients that give RGB color space bigger than YCbCr color space, but with BT.709 and BT.601 coefficients YCbCr is bigger than RGB.

That is not what the picture says. The picture says if you convert YCbCr to RGB, that conversion locks you onto a smaller RGB color space.
I disagree.

An RGB sourced image for example, can contain a larger color space than one converted from YCbCr. Indeed, there are values in RGB that would be illegal in YCbCr and would poke out of its cube.
I disagree. For the standards above all RGB values have a valid YCbCr representation. It's exactly the opposite of what you are saying.

This it the reason our photos generated in RGB look as good as they do, unlike what the picture that I post would (incorrectly) imply.
So, when you look at the picture you expect the opposite of what you think, then you conclude that the picture just gives you a wrong idea...;)

Sorry, I can't visualize what you are trying to say. The reverse is of course true in that we do map multiple YCbCr values into one RGB value. So there is a many-to-one relationships.
Once again, it's the opposite. We do map multiple RGB values into one YCbCr value.;)

Look amirm, I understand you completelly, because in the beggining, when I started reading about this, I also thought about it the way you are thinking. The literature is a bit misleading.
Only when I started performing the math, I realized that it was the opposite, and then when I looked to the pictures, they started to make sense...

Here are some real numbers instead of words, maybe this would help...:)

I will use the BT.709 coefficients for the RGB<->YCbCr conversions, and will use numbers between 0 and 255.
Let's consider the following RGB values:
A [102, 205, 85]
B [102, 204, 85]
C [101, 204, 85]
D [101, 205, 85]

Converted to YCbCr the result would be:
A [174.4382, 79.800926923906, 82.001651003302]
B [173.723, 80.1863548178487, 82.4558039116078]
C [173.5104, 80.300926923906, 81.9558039116078]
D [174.2256, 79.9154990299634, 81.501651003302]

If we store A, B, C and D in 8bit YCbCr, they become:
A [174, 80, 82]
B [174, 80, 82]
C [174, 80, 82]
D [174, 80, 82]

Now, if we convert A,B,C,D back to RGB before we store them in 8bit YCbCr,
we will get exactly the original RGB values.
If we convert A,B,C,D back to RGB after we store them in 8bit YCbCr,
we will get the same RGB value for all of them:
A = B = C = D = [102, 205, 85]

Like it was shown above, 4 different 8bit RGB values ended in a single 8bit RGB value due to the usage of 8bit YCbCr as the storage format.

Now, just to confirm that some valid YCbCr values have no valid representation in RGB, let's consider the YCbCr value [200, 200, 200].
When converted to RGB gives [313, 153, 334], which is completelly outside of the valid range.

This is why 4:4:4 YCbCr is an inherently inferior colorspace to RGB. The only reason it exists is to be able to chroma subsample to save space.
Just a small addition... The above is true if YCbCr and RGB are represented with the same bit depth. I know that you know that, and that you were implying that, but we should always say it.

You also anticipated my (long) reply.;)

10bit log RGB starting point.
Down to 8bit video and clamped
inflated to 32bit
into yuv clamped
back out to rgb clamped
deflated to 8bit

no float or concatenation

pixel for pixel same as the input as evidence by difference map.

transparent guys?

Can you try this?
-10bit log RGB starting point.
-Down to 8bit video and clamped
-into yuv clamped
-store the image into a file at 8bit yuv
-now load the stored image
-back out to rgb clamped
-deflated to 8bit

Let me know the result.;)

Ye, but no matter how much dynamic range you have, white is still white and black is still black.

The more shades you have, the more dynamic range would that give. (if the source is that good of course) Since you have more info in the highlights and shadows.

Now's a time for a good illustration of this. Same precision , higher dynamic range.They are all the same precision but in order of increasing dynamic range.

This is what you get if you punch in the standard numbers for linearising a 10bit log full negative density image and mapping it into 8 bit video.

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156177&stc=1&d=1256501924


This is my pretty much eyeballed grade (essentially a 1dlut).This is more like what happens at a real video mastering.

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156178&stc=1&d=1256501948

This is the original log full negative density ( converted to 8bit jpeg so you can view it , this was 10bit originally)

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156179&stc=1&d=1256502232

Can you try this?
-10bit log RGB starting point.
-Down to 8bit video and clamped
-into yuv clamped
-store the image into a file at 8bit yuv
-now load the stored image
-back out to rgb clamped
-deflated to 8bit

Let me know the result.;)

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156180&stc=1&d=1256503311

http://www.avsforum.com/avs-vb/attachment.php?attachmentid=156181&stc=1&d=1256503370

seems the same as the 8bit precision workflow.
I get improved results if I move to 32bit error is down to 0.002 on average but its not fully transparent.

Just a small addition... The above is true if YCbCr and RGB are represented with the same bit depth. I know that you know that, and that you were implying that, but we should always say it.

You also anticipated my (long) reply.;)

Yes I was making that assumption, and you're right I should have been explicitly clear there.

I disagree. For the standards above all RGB values have a valid YCbCr representation. It's exactly the opposite of what you are saying....Once again, it's the opposite. We do map multiple RGB values into one YCbCr value.;)
With your example, I see what you are saying now. But the way you explained it, really confused the issue. I thought your theses was around the missing color samples in RGB. Not the fact that you have math that results in intermediate values which must be dealt with.

To expand, we would have the same problem even if the RGB cube was the same size as YCbCr but different shape. Why? Because if you have to use fractional math to make the transformation, you are going to create values that cannot be represented in integer RGB values. This is why you must dither the output. If you did not, then yes, you get banding.
The literature is a bit misleading. Only when I started performing the math, I realized that it was the opposite, and then when I looked to the pictures, they started to make sense...
The literature is fine actually. It is understood that an actual implementation would not be decimating sample values (as you showed) but use dither. It is the difference between textbook DSP and real life implementation :).

Noise floor is increased to be sure as a result of dither, but not banding.

seems the same as the 8bit precision workflow.
I get improved results if I move to 32bit error is down to 0.002 on average but its not fully transparent.
With your example, I see what you are saying now. But the way you explained it, really confused the issue.
An image worths more than 1000 words, especially when they come from a non-native.:D

...This is why you must dither the output. If you did not, then yes, you get banding.
The literature is fine actually. It is understood that an actual implementation would not be decimating sample values (as you showed) but use dither. It is the difference between textbook DSP and real life implementation :).
Noise floor is increased to be sure as a result of dither, but not banding.
Yes, dithering of the source would be needed to avoid banding.

Where does that leave us in terms of moving consumer video to 10bit??
With 10bit consumer video, the noise floor due to the dither would be decreased, or even avoided, because at 10bit probably we could not be able to notice the banding... especially if the current displays, like Mr.D already said, are only capable of resolving 8bit.

It is understood that an actual implementation would not be decimating sample values (as you showed) but use dither. It is the difference between textbook DSP and real life implementation :).
Now if only all actual implementations would always apply proper dithering...

For me one of the biggest (only?) reasons for using more than 8bit YCbCr is that studios would have less of a chance to drop the ball. I think that dithering works well enough that 8bit is sufficient with Rec709. It's just that some studios "forget" to apply dithering. We wouldn't have that problem with 10bit. Or at least missing dithering wouldn't show as clearly in 10bit.

But the real deal I'm looking forward to is a new color format which is actually able to represent the full film gamut. And for that 10bit would probably make sense. But it seems that there's not much of a chance to get this anytime soon... :(

Now if only all actual implementations would always apply proper dithering...
I agree. People hear the word "dither," look it up in the dictionary and find out that it is "noise" and think it is a bad thing when in reality the reverse is true.

Yes, dithering of the source would be needed to avoid banding.
I think you mean the right thing but dither must be applied to the result of the computation and not the source. Dithering the source simply adds noise to it and nothing else! It is the conversion output which we want to randomize.

P.S. Your English is really good. Didn't realize it was you second language until you said it. :) The fault is trying to explain things in this one-way medium. It is not always easy....

Can I just ask some of you to confirm that the images I've posted are visible. They seem fine on one of my machines but not on another (one is ancient one is weird)

ta

But the real deal I'm looking forward to is a new color format which is actually able to represent the full film gamut. And for that 10bit would probably make sense. But it seems that there's not much of a chance to get this anytime soon... :(
At the displays level we are getting nearer, unfortunatelly we need to "shrink" them to get reasonable colors with the current standards.;)

I agree. People hear the word "dither," look it up in the dictionary and find out that it is "noise" and think it is a bad thing when in reality the reverse is true.
The reverse is true in some situations... like the one we are talking here.
If, for example, the YCbCr was increased to 10bit, dithering during the conversion of an 8bit RGB source would be bad.;)

I think you mean the right thing but dither must be applied to the result of the computation and not the source. Dithering the source simply adds noise to it and nothing else! It is the conversion output which we want to randomize.
Yes. Thanks for explaining it clearly, and also for praising my english skills.:)

Can I just ask some of you to confirm that the images I've posted are visible.
I can see all, except on your post #91. Maybe you forgot to add the pictures on that?
By the way, thanks for the pictures!

Can I just ask some of you to confirm that the images I've posted are visible.
All of them are visible for me, except those in post #91.

If, for example, the YCbCr was increased to 10bit, dithering during the conversion of an 8bit RGB source would be bad.;)
No, it would be good, not bad. Every color space conversion results in floating point numbers. If you do 8bit RGB -> 10bit YCbCr, the real chain is 8bit RGB -> floating point YCbCr -> 10bit integer YCbCr. The conversion from floating point YCbCr to 10bit integer YCbCr needs dithering, if you care about precision. Oh, the wonders of digital processing...

----------

A question to the experts here: How much bitdepth do we need to *process* (not hold) linear light RGB video data without losing precision? As far as I know, 32bit float is enough to hold all information of linear light RGB. But is it also enough to process it further (multiplications, additions etc)? I'm planning to do linear light scaling in a GPU pixel shader, that's why I'm asking...

No, it would be good, not bad. Every color space conversion results in floating point numbers. If you do 8bit RGB -> 10bit YCbCr, the real chain is 8bit RGB -> floating point YCbCr -> 10bit integer YCbCr. The conversion from floating point YCbCr to 10bit integer YCbCr needs dithering, if you care about precision. Oh, the wonders of digital processing...
I don't agree with this. 10bit YCbCr has enough resolution to hold all 8bit RGB values in different YCbCr values. The conversion from 8bit RGB -> 10bit YCbCr does not create any new values, is simply a 1:1 mapping between different spaces. The intermediate results being in floating point do not interfere with this.;)

10bit YCbCr has enough resolution to hold all 8bit RGB values in different YCbCr values.
Let's imagine there were 2 different data formats:

(a) 3 possible values, 0.0, 0.5, 1.0.
(b) 4 possible values, 0.0, 1/3, 2/3, 1.0.

Now if you convert data from format (a) into format (b), according to your logic, no dithering would be needed, because (b) has enough resolution to hold all (a) values in different (b) values, right? Ok, so try converting the following data block from format (a) to format (b):

0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
Without dithering, you'd end up with:

2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3
2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3
2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3
2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3, 2/3
Do you see that you just produced a gigantic cumulated error in that conversion? Now if you used dithering, the conversion result would look something like this:

1/3, 2/3, 1/3, 1/3, 2/3, 1/3, 2/3, 2/3
2/3, 1/3, 1/3, 2/3, 2/3, 2/3, 1/3, 1/3
2/3, 2/3, 1/3, 2/3, 1/3, 1/3, 2/3, 1/3
1/3, 1/3, 2/3, 1/3, 2/3, 2/3, 1/3, 2/3
The error in every single pixel is just as big as when not using dithering. But the *cumulated error* over all pixels is almost zero. That's the beauty of dithering. And btw, that's also how our eyes work. Our eyes care more about the cumulated error and less about small errors in individual pixels.

I think it would be better if we had more real colours instead of less colours with dithering.

Let's imagine there were 2 different data formats...
Your example does not apply to what I was saying for two reasons:
1) In what I was saying, the idea of using format (b) to store the data from (a) is to later convert it back to (a). So, if you dither, when you convert back to format (a) you would get:
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5
or
0.0, 0.5, 0.0, 0.0, 0.5, 0.0, 0.5, 0.5
0.5, 0.0, 0.0, 0.5, 0.5, 0.5, 0.0, 0.0
0.5, 0.5, 0.0, 0.5, 0.0, 0.0, 0.5, 0.0
0.0, 0.0, 0.5, 0.0, 0.5, 0.5, 0.0, 0.5
depending on the conversion formula between (a) and (b).
If you use dither, there is a chance that you could never get back to (a).
Do you see that you could just produced a gigantic distortion of (a);)

2)Your example does not mimic which happens in RGB->YCbCr conversion. The values in (a) are the same as in (b), but in RGB->YCbCr the values in both spaces are completelly different.

Your example does not apply to what I was saying for two reasons:
1) In what I was saying, the idea of using format (b) to store the data from (a) is to later convert it back to (a).
The idea of converting back and forth between two formats in a lossless way is nice, but this is not the situation we're talking about here:

(1) Original content is RGB.
(2) Studio converts to YCbCr.
(3) Studio subsamples Chroma.
(4) Studio applies lossy compression.
(5) Playback device uncompresses.
(6) Playback device upsamples Chroma.
(7) Playback device converts to RGB.

There's so much processing going on between formats (a) and (b) that this can never be even near to lossless. Which means that it's crucial that every processing step is done as good as possible, in terms of the *cumulative error*. Which means, dithering MUST be used, if you care about quality at all, even if RGB bitdepth is 8bit and YCbCr bitdepth is 10bit.

The situation might be different if you convert back and forth between (a) and (b) without ever doing any actual processing on the data. But there's no sense in doing that. And as soon as you process in format (b) and then convert back to format (a), you are in danger of losing quality if you have used rounding instead of dithering.

If you use dither, there is a chance that you could never get back to (a).
Which is not a problem at all, since this is all not lossless, anyway, due to lossy compression and chroma subsampling. We only have to keep the cumulative error as small as possible.

Do you see that you could just produced a gigantic distortion of (a);)
Nope. With my example, you have to use dithering both ways. Which means that 1/3 would become either 0.0 or 0.5. And 2/3 would become either 0.5 or 1.0. In other words, the final result would have about 25% 0.0 pixels, 50% 0.5 pixels and 25% 1.0 pixels. The cumulative error would still be near zero. Just the noise has increased. Which is exactly how dithering works. Ok, with my example the dithering noise is so high it's not funny. But this example is intentionally chosen with extreme values to make things clearer. Of course in real life dithering noise is so low that it's not visible to the naked eye.

Now let's get one step further: Imagine the data gets processed in format (b) by an algorithm which raises brightness of each value by one step. 0.0 becomes 1/3. 1/3 becomes 2/3. 2/3 becomes 1.0. 1.0 clips to 1.0. If you go (a) -> (b), then run this brightness increase algorithm, then go back to (a), if you use rounding, you'll end up with all pixels definitely being 1.0. If you use dithering, exactly the right amount of pixels would be 0.5 instead of 1.0, so that the overall brightness of the data would be 0.5 + 1/3 = 0.833333. (Or slightly higher than that, due to clipping).

2)Your example does not mimic which happens in RGB->YCbCr conversion. The values in (a) are the same as in (b), but in RGB->YCbCr the values in both spaces are completelly different.
Doesn't matter at all. We don't disagree on how to do RGB -> YCbCr conversion. We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering. And there IMHO my example fits quite well (although of course it's grossly simplified)...

The conversion from 8bit RGB -> 10bit YCbCr does not create any new values, is simply a 1:1 mapping between different spaces.
There's so much processing going on between formats (a) and (b) that this can never be even near to lossless. Which means that it's crucial that every processing step is done as good as possible, in terms of the *cumulative error*. Which means, dithering MUST be used, if you care about quality at all, even if RGB bitdepth is 8bit and YCbCr bitdepth is 10bit.
I agree that dithering MUST be used in every processing step that "creates" new data that did not exist in the previous step, or when the following step does not have enough precision to hold completelly the previous data.
This only happen for sure in steps (3), (4) and (6). In steps (2), (5) and (7), if the following step has enough resolution to hold the processed values dithering must not be used, instead we must use 1:1 mapping.
If the entire processing chain was lossless, only 1:1 mapping would be used.
It's not, so, let's use dithering only where 1:1 mapping cannot be used, or we will make it worse.

We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering.
No. As I explained above, we disagree because you want to consider the 8bit RGB to 10bit YCbCr conversion as any other kind of processing that "creates" new data, and I do not. This process only converts a group of values into another group of values of the exact same dimension, a 1:1 mapping, and if we use dithering in a 1:1 mapping process, then it's not a 1:1 mapping process anymore.
What you are saying is the same as dithering a 1920x1080 8bit RGB image right before sending it to a 1920x1080 10bit display. You will only add noise.;)

you want to consider the 8bit RGB to 10bit YCbCr conversion as any other kind of processing that "creates" new data
Where did I say that?

Look, dithering theory is really simple: Whenever you reduce bitdepth, you use dither. It's as simple as that.

What you are saying is the same as dithering a 1920x1080 8bit RGB image right before sending it to a 1920x1080 10bit display. You will only add noise.;)
Going from 8bit RGB to 10bit RGB means we're increasing bitdepth. By definition dither isn't needed in that case.

But if you go from floating point YCbCr to 10bit integer YCbCr, you do reduce bitdepth. The proof is simple: If you convert the 10bit integer YCbCr back to floating point, you will end up with different floating point numbers than you started with. Ergo: Bitdepth reduction -> dither.

FYI, I was going to pick on the same point Madshi did yesterday but let it go :). Net, net, he is right and the rule is much simpler than you are assuming as he explained. See more below.
No. As I explained above, we disagree because you want to consider the 8bit RGB to 10bit YCbCr conversion as any other kind of processing that "creates" new data, and I do not. This process only converts a group of values into another group of values of the exact same dimension, a 1:1 mapping, and if we use dithering in a 1:1 mapping process, then it's not a 1:1 mapping process anymore.
Again, looking at whether we have enough input our output sample points it not the only deciding factor as to whether we dither or not (my clarification to your previous argument). But rather, whether at any time during conversion, you wind up with more accuracy than you are representing in the output.

Let's look at a simple example. Let's say I have an audio system which has integer levels from 0 to 100. I then add a digital volume control to it and set that to 0.3 and the input value is 3.0. The gain stage multiplies 0.3 by 3 and gets 0.9. Do you think you should dither or not? Note that I have not changed anything as far as the number of inputs and outputs. We still have a scale of 0 to 100 regardless.

The answer is of course we have to dither. Otherwise, you get the bad sound that digital volume controls are known for.

So to the extent you are going to generate fractional results as you showed in your example to me, you must dither. 87.67488737487 or whatever the value is, cannot be represented in 10 bits any more than it is in 8 bits. Both are whole integer numbers and can't hold the fractions in that floating point value.

What you are saying is the same as dithering a 1920x1080 8bit RGB image right before sending it to a 1920x1080 10bit display. You will only add noise.;)
Let's look at this example.

Assume we have a ramp in the smaller space that goes from 0 to 10: That would give us:
0 1 2 3 4 5 6 7 8 9 10

Now let's say we double the number of steps in a new space. If we just map them as is, here is what we get:

0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10

Does this look right to you? If the display properly shows all the new levels, do you think you still have a smooth ramp?

Where did I say that?
You didn't.

We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering.
I've found the flaw on my logic, and it wasn't that. I was forgetting that 8bit RGB does not map exactly to 10bit YCbCr.:o
We can have all the number of colors representable by 8bit RGB represented in 10 bit YCbCr, without loosing any of it, but they will not represent the exact same colors, because that would be lost during the rounding process. If no further processing ocurred in the 10 bit YCbCr before we converting back to 8bit RGB, then it would be better not dithering, because due to the rounding being performed the same way back, the exact colors would be retrieved, but that's not what's happening, so we should dither.

I'm very sorry if I have confused anyone...

Edit: amirm, as you probably will see, I already discovered where was my flaw before your post... Thanks anyway.;)

Let's look at this example.
Assume we have a ramp in the smaller space that goes from 0 to 10: That would give us:
0 1 2 3 4 5 6 7 8 9 10
Now let's say we double the number of steps in a new space. If we just map them as is, here is what we get:
0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10
Does this look right to you? If the display properly shows all the new levels, do you think you still have a smooth ramp?
When I said 1:1 mapping, I was not saying bit:bit mapping, like you are doing in your example. In your example, you decrease the dynamic of the original signal. The bigger bit depth increases level resolution, not the highest and lowest values.

Where did I say that?

Look, dithering theory is really simple: Whenever you reduce bitdepth, you use dither. It's as simple as that.


Sort of agreed but really dither is useful any time the answer cannot be represented exactly in the target system. For instance working in 16 bit color doing a simple average of two adjacent pixels values for whatever reason the answer could come out to something and a half and it could be beneficial to dither it. Doing so would both decorrelate errors (hide banding) and also reduce the error of the average in any area.

I'm not sure whether your wording was already intended to cover that case.

- Tom

Sort of agreed but really dither is useful any time the answer cannot be represented exactly in the target system. For instance working in 16 bit color doing a simple average of two adjacent pixels values for whatever reason the answer could come out to something and a half and it could be beneficial to dither it. Doing so would both decorrelate errors (hide banding) and also reduce the error of the average in any area.
You're right, of course. Personally, I like the idea of running all processing algorithms in the highest bitdepth your hardware can handle, ideally 32bit or even 64bit floating point, and then to dither down to the target bitdepth as the last step. This way you don't have to dither during processing, but only once at the end of the processing chain.