YCbCr --> RGB conversion tips

[lordtangent]

I've recently been doing a little reading about YCbCr to RGB conversion and it occurred to me that this is an area that can have a profound effect on the quality one can get out of an HV20. You see, part of the issue, aside from the color sub-sampling inherent to compressed formats like DV and HDV, is that simple color space conversion conversion is ALSO a lossy operation in and of itself. Add to that the issue of "video" color range [16-235] vs. "Computer" color range [0-255] and it seems like it would be a really good idea to understand the subtle but important details regarding how the color is handled in ones "pipeline" when quality is a priority.

I did some tests to try to determine exactly what it is that comes out of the HV20 in terms of "color space". The results were a little surprising, but mostly in a good way.

As you know, the HV20 saves it's video in "HDV" format, which is really nothing but an mpeg2 stream with very specific parameters. mpeg2 should use a Rec709 matrix/coefficients for it's interpretation of YCbCr. Basically, Rec709 defines how the YCbCr is to be interpreted for conversion to RGB. (there is more than one "formula" for conversion to and from YCbCr to RGB. Rec709 is the standard formula used for HDTV and modern YCbCr professional video gear.)

For my tests, I used AVISynth to convert from the HV20s mpeg into RGB using the four standard formulas it provides. People familiar with the "Farnsworth" method for removing the hard telecine in the movies from the HV20 might recognise the name of the program. Think of it as a Swiss Army Knife for working with video.

This is where the surprises came up. It seems that while the HV20 pads the blacks as specified by Rec709 (it puts "video black" at code value 16) it uses the rest of the range, all the way up to code value 255 to encode whites.

This is actually good news for our purposes. We get more headroom for our whites!

The trick is, you need to convert the video correctly. If you convert the video in the standard (arguably "correct") way, scaling the Rec709 video [16-235] to computer space [0-255], the BLACKS will be in the correct place but you will clip the whites. By default, this is probably what most codecs do when decoding the video.

To hang on to those extra whites, what you need to do is pass the video straight though, converting the code values 1:1 without scaling. So, instead of scaling the video color range [16-235] to fit in the computer color range [0-255], you basically pass it straight though with no scaling. It will make the blacks look a little milky, but you'll hang on to more of the highlight values. The milkiness in the blacks can be corrected in post and it will be no more lossy a color correction than if you scaled them in the initial conversion anyway. The advantage is that you've held on to more highlights.

This is another advantage of using my AVISynth pipeline for converting HV20 HDV. Not only can you process the inverse telecine on the fly, you can also control precisely how the color is being handled on the YCbCr to RGB conversion, something that is not normally exposed by most playback codecs.

I'm attaching the output from the conversion tests. The files that have "PC" in the names are the ones that use full range conversion (no scaling). As you can see, they look a little flatter and the blacks are milky. OK, no problem with the blacks, we can fix that. To really see the difference you have to look the image with a color picker. See the headlights of the cars? They actually go above 235, proving that data is in fact encoded in that "super white" range. Using the standard Rec709 conversion would clip those values. (Compare the images, the scaled "Rec709" and the unscaled "PC709") Way more room for grading in the PC709 images.

Considering the limited bandwidth of HDV is makes sense to hang on to everything that we can. MOST editing programs, unfortunately, work in RGB color space so this conversion step is often a necessary evil. It makes sense to take control of how the conversion is done. Converting the YCbCr straight across rather than attempting to scale it to PC color range, in this case, seem to be the way to go.


First image... Incorrect conversion (the default!)



Second image... more correct... no scaling of "video" to computer color.



Last image... my graded image which fixes the lifted backs but leaves the
newly found white dynamic range. (I lifted the saturation a little also )


UPDATE:

Another thing I want to add is even systems that work in Y'CbCr natively will some times run "video legal" filter on footage without asking you. That will effectively cut off any of the out-of-range data. That is a caveat that you definitely need to be aware of even if your NLE is YCbCr native. Make sure you know what your NLEs default behavior is. Also, keep in mind that a lot of filters in many NLEs are RGB only. The NLE will convert the video to RGB and back to YCC without telling you, often also running those "video leagal" filters in the process.

More UPDATES:

My recent testing (October 2008) has revealed that Adobe CS3 handles the super-whites correctly. Using Premiere to edit and After Effects to remove pull down and color grade as described in this post [ http://hv20.com/showthread.php?t=14476 ] by Max Goldberg is a straight forward system that addresses both while maintaining the highest quality. To save the super whites you must run After Effects in Floating Point mode. At that point the only real caveat is that some effects in AE are NOT floating point. You must be careful to remap any super white values back into the 0-1 range before running any non-float filters or they will be clipped. It's not as complex as it sounds. And nearly ALL the color correction filters are float so if you do all your color correction first you will likely never have any problems.

Non-float filters are labeled with a little exclamation point in a warning sign. They stand out in the filter stack quite obviously and are easy to spot. Color correct first and you will usually be OK. However, if for some reason you need to pass super whites THOUGH some non-float filters there is a simple trick. You'll lose some precision but not much. Use "Levels" to map the super whites into the 0-1 range using the output white slider before running the non-float filters. You can then map the values back up AFTER the non-float filters using another Levels with the input white slider (set to the same value you used in the previous Levels output white) if required. This will map the super whites to the exact sample place they were before the non-float filters. The non-float filters run in 16 bit mode so there will be some the loss in precision. But it will not be big enough to worry about if you map the float values down in a sane way.. i.e. only pull down the whites just enough to get them under 1 (in most cases it should not require more than about a 10% reduction)

To-date I have only tested this with HDV sources and not with direct captures from the Intensity (I currently don't have access to my Intensity workstation). The more convoluted work-flow requiring pre-processing with AviSynth might still be required for those sources. But since the pre-processing actually serves to COMPRESS the footage (we are talking about 60i footage in a pure Uncompressed codec vs the post-processed footage at 24p in a lossless compressed format) In that particular case pre-processing in AviSynth actually has advantages that make up for the extra work it requires.

[SenorKaffee]

Do you start with DGIndex on your AVISynth pipeline?

[RHKFilm]

Hello,
When comparing your graded version to the default version, I definitely appreciate the difference. The sky of you graded image lookss more like dusk with better coloration and detail. The clipped whites version doesn't read as dusk as well as yours does.
At first I was looking at the headlights for a difference, but those seem to be nearly clipped in both versions.
Good work! I will test on my suite to confirm. Would it be possible to post an unconverted version of this image/video?
-RK

[lordtangent]

Do you start with DGIndex on your AVISynth pipeline?

Yes. This is just a slight tweak to the "Farnsworth" system. DGindex -> AVISynth -> VdubMod (or frames served directly from vfapi loader)

Really it has nothing to do with 24p, but I figured since people in this section of the forum would be a little more familiar with AVIsynth this would be a good place to put it. As far as I know, most codecs don't expose the "how to convert YCbCb to RGB" control, but most edit packages work in RGB and require conversion. The codec often handles it, but as you can see there is room for error if you don't get it right. You could potenitally waste a good deal of your highlight headroom. It's something to definitely be aware of.

BTW, the name of the funtion in AVISynth is ConvertToRGB() You want to use the matrix="PC.709" option something like this:

ConvertToRGB(clip, matrix="PC.709")

Near the end of your scipt. Keep in mind though, this will promote the outgoing video stream to RGB. You will want to be careful to be sure you don't accidentally DOWN convert it again to YUV when you compress it with HufYUV or Lagarith. (THey both have the option of doing YUV or RGB. Make sure you use RGB!) The files will be bigger, but you can be certain of the values contained.

OR, you could use my personally prefered method of using the vfapi loader to serve the frames live from AVISynth. No more transcoding and no more YUV->RGB surprises!

[Erik Bien]

This thread gets my vote to become an "instant sticky."

(I don't know beans about post but even I get how this will protect innocent highlights!)

[Frank]

I've recently been doing a little reading about YCbCr to RGB conversion...

First of all, thanks for doing this research and posting your results.
Second of all, where have you been reading? I would like to learn more about this.

[RHKFilm]

Hello,
I'm wondering if other people have thought about why this might be the case. It seems to me like the truncated colorspace exists for compatibility with TV's of years past. I always edit HD and intend for my audience to watch on an HDTV or computer screen. I do have friends and family (most of them in fact) that end up watching on a DVD player attached to a regular TV. Any thoughts?

RK

[lordtangent]

Hello,
I'm wondering if other people have thought about why this might be the case. It seems to me like the truncated colorspace exists for compatibility with TV's of years past. I always edit HD and intend for my audience to watch on an HDTV or computer screen. I do have friends and family (most of them in fact) that end up watching on a DVD player attached to a regular TV. Any thoughts?

RK

You are 100% correct. In 8 bit the code values 16-235 of rec708 correspond almost perfectly to the old analog NTSC "magic numbers" of 7.5 IRE (AKA "video black") and 92.5 IRE (AKA "video white"). It's legal in old analog NTSC to go to IRE 100 which is called "peak white".

So, you see they are doing things almost exactly the "old way" only in digital space rather than analog. The "peak white" values are totally legal which is why they are recorded by the HV20.

Why the "video black" level (code value 16) is still recorded into the digital video itself in this day and age kind of leaves me scratching my head. I mean, why "hard code" it into the video file when the analog circuits of the playback device could easily make it on the fly? Why not use the entire color range of the video format to encode picture? (A little trivia here: Many professional digital decks allow for this "full range" "super black" recording. But you have to be really careful when you do so. It's still considered a hack. You must make sure everyone is "on the same page"... the post house, etc, etc... otherwise your picture can get screwed. Another bit of trivia, NTSC-J, the variant of NTSC used in Japan, actually uses 0 IRE for video black... NOT 7.5 IRE. Thier system was always "full range"! )

So, the trick with the HV20 and I'm assuming all HDV cams, is to make sure we are actually get the full range the camera records out of the video files. What we really want is... everything we can get! Which in this case is code values 16-255. We don't want the YUV to RGB converter we are using to throw away those top code values (whites) by assuming that "235" is white and scaling everything.

If you have editing software that works in YUV natively and doesn't ever convert to RGB you MIGHT be immune from the problem... maybe... but it would still be a really good idea to test and make sure. The problem is, such software is still kind of rare. MOST software still functions in RGB, which means a mandatory conversion and/or round trip at some point.

Round-tripping the image YCbCr -> RGB -> YCbCr more times than absolutely necessary could be disastrous for image quality, ESPECIALLY if you are doing it incorrectly and scaling the color each round. Think about it. Each round trip the image will seem to get more and more contrasty. (as the faulty conversion assumes 16-235 = 0-1 when really 16-255 = 0-1, or maybe 0-255 = 0-1 YIKES! even I'm getting confused! ) I seriously suspect this is why so many codecs mutilate the color of the video fed to them. It isn't the codec that's doing it, it's the fact they are either adding or removing that "video" range when converting color space before compression... without asking or even notifying you to the fact.

What I'm suggestion here, which is an early conversion to RGB and STAYING at RGB until you are ready to make your final output, might seem a little odd. But for majority of editing tools out there (still working natively in RGB only) it is likely the most fool-proof way to avoid "surprises" regarding your color as it will reduce the amount of "round trips" to the minimum. It also gives you a known quantity as a starting place.

This is one of the reasons (among many others) why AVISynth is so great. It's easy to know for sure what the heck is going on under the hood.

[lordtangent]

First of all, thanks for doing this research and posting your results.
Second of all, where have you been reading? I would like to learn more about this.

I'm a professional CG artist (3D). I've also been doing Photoshop and photography for years as well as quite a bit of video. So, some of what I'm bringing here was already in my head. Other stuff I kind of just started thinking about because of these amazing new little consumer cams. (Like when DV first cam out... I went though a similar process of just being blown away by them)

I read a lot of trade magazines and professional forums. And you would be amazed how useful Wikipedia can be! I also found the AVISynth documentation enlightening. You don't think about the ramifications of seemingly simple things like 4:2:0 color sub-sampling until you have to deal with the nitty-gritty of image processing it.

These articles formed the foundation for most of my thinking on this particular topic. Also reading this forum, and playing with AVISynth. The rest I figured out though intuition (based on previous knowledge) and experimentation.
http://en.wikipedia.org/wiki/YCbCr
http://www.animemusicvideos.org/guid...olorspace.html
http://en.wikipedia.org/wiki/Chroma_subsampling

[Redsandro]

This is truely interesting. There's a conciderable difference in the images, especially notable when saving them to disk and swapping them in a fullscreen display.

However, I'm not entirely convinced what's happening why. Maybe you can shed a light on this.

First, since HDV is a recording standard, how is it possible that the HV20 exceeds the standardized color gamut?
What did you use for raw capturing? Is it possible that the capture software erroneosly or deliberately interpolates the gamut to a new scale?

http://en.wikipedia.org/wiki/YCbCr sais:

When representing the signals in digital form, the results are scaled and rounded, and offsets are typically added. For example, the scaling and offset applied to the Y' component per specification results in the value of 16 for black and the value of 235 for white when using an 8-bit representation. The standard has 8 bit digitized versions of Cb and Cr scaled to a different range of 16 to 240. This arbitrary "footprint" forces rescaling by the fraction (235-16)/(240-16) = 219/224 when doing color matrixing or processing in Y Cb Cr space. This results in unnecessary quantization distortions which a choice of identical ranges would have rationalized.

So if I understand correctly, the ranges of the standard are as follows:
Y : 16 - 235
Cb: 16 - 240
Cr: 16 - 240

So I think any value above 240 must be artificial. I don't understand the clipping anyway since you throw away (at least) 32 shades of data storage (8 bits per channel are needed anyway because 7 bit is too little), but hey that's the standard.

Second, since capturing is getting the HDV data from the tape 1:1, wouldn't the NLE or other software used for capturing make no difference at all? If there is white headroom coming from the camera, shouldn't the NLE get these as well?

Third, I think any serious NLE works with YCbCr. Other software like Premiere offers you to choose a codec, so it's up to you to choose a YCbCr one. Therefore, there is no initial conversion. If your target media is television, you want to keep the milky look. If your target media is a computergame, then you might want to rescale your gamut while converting to RGB. But you don't have to. Aren't there a lot of codecs that keep data in YCbCr format? Not sure.



Now I have some questions, if I may.

A question about the subject; since HDV (over Firewire) is in BT.709 colorspace anyway, why does exporting HDV usually come with an option for RGB or 709 output? When I export CGI in 709 mode it looks RGB and when I export in RGB mode it looks 'milky' (709 like). So it seems to me this option is more like a question as in "What format is the SOURCE material?" What do you guys think?

Avid is (like any NLE) supposed to capture the HDV data 1:1. Can you get the data out of Avid (or the OMFI media files) without recompressing? Exporting in the DNxHD codec turns 5 minutes into 6 gigabytes whilst MPEG is close to 1 gigabyte. The latter is obviously HDV native, but it sais nothing about when it's recompressing or not. Given the time it takes, I'd say it's always recompressing, thus (probably) messing with the GOP, making the export of the capture worse in quality then the capture itself. You could use DNxHD to keep quality, but multiplying filesize by 6 is just not the same as having raw HDV material.

(HDV) MPEG export settings lets you choose a quality some steps between low and high. Which one resembles compression used in the camera (on tape)?

[Redsandro]

Why the "video black" level (code value 16) is still recorded into the digital video itself in this day and age kind of leaves me scratching my head. I mean, why "hard code" it into the video file when the analog circuits of the playback device could easily make it on the fly? Why not use the entire color range of the video format to encode picture?

I think people are concidered stupid and old televisions (well, relatively old, as these old televisions are still being made!) are supposed to be kept into account for a long time.

By people are concidered stupid I mean most consumer and prosumer cameras choose narrowing the color gamut above having to explain to their users why their video's show up messy (see below).

And by old televisions I mean analog superblack and superwhite (0 and 255) can leak into audio and colors in the analog signal, making the video display messy. Analog circuits could only fix it on the fly if we replaced them in all televisions.

I tried it on my only-few-years-old Panasonic crt tv: absolute black looks dark purple and makes dark parts of colors look in greyscale. White colors and the sound, however, stay okay.

[Redsandro]

Here's something I just found out that broadens my confusion:

I did an export of a project in MPEG. Opening it with Media Player Classic and making a screenshot of black gives RGB values of 16, 16, 16; whilst opening it in VirtualDub-MPEG and making a screenshot gives black values of RGB 0, 0, 0.

Which one is cheating?

[lordtangent]

Here's something I just found out that broadens my confusion:

I did an export of a project in MPEG. Opening it with Media Player Classic and making a screenshot of black gives RGB values of 16, 16, 16; whilst opening it in VirtualDub-MPEG and making a screenshot gives black values of RGB 0, 0, 0.

Which one is cheating?

You bring up the issue I was trying to make over any other point: If you really want to get the best results you simply have to know what is going on under the hood and take control. (See my above comments on round tripping stuff without being sure what is going on)

So, which is cheating the example you give? I would say vDub is doing the "right" thing based on the official rec709 spec and the canonical conversion of rec709 to computer RGB. But in the process it may be throwing out precision in the "super white" area. (it depends on how the decode codecs developer decided they wanted to do things. You are at their mercy. )

The only way to really have control is to use a fully accounted for "decode chain" where we positively know what is going on under the hood. Amazingly, even AVISynth doesn't FULLY expose that stuff. (It gives more control than just about anything out there short of a full blown color management system though)

I don't think the over 235/240 whites are artificially created. There is good data in there, not interpolated garbage. And based on the old analog stuff those over "92.5 IRE - like" values are totally legal.

Of course, part of the problem here is we are talking about what in professional terms amounts to a toy camera. It's probably a little dangerous to apply professional expectations to it. But based on my observations so far I believe things are working as I stated in my first post.

I intend to do more tests. I just haven't had the time yet.

P.S. Yes, a GOOD NLE will work in YUV space. But it's surprising how many NLEs are not good NLEs that way.

[bluegrass]

I've got to congratulate red & lord. You're speaking English but it's completely Greek to me. When you get it all solved and which NLE is a good ylu to rgb editor that doesn't f&*^% up my colors, please let me know which one it is and how to do it. and please translate it to plain English for me. Thanks. It seems like an important and interesting topic but about 10 floors above me. Maybe I should take all the terms and let Wiki digest them and spit out some data printouts for me to study.

[Redsandro]

I like to know how it works. Knowledge is power. I like free power.
Currently I want to figure what tool gives me raw and honest control of the videostream so I can do some testing for myself. The weird thing about my last post is that both Vdub and MPC require codecs to be installed. I THINK they both use the same. Still, colors are scaled differently.

Too bad I cannot feed a photoshop testimage to my HV20-cmos and see what whites are clipped or not.

Blue, if I ever figure out a factlike way to preserve most quality, I will let you know. For now, according to Lord's experiments, if I understand correctly, just capture with HDVsplit and do the AviSynth magic with which I cannot help you since the only thing I use it for is piping a direct show source to Vdub that cannot be directly opened in Vdub. And I haven't got a clue about DGIndex.. :$

[lordtangent]

Too bad I cannot feed a photoshop testimage to my HV20-cmos and see what whites are clipped or not.

.. :$

For the purposes of testing you could shoot a properly exposed test chart. It would give you "white" and if you included other things in the scene, say bright white objects or even reflective objects, it would potentially give you some "super white" areas also. (Which you could use to determine if you are clipping or not when using various post pipelines)

That's what I intend to do. (when I have the time...)

[Redsandro]

I think I can write a gd library script that checks all RGB values to see if any value in the range is structurally skipped, which would mean the higher whites are obtained by spreading the 16-235 scale over 16-255. But for that, a still from the camera would need to be converted to RGB and that's the untransparent part..

I think not, though. I think you are right, because I haven't noticed any 'banding' on footage. But then again we can't be sure if gaps are filled through interpolation.

I'll be testing, too. I have an important project coming up, and I want the best possible quality out of it. Which raises another slightly off-topic question: If your initial idea is correct, would clipping the whites give an overall better quality as opposed to scaling 16-255 back into broadcast range, because the latter would once again interpolate the entire scale?

[lordtangent]

If your initial idea is correct, would clipping the whites give an overall better quality as opposed to scaling 16-255 back into broadcast range, because the latter would once again interpolate the entire scale?

Are you talking about going BACK to HDV (or broadcast)? In that case, I don't know the correct answer. I guess to make TECHNICALLY correct video, you would want to scale it into the broadcast range. But there is a little wiggle room there. You could allow really bright areas to hit the "peak white" range. That is what it is there for.

I can tell you one thing: There are a lot of pros who have no problem at all "bending the rules" to get the look they want out of video gear. Even if that means pushing white to 100 IRE. As long as the signal doesn't clip altogether, you are cool.

As for acquiring video via HDV, I'd say you would still want to be very careful with exposure as usual. Actually, it would be best to pretend you don't have any of that extra white headroom, and imagine that 235 (92.5 IRE... AKA video white) is white for the purposes of exposure. Actually, you might even want to underexpose a little, if the scene has very bright areas. "Expose for the whites" as they say. Just make sure you don't clip. The only concern would be underexposing to the point that you can't time it up in post without making the noise of the sensor visible. Having a few little highlight blow out is a better trade off than tons of noise in your image.

Above code value 235 stuff then just serves as extra safety. And if you handle it correctly in post you wont loose the precision.

[Redsandro]

Yeah I meant either going back to HDV or when the product is for DVD/HDDVD.

There's a show on national public broadcast that goes RGB 000 (I think). It distorts the picture on some tv's (like mine). I think it all looks fine in their kickass €€€ studio, but my tv, and therefore me, don't like it. That's where I don't agree with the professionals.

I haven't seen a problem with superwhite though. So if it's there, I want to use it. Not sure (yet) if NLE crops it anyway.

Thanks for the tips.


BTW - come to think of it.. at the risk of asking a stupid question, the HV20 is my first and only camera. Is the 'extra white' truely a 'bonus' or do all camera's actually add this? I know the theory.. but there it stops.

[Ian-T]

.... Actually, you might even want to underexpose a little, if the scene has very bright areas. "Expose for the whites" as they say. Just make sure you don't clip. The only concern would be underexposing to the point that you can't time it up in post without making the noise of the sensor visible. Having a few little highlight blow out is a better trade off than tons of noise in your image.

....

In order to follow your recomendation in this statement do you think it's best to allow the camera to automatically set the exposure and then from there manually set it a notch or two lower? I ask because I really don't know what too low is (or can't tell in the cams LCD) and I don't want to bring the image down to the point of no return. I have had a couple of occassions where is was in manual mode and conciously set it a few notches lower than what I saw with using the zebras and the picture came out too dark (darker than what it appeared in the LCD). When bringing it back up in post I noticed the "sensor noise" you mentioned earlier.

Edit: I'm not complaining at all about the image quality on this cam...I just want to get the BEST possible image I can out of the HV20.

[Ian-T]

Also, the reason for my question is due to the fact that what "I" choose in manual mode for "good exposure" is not necessarily what the cam chooses when in automatic mode (which is probably why a few of my shots came out too dark).

[lordtangent]

Also, the reason for my question is due to the fact that what "I" choose in manual mode for "good exposure" is not necessarily what the cam chooses when in automatic mode (which is probably why a few of my shots came out too dark).

I'm assuming color grading in post. Otherwise if you follow this advice you probably are not going to be too happy with the results. Another thing to keep in mind is the best approach is really to just avoid high dynamic range scenes to begin with and be very deliberate with your lighting. Light within the dynamic range of the camera and you can get FANTASTIC results. (With almost any camera actually... no matter how crappy it is) Of course, that is the art of photography and it takes a while to master.

Letting the camera figure out the initial exposure and working from there is a good starting place. (Even a basic light meter is pretty smart! But modern camera all have some sort of multi-zone metering... they are VERY smart)

I personally also use the zebra stripes to make sure I'm not blowing out anywhere. That's the pro way of doing it. If you don't already have the zebra strips turned on in your camera I strongly recommend it. Its under the "Assist Func." menu.

When I give this type of advice I'm talking more to people who want to shoot single camera cinema style, where each shot is carefully composed and lit. The same goes for even worrying about that last 10% or so of "super white" on the YCbCr conversion. My intended audience is other perfectionist aspiring film makers like myself. But for home videos even I wouldn't worry TOO much about perfect exposure, etc. and just get on with shooting. I'd let the camera do what Canon has designed it so well to do (be a home-video camera) Otherwise every birthday party would turn into a high production Hollywood movie and you'd never get round eating the cake!

[lordtangent]

BTW - come to think of it.. at the risk of asking a stupid question, the HV20 is my first and only camera. Is the 'extra white' truely a 'bonus' or do all camera's actually add this? I know the theory.. but there it stops.

Pro equipment does it. Your guess is as good as mine when it comes to consumer stuff. My tip is still useful anytime you need to convert YCbCr to RGB and you suspect the extra white is there. Now that I've noticed this detail with the HV20 I'm going to definitely be thinking about it in the future when I deal with other cameras.

It never hurts to test any gear you are working with and try to figure out exactly what is going on under the hood.

[Redsandro]

True.

I personally also use the zebra stripes to make sure I'm not blowing out anywhere.

I use zebra at 100% white, but after capture I still get detail in the parts that were marked as totally white.
Maybe zebra 100 marks the 235 part.

Do you ever use zebra 70?

What special color conversion do you actually do at the time?
Squeeze 16 - 255 back into 16 - 235, or expand it to 0 - 255?

[lordtangent]

Maybe zebra 100 marks the 235 part.

Do you ever use zebra 70?

I went though a bit of a thought experiment just the other day with a friend over this issue because we observed the same behavior. I think "100 means code 235 / IRE 92.5" is a very sound theory. But I wont know for sure until I test more. (I'm working 6-7 days a week right now so not a lot of time to do tests!)

I haven't used zebra 70, but I was going to test that also. Using it as a guide should theoretically leave a lot of headroom. But maybe it's TOO low? The cam is only 8 bit so there is only so much we can push around the image in post. Plus there is the danger of WAY under exposing and wasting too much of our latitude. Not good. As much as I hate the way video clips specular reflections and other bright areas, I have to say a super grainy image with banding from pushing the colors too far would be even worse to look at.

What special color conversion do you actually do at the time?
Squeeze 16 - 255 back into 16 - 235, or expand it to 0 - 255?

see my initial post: http://www.hv20.com/showpost.php?p=17739&postcount=1

Essentially I'm going YCbCr 0-255 --> RGB 0 - 255 How you handle it from there really depends on your intended output target.

Jumping back to your earlier question regarding going back to YCbCr... If you wanted to keep the same relationship with the original signal going back to YCbCr you would just want to do the reverse RGB 0 - 255 --> YCbCr 0-255. Just make sure you don't remove that black pad up to code value 16 while you are working in RGB or your blacks are going to get clamped in the conversion back to YCbCr.