x264 transcode is lighter than original

[BabaG]

i'm trying to transcode video for blu-ray playback as art installations. for legal purposes i'll state up front that the material is all original. with some much appreciated help from the forum here i've gotten to the point where i can make x264 files that adobe encore accepts without the necessity of transcoding. the problem i'm having now, though, is that there are noticable differences in the x264 relative to the original. while it looks very good, the x264 appears noticably lighter than the master. here's what i've been doing to get to where things are now. i should state that i'm on a mac, btw.

1. start with uncompressed masters. these are made in final cut pro as uncompressed 10 bit 4:2:2 mov files
2. from these i use ffmbc to make proreshq 16x9 dupes also as mov files. i do this because encore seems to only accept the x264 without re-transcoding if it's in 16x9.
3. i use x264 in a virtual linux machine to transcode the proreshq to x264. apparently there is a mac or quicktime bug that precludes using osx from the x264 process.
4. in a nutshell: uncomp 10 bit 422 ---> proreshq 422 ---> x264

the commands i use to perform the x264 encode are here:
for i in *.mov; do /
x264 --bluray-compat --bitrate 22000 --preset veryslow --tune film --weightp 0 /
--bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 /
--fps 24000/1001 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" /
--transfer "bt709" --colormatrix "bt709" --sar 1:1 --ref 4 --qpmin 4 --pass 1 /
-o `basename $i .mov`.264 $i /
&& /
x264 --bluray-compat --bitrate 22000 --preset veryslow --tune film --weightp 0 /
--bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 /
--fps 24000/1001 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" /
--transfer "bt709" --colormatrix "bt709" --sar 1:1 --ref 4 --qpmin 4 --pass 2 /
-o `basename $i .mov`.264 $i; done

can i use x264 to adjust the brightness and contrast of the output?
would this be better done at an earlier step?

the uncompressed and proreshq appear very close in quality to the eye. it's the x264 that seems light. one thing i notice in the process is that i get a warning that 4:2:2 is being converted to 4:2:0 while running my x264 script and i'm guessing that this could be a major contributor to, if not the source, of the lightness issue. i'm anything but an engineer, here, so, while i'm very pleased with having gotten this far with all of this, i know i'm well out of my areas of expertise. any suggestions for a better workflow or ways to address the lightness issue are much appreciated. i can supply still frames for comparison if that seems necessary.

thanks,
BabaG

[Blue_MiSfit]

x264 does not mess with levels.

How are you reviewing your samples? Usually this is a playback issue, sometimes related to the decoder or renderer used.

[BabaG]

thanks for the reply, Blue_MiSfit.

generally, i think the encodes look pretty good. the artist i'm working with, though, noticed pretty much right off the bat that things looked 'light' overall. he said he was seeing things that he'd never been able to see in dark areas and that light areas looked too bright.

after that, i pulled matching still frames from each iteration: the uncomp master, the proreshq intermediate with pillars, the x264. the x264 is noticably, though, slightly, brighter than the others when all are placed side-by-side on a large monitor.

the first two i exported as tiffs from mpegstreamclip. the x264 was more complex as mpegstreamclip cannot open it. for that i had to wrap it in an mp4 and export from the quicktime player. since mpegstreamclip uses quicktime, i felt this was an ok process, given the constraints. i realize that this last step could involve some influence on the image but the fact that it still confirms something both intuitively and immediately noticed leads me to think that's not the case.

thanks for the help,
BabaG

[kieranrk]

Probably the old Quicktime gamma bug.

[BabaG]

i did some further testing using my stills and found that the lightness seems to be across the board. i read a grayscale test chart and the mid strip measured within a point or two for the uncompressed and proreshq, coming in at about 136 on a 0-255 scale. the x264 was about 15 points lighter, measuring between 149-155. the black and white strips were each also about 15 points higher than the original.

i use a program called xnviewmp sometimes for still adjustments and, using its level tool, i found that sliding the mid point from a value of 1.0 to .8 gave me values on the resulting file that came in very close to the original. not sure how that info might be applied to the making of the intermediate as, i'm guessing, the ffmbc filters probably use adifferent numbering and filtering system. it also seems odd to have to make an adjustment, probably at the intermediate step, in order to anticipate and compensate for something problematic happening later in the chain.

thanks again,
BabaG

[Blue_MiSfit]

Can you post a sample? I can basically guarantee that what you're viewing the stream with is behaving poorly. As kieranrk says, it's likely the old quicktime gamma bug :)

What happens if you look at the clips in VLC? It should handle uncompressed, prores, and h264 no problem.

[smok3]

It is a quicktime bug.

i use x264 in a virtual linux machine to transcode the proreshq to x264. apparently there is a mac or quicktime bug that precludes using osx from the x264 process.

Native osx ffmpeg with x264 built-in is working fine for me (on mountain lion).