Finding reason for differing colors

[jagabo]

Y'CbCr gets converted to RGB with a Rec matrix , so Y' 0-15 and 236-255 get clipped (i.e. 0-15 becomes all black instead of seeing gradations, and 236-255 becomes all white, instead of "shades" of white) . That's why you don't see a fold

You don't get it. The final video does contain the folds. That's not possible if clipping has taken place before. Lost information is not recoverable!

No, you don't get it. That bright detail will be lost when displayed on the TV -- it will not show up on correctly calibrated system.

[CryGuy]

I do believe you, but I'm surprised that a H.264 encoder doesn't always output TV levels. I thought it violates the standard it's made for. Instead, we must adjust the RGB to TV level before encoding to ensure TV level in the target video? Well, in that case, I've really learned something new.

When you are feeding Y'CbCr material to most encoders, there is no intermediate colorspace conversion (you're not converting to RGB at the encoding stage) . So input = output levels.

You said this already in other words. I said I got it.

The difference is most DEcoders will use Rec matrix to convert to RGB for display - so if you don't legalize Y' values, you won't see 0-15 or 235-255.

Yes, and if I choose 0-255 as EVR color space, it works well.

I have a strong feeling you're not understanding what was being discussed earlier. You wouldn't be asking these questions.

You don't understand that I knew it before starting this discussion. But I'm repeating myself once again.

In your original file , you have values that are superwhite. Normally white is Y' 235.

Again, it's MJPG. It uses full range. Read the specs. That's "normal".

But you have values greater than that. If you don't legalize values, they will clipped upon display by the RGB conversion

Again, it depends on the settings.

BMP's are RGB.

Really? Enough!

So in the case of avidemux you are converting to RGB with a Rec matrix. You don't have control over this conversion in avidemux, but you do in other programs like avidemux. If you wanted to map full range using a PC matrix for example.

I know.

[CryGuy]

Y'CbCr gets converted to RGB with a Rec matrix , so Y' 0-15 and 236-255 get clipped (i.e. 0-15 becomes all black instead of seeing gradations, and 236-255 becomes all white, instead of "shades" of white) . That's why you don't see a fold

You don't get it. The final video does contain the folds. That's not possible if clipping has taken place before. Lost information is not recoverable!

No, you don't get it. That bright detail will be lost when displayed on the TV -- it will not show up on correctly calibrated system.

You still don't get it. This was not the point. Read thoroughly next time. I wrote the final video does contain the folds. I did not even mention displaying it. You're completely mixing up things. My argument was that the fact that the final video contains the folds prooves that the image saved by Avidemux is not the same as the one sent to the encoder.

[Cornucopia]

Lost information is not recoverable, but hidden information might be considered lost even though it isn't. That IS recoverable.

IMO, the 1st thing to do is find out what your original truly contains USING TOOLS THAT DON'T AFFECT that data. Then understand that the paths that affect the display of data may not be the same paths that affect the encoding/conversion/rendering of the same data.

Sometimes it pays to MAP OUT every link in the chain, and describe how each link affects the original. It can often reveal something that is going on that you may not be considering.

Scott

[CryGuy]

I'm surprised that a H.264 encoder doesn't always output TV levels. I thought it violates the standard it's made for.

The job of a codec is to reproduce what you give it, not fix your video for you.

Depends on what you consider requires fixing. I already said I've learned that full RGB range is not considered suitable. What else do you want? I don't fall down to my knees for not knowing this before.

...

You don't get the point.

[CryGuy]

Lost information is not recoverable, but hidden information might be considered lost even though it isn't. That IS recoverable.

A bitmap displayed in MSPaint doesn't hide anything.

IMO, the 1st thing to do is find out what your original truly contains USING TOOLS THAT DON'T AFFECT that data.

Yep, and before I thought this is done by saving it as a bitmap in avidemux. I made a guess why, but it wasn't understood. Luckily I don't need anyone else to understand it. It's sufficient if I do. My consequence is only using virtualdub+ffdshow in future because that gives the most reliable picture. It works for me. You may use a different approach.

Then understand that the paths that affect the display of data may not be the same paths that affect the encoding/conversion/rendering of the same data.

Sometimes it pays to MAP OUT every link in the chain, and describe how each link affects the original. It can often reveal something that is going on that you may not be considering.

I do understand, and that's my daily business.

[CryGuy]

Can someone close this thread? I thought I find people here that are able to grasp the context and think logical. I'm disappointed now.

Anyway, apart from the most unnecessary information repeated several times, I also got new information. Thanks for that in any case.

Bye

[poisondeathray]

I normally would let it drop, but there still seems to be some misunderstanding, and other people searching for information might get confused and the wrong information

Y'CbCr gets converted to RGB with a Rec matrix , so Y' 0-15 and 236-255 get clipped (i.e. 0-15 becomes all black instead of seeing gradations, and 236-255 becomes all white, instead of "shades" of white) . That's why you don't see a fold

You don't get it. The final video does contain the folds. That's not possible if clipping has taken place before. Lost information is not recoverable!

You misquoted me, and didn't include the first sentence. It makes more sense when you include the whole quotation:

The reason for your avidemux bmp observation was explained earlier

Y'CbCr gets converted to RGB with a Rec matrix , so Y' 0-15 and 236-255 get clipped (i.e. 0-15 becomes all black instead of seeing gradations, and 236-255 becomes all white, instead of "shades" of white) . That's why you don't see a fold

As you see, this statement refers to the BMP, not the video. The clipping occurs in the BMP.

If you go on to read the next reply it explains why the data is in the video, but you shouldn't be seeing it. If you are seeing the folds in the exported avidemux x264 encoded video, this indicates a larger calibration problem in your setup. This means 99.9% of all other videos will not look correct on your setup. (blu-ray, dvd, flash, downloaded videos, just about everything) . You might want to have a look at calibrating your setup.

Lost information is not recoverable, but hidden information might be considered lost even though it isn't. That IS recoverable.

A bitmap displayed in MSPaint doesn't hide anything.

But a BMP does hide something. RGB vs Y'CbCr video....Rec conversion matrix.... remember ?

IMO, the 1st thing to do is find out what your original truly contains USING TOOLS THAT DON'T AFFECT that data.

Yep, and before I thought this is done by saving it as a bitmap in avidemux. I made a guess why, but it wasn't understood. Luckily I don't need anyone else to understand it. It's sufficient if I do. My consequence is only using virtualdub+ffdshow in future because that gives the most reliable picture. It works for me. You may use a different approach.

So in the end you decided to do what was suggested; use legal levels instead of retaining full Y' levels as in the original - because that's what ffdshow is doing - clamping levels to legal range





Listen, we are honestly just trying to answer your questions. I apologize if you got the wrong impression are offended

But if I just answered: the reason for your observed difference is because of "decoder levels, different colorspaces RGB vs. Y'CbCr, matrix conversions" without farther explanations , you reply would be "I know all this already." Don't be so quick to dismiss what people offer, because those are the answers to your questions

Cheers

[Ethlred]

No. If information got lost, it's just wrong. But I've said this already one, two times.

I don't that anyone claimed the information was lost in the video. The video is not SHOWING that information because the PLAYER is clipping it. The player is not showing the information that is outside the legal limits.

It does not matter that you think X264 should hold the data to the legal limits since it simply does not do that. YOU must convert the data from the present illegal form that has data greater than 236 to fit the legal limits. So you need to use a filter to fit the data to the legal limits. You can either decrease the brightness overall or you can compress the range, that is change the contrast or the gamma.

The basic problem is that you are starting with data that isn't legal for standard video. So have to make it fit somehow into the legal bounds. BEFORE encoding. Otherwise you will get variable results depending on how the decoders treat the illegal data.

I have never had this problem because all I do in video is convert my DVDs to MP4s. Since I always started with legal data I have never had to try to fit illegal data to the proper limits. So I don't know how you should go about doing that and it will depend on which program you use to encode. Every program has it's peculiarities.

Ethelred