H.264 Brightness / Contrast issue...

[Curtis Bouvier]

Using Adobe Premier Pro 2.0, having a slight problem with H.264 codec..

It doesn't matter what I save, whether it's a picture or a video, the compression seems to remove alot of brightness and contrast from my work, and there doesn't seem to be a way of correcting this issue, since there is no configuration menue.. other than a quality slider that goes from 0% -100% (doesn't make a difference what percent I use)

If I save at BMP, or PNG, or JPEG or etc, they dont lose any contrast / brightness, but the file is 10X larger.

Any one have any idea's as to what the problem is with H264?

Here is a screenshot showing exactly what I mean:

http://img95.imageshack.us/img95/2057/h264wrongcg5.jpg

[Zack Vohaska]

I was going to ask this question eventually myself -- I'm having the same problems you are with the H.264 codec.

I tried exporting directly to the H.264 codec -- washed-out image (brightness/contrast issue). I exported to an uncompressed AVI file, then tried converting it directly from QT7 to an H.264 file to see if it'd make a difference, but no - still washed out.

Anyone have an idea?

[Christopher Lefchik]

I've noticed the same phenomenon. There is a definite boost in image brightness. Interestingly, playing the same H.264 file in VLC media player yields a picture darker, much richer picture. By default VLC media player uses hardware acceleration (the computer's graphics card) to render the video image. If I deselect that option, the picture in VLC media player looks just like the one in the QuickTime Player.

As if that wasn't confusing enough, playing a DV AVI file in both QuickTime and VLC media player yields an identical image, even though VLC media player is using hardware acceleration.

[Zack Vohaska]

Chris,

I just played one of my H.264-encoded .mov files through VLC player and you're right -- the image plays as how it was rendered uncompressed from my NLE.

Now I'm more confused than ever as to what's causing the brightness boost when viewing the file through the QT7 player. The HD trailers on the Apple site look great! Obviously they're probably using much more advanced H.264 encoding software, but still, one shoot be able to tweak such a simple change. :-/

[Greg Boston]

Originally Posted by Zack Vohaska

Chris,

I just played one of my H.264-encoded .mov files through VLC player and you're right -- the image plays as how it was rendered uncompressed from my NLE.

Now I'm more confused than ever as to what's causing the brightness boost when viewing the file through the QT7 player. The HD trailers on the Apple site look great! Obviously they're probably using much more advanced H.264 encoding software, but still, one shoot be able to tweak such a simple change. :-/

It may have to do with gamma. One of the nice things about MPEG4 is that it allows the gamma correction to be imbedded into the file so it should play fine on PC or Mac. I know you guys aren't talking about cross platform here, but I still think gamma can be involved somehow. I just haven't figured out how.

-gb-

[Christopher Lefchik]

EDIT: Scratch the last line in my previous post. I didn't notice that I had a VLC settings dialog open and hadn't saved the settings back to using hardware acceleration. Once that was done, the DV AVI did play darker in VLC media player, compared to the QuickTime Player.

I tried playing an Apple HD H.264 trailer in both QuickTime Player and VLC media player. Just like with my own H.264 video, the picture was darker in VLC media player.

So, with hardware acceleration enabled VLC media player renders a darker image than QuickTime on both H.264 video and DV AVI files. With it disabled the video is rendered lighter, like QuickTime Player renders those files.

[Glenn Chan]

I believe Quicktime can do things to account for Mac VS PC gamma.

2- There is also a gamma difference between:
Rec. 601 video (SD)
sRGB, for computer monitors and digital still cameras.

Quicktime does do things to account for this... i.e. when importing and exporting stills into FCP, FCP will change the gamma of the image.

[Greg Boston]

Originally Posted by Glenn Chan

I believe Quicktime can do things to account for Mac VS PC gamma.

2- There is also a gamma difference between:
Rec. 601 video (SD)
sRGB, for computer monitors and digital still cameras.

Quicktime does do things to account for this... i.e. when importing and exporting stills into FCP, FCP will change the gamma of the image.

I know that MPEG4 can do this. It is referenced in one of my FCP manuals concerning output. Just not sure that all H.264 encoders can do this.

MAC gamma runs 1.0 while PC Gamma runs 2.2 (which is the same as many television CRTs).

-gb-

[Eric Gorski]

i have noticed the same thing. it sux.

[Glenn Chan]

On Macs, the gamma is 1.8.

The gamma of a television: There are many figures for this. The NTSC standard was developed with the assumption that CRTs followed a gamma of 2.2.

If you fit measured data to the following formula:

Output = (input + black level error) ^ something

Gamma would be about 2.4. (According to Charles Poynton; his gamma FAQ is outdated in this regard.) Even that is an oversimplification however.

Another answer, with first-hand measurements:
http://www.nightscapes.net/technique...asDisguise.pdf

[Christopher Lefchik]

I’ve done some more research on this problem. Apparently, the issue is caused by hardware acceleration, in particular Core Video on the Mac and DirectX DirectDraw on the PC. Somehow this must be tied in with QuickTime’s rendering of H.264 embedded ICC profiles.

I confirmed the problem is related to hardware acceleration by opening in QuickTime Player 7.2 an H.264 video I encoded, and playing it with and without DirectX acceleration. See attached screen shots at the end of this post.

Visit these links for more information:

Quicktime Player h.264 Bug
Update and comments
RE: Core Video/ H.264 Color issues

To quote a Robert Spryn from the second link:

“I spoke to one quicktime engineer. All I got out of it is that this is a problem they are aware of and working on, and that detailed information on the problem like I provide is helpful.”

This comment was posted on June 26 of this year.

To sum things up, nothing is inherently wrong with the H.264 format; it is QuickTime Player’s handling of the embedded ICC profiles that is at fault. Thus, I would strongly urge against doing anything like increasing saturation or decreasing the brightness of your project in an attempt to correct for this problem when exporting to H.264. If and when Apple fixes this issue regarding ICC profiles and hardware acceleration in the QuickTime Player, any H.264 videos so corrected could end up being rendered rather, well, interesting.

Regarding the screen shots below, in each of the two the QuickTime window on the left is being rendered with DirectX hardware acceleration, and the window on the right with Windows GDI.

[Chris Barcellos]

Christopher:

Nice job of digging this out !!! I thought there was something we were doing wrong.

[Zack Vohaska]

Originally Posted by Christopher Lefchik

I’ve done some more research on this problem. Apparently, the issue is caused by hardware acceleration, in particular Core Video on the Mac and DirectX DirectDraw on the PC. Somehow this must be tied in with QuickTime’s rendering of H.264 embedded ICC profiles.

I confirmed the problem is related to hardware acceleration by opening in QuickTime Player 7.2 an H.264 video I encoded, and playing it with and without DirectX acceleration. See attached screen shots at the end of this post.

Visit these links for more information:

Quicktime Player h.264 Bug
Update and comments
RE: Core Video/ H.264 Color issues

To quote a Robert Spryn from the second link:

“I spoke to one quicktime engineer. All I got out of it is that this is a problem they are aware of and working on, and that detailed information on the problem like I provide is helpful.”

This comment was posted on June 26 of this year.

To sum things up, nothing is inherently wrong with the H.264 format; it is QuickTime Player’s handling of the embedded ICC profiles that is at fault. Thus, I would strongly urge against doing anything like increasing saturation or decreasing the brightness of your project in an attempt to correct for this problem when exporting to H.264. If and when Apple fixes this issue regarding ICC profiles and hardware acceleration in the QuickTime Player, any H.264 videos so corrected could end up being rendered rather, well, interesting.

Regarding the screen shots below, in each of the two the QuickTime window on the left is being rendered with DirectX hardware acceleration, and the window on the right with Windows GDI.

Yes, thank you! I was thinking about doing something crazy like increasing the saturation, haha. Glad to know that the QuickTime development team is aware of the issue and is working on it. :)

[Eric Gorski]

is there a good alternative to H.264 for encoding highquality/lowsize quicktimes?

[Christopher Lefchik]

As far as I know, the Sorenson Pro codec is the only codec that is equal to or better than H.264.