PDA

View Full Version : Codecs not delivering accurate blacks



starbase1
11-17-2012, 01:54 AM
Has anyone else run into the problem of blacks in video sequences coming out lighter when you render a sequence out?

It's really driving me nuts, as it seriously spoils the result. Yesterday evening I tried every codec in turn, and the only ones that delivered a proper deep bloack in space scenes were uncompressed, and that produced files so large no-one else will ever get to see them...

I overlaid two frame grabs to show the problem, result attached.

Is there a codec that will deliver deep blacks, or settings on one that will address the issue?

Commercial codecs are acceptable as long as the price is not too painful, and the results can be played on most PC's without additional downloads.

Nick

Silkrooster
11-17-2012, 02:21 AM
Interesting, I haven't run across this issue yet. Or I should say, I haven't noticed it, maybe I need to do some checking...

- - - Updated - - -

Interesting, I haven't run across this issue yet. Or I should say, I haven't noticed it, maybe I need to do some checking...

Quick question: Is your monitor color calibrated? Some of the software takes advantage of color profiles, maybe it interfering?

starbase1
11-17-2012, 03:03 AM
No, not calibrated. I have used several video players though, and they all deliver the same result. (CVLC, Media player classic, GOM player...)
I couldn't find anything on this with a google search.

I've not checked if it also does this wth all scenes even with a little black, or just ones whee black dominates. but as I like doing space scenes it's a big issue for me!

nikfaulkner
11-17-2012, 04:02 AM
a lot of codecs use different gamma values (or colourspaces) annoying as hell i know :/

you're not saying what you are using them for, but here's what i use...

for editing and compositing i use photojpeg quicktimes at 100% quality (effectively a jpeg at 100% quality for each frame) these play full speed on pretty much any machine
if i need alpha channels i use quicktime with png codec, both quicktime and png are "virtually lossless" which means they are so close to being uncompressed in quality that
for 99% of people (me included) they are good enough.

if you want totally lossless use quicktime animation codec at 100% (works with alpha)

for delivery (youtube,vimeo,web, client) go with quicktime h264s although some people notice the gamma shift you mentioned. here's how to fix it
http://www.videocopilot.net/blog/2008/06/fix-quicktime-gamma-shift/

ive not used avi's for anything for years, all of the divx/xvid variants are so nonstandard that it quickly became a nightmare. the only codec i did use
was the free "huffy" codecs but this was for editing\post and not delivery. even with that i got burnt when i went back to an old project and couldnt
open any files as the latest updates of the codec broke backward compatibility.

since then quicktimes only for me

starbase1
11-17-2012, 07:23 AM
I'm trying to make a moderately good quality video that will download in a reasonable time.

I don't see how gamma is relevant - I thought that affected the response BETWEEN black and white, not the end points. And my sky (between the stars) is 0,0,0 100% black.

I understand that some codecs change colours, but I'd hope there was at least ONE that didn't change black to grey!

nikfaulkner
11-17-2012, 07:40 AM
quicktime h264, quality and size are amazing. check out the apple trailer site for quality examples.

re- the black level\gamma (or whatever it is) i've always assumed was to do with the different handling of the 16-235 luminance rule.

depending on codec, anything above 235 or below 16 (in rgb) can either get totally crushed, changing your contrast and mapping dark\light greys to black\white respectively.

or...

shift anything below 16 up, anything above 235 down making blacks grey and highlights darker

or(if you're lucky)

leave it alone entirely.

i'm not and expert in this but i think its something to do with the different colourspaces and handling of encoding\playback. the difference between 4:4:4, 4:2:2 etc
http://www.dvxuser.com/articles/colorspace/

SBowie
11-17-2012, 07:47 AM
Your XVid sample look more like it is set up for NTSC pedestal (black at IRE 7.5).

starbase1
11-17-2012, 08:04 AM
Thanks to help received elsewhere, I have fixed this - I'm sharing the result here in case anyone else hits it.

The nvidia driver imposes adjustments to video colour settings, independant of image setings, and so can the video player software, I started the nvidia controls, told it to take over settings, and dropped brightness by 5% to get fully dark blacks,

And the really nice thing was that you can have a video looping in the background, so you can see the impact as you tweak settings, so my end result is deep rich blacks with the faint stars still showing,

I attach the screen grab of the control panel in case anyone else finds it useful.

I've been suffereing with that for years!
Nick

djwaterman
11-17-2012, 09:30 AM
Quicktime h264, will look good in WMP, but played through quicktime then the blacks look washed out, but if you have quicktime pro you can just go into the video settings and set the
transparency to straight alpha, blacks become black, whites become white. If you send the QT H264 file off for broadcast it will be fine, even if you don't do this adjustment, but if you want to see it look nice in the quicktime and some other players, you need to do this.


http://i1210.photobucket.com/albums/cc401/djwaterman/Untitled-1.jpg

Sensei
11-17-2012, 10:37 PM
Black background in rendered image is not really black - there is added special noise when LW is converting from floating point channel to 8 bits per channel/32 bits per RGBA image formats.
You can control it in Effects window, Processing > Dither Intensity.
Try using Off and see again whether it is still visible.

starbase1
11-18-2012, 04:33 AM
I sampled colours from the image sequence to check, what goes in is 100% black.

dwburman
11-18-2012, 09:36 AM
Black background in rendered image is not really black - there is added special noise when LW is converting from floating point channel to 8 bits per channel/32 bits per RGBA image formats.
You can control it in Effects window, Processing > Dither Intensity.
Try using Off and see again whether it is still visible.

I think that dithering is off by default now (LW11).