Converted Videos look Washed Out

[budwzr]

In your camera, you should activate highlight tone priority, that will block ISO100 and force you to use shutter speed and/or aperture to set the exposure.

Then you might want to set the recording levels to neutral, then adjust up or down as needed to get the best dynamic range for the given scene.

The best exposure will look uniformly even, or flat, lacking contrast, but every pixel will have information that can be teased out in post.

[Track]

In your camera, you should activate highlight tone priority, that will block ISO100 and force you to use shutter speed and/or aperture to set the exposure.

Then you might want to set the recording levels to neutral, then adjust up or down as needed to get the best dynamic range for the given scene.

The best exposure will look uniformly even, or flat, lacking contrast, but every pixel will have information that can be teased out in post.

I'll keep that in mind for future projects.

But what about the videos at hand? How do I maintain the luma while reducing file size?

[jagabo]

But what about the videos at hand? How do I maintain the luma while reducing file size?

Use Xvid4PSP. It ignored the full range luma flag.

[Selur]

for general amusement, I just made a small script to see the difference between the different ColorMatrix and ConvertToRGB calls in avisynth:

LoadPlugin("G:\avisynthPlugins\ColorMatrix.dll")
LoadPlugin("G:\avisynthPlugins\DGDecodeNV.dll")
# loading source
v = DGSource(dgi="H:\Temp\222519718mov_deb1536f480475f7d593219aa1afd74c_41.dgi",fieldop=0) # another source filter could be used
v = v.trim(580,620)
v = v.BicubicResize(v.width/4,v.height/4)
a = v.ColorMatrix(mode="SMPTE 240M->Rec.601",clamp=3,interlaced=false).Subtitle("SMPTE 240M->Rec.601", align=5)
b = v.ColorMatrix(mode="Rec.709->Rec.601",clamp=3,interlaced=false).Subtitle("Rec.709->Rec.601", align=5)
c = v.ColorMatrix(mode="FCC->Rec.601",clamp=3,interlaced=false).Subtitle("FCC->Rec.601", align=5)
d = v.ColorMatrix(mode="SMPTE 240M->Rec.709",clamp=3,interlaced=false).Subtitle("SMPTE 240M->Rec.709", align=5)
e = v.ColorMatrix(mode="Rec.601->Rec.709",clamp=3,interlaced=false).Subtitle("Rec.601->Rec.709", align=5)
f = v.ColorMatrix(mode="FCC->Rec.709",clamp=3,interlaced=false).Subtitle("FCC->Rec.709", align=5)
g = v.ColorMatrix(mode="SMPTE 240M->FCC",clamp=3,interlaced=false).Subtitle("SMPTE 240M->FCC", align=5)
h = v.ColorMatrix(mode="Rec.601->FCC",clamp=3,interlaced=false).Subtitle("Rec.601->FCC", align=5)
i = v.ColorMatrix(mode="Rec.709->FCC",clamp=3,interlaced=false).Subtitle("Rec.709->FCC", align=5)
j = v.ColorMatrix(mode="FCC->SMPTE 240M",clamp=3,interlaced=false).Subtitle("FCC->SMPTE 240M", align=5)
k = v.ColorMatrix(mode="Rec.601->SMPTE 240M",clamp=3,interlaced=false).Subtitle("Rec.601->SMPTE 240M", align=5)
l = v.ColorMatrix(mode="Rec.709->SMPTE 240M",clamp=3,interlaced=false).Subtitle("Rec.709->SMPTE 240M", align=5)
m = v.ConvertToRGB("PC.601").ConvertToYv12().Subtitle("ConvertToRGB(PC.601)", align=5)
n = v.ConvertToRGB("PC.709").ConvertToYv12().Subtitle("ConvertToRGB(PC.709)", align=5)
o = v.ConvertToRGB("AVERAGE").ConvertToYv12().Subtitle("ConvertToRGB(AVERAGE)", align=5)

p = StackHorizontal(a, StackHorizontal(b, StackHorizontal(c, d)))
q = StackHorizontal(e, StackHorizontal(f, StackHorizontal(g, h)))
r = StackHorizontal(j, StackHorizontal(j, StackHorizontal(k, l)))
s = StackHorizontal(m, StackHorizontal(n, StackHorizontal(o, v)))
StackVertical(p, StackVertical(q, StackVertical(r,s)))

I also made a screenshot of the result and attached it.

[jagabo]

I'm pretty sure PC.709 is the correct conversion.

[Selur]

Yup, only thing that surprised me: shouldn't one of the ColorMatrix conversion also produce the correct conversion?

[jagabo]

shouldn't one of the ColorMatrix conversion also produce the correct conversion?

No. Because the none of the ColorMatrix conversions compresses the luma levels from 0-255 to 16-235. And you set clamp=3 so the source was clamped* to 16-235 before (and after) conversion, losing all the super darks and super brights. Before (left) and after (right) ColorMatrix(mode="Rec.709->Rec.601",clamp=3):



Notice how the top and bottoms of the graph are truncated on the right. But everything in the middle is the same.

Finally, whatever software you used to to convert YUV to RGB for display assumed normal 16-235 levels and stretched them to RGB 0-255. So even if you had used clamp=0 that final conversion to RGB would have crushed the super darks and super brights.

* Clamped may not be a good word to describe what's going on. Truncated or squashed is probably more accurate. All values below 16 become 16. All values above 235 become 235.

[Track]

Guys, this is far, far beyond my understanding level

[Selur]

@jagabo: doh, totally overlooked the clamp

[jagabo]

Guys, this is far, far beyond my understanding level

Most video formats store video using a YUV colorspace. Like RGB, YUV uses three channels to represent pixles. Y is the luma component, a grayscale picture, much like you see on an old black and white TV. U and V are the chroma (color) components. They represent colors that are added or subtracted from the grayscale image to produce the final color image. This originates in color TV broadcasts where they wanted to retain a signal that was compatible with existing black and white TVs (the luma signal) and transmit color information on a side channel.

Most acquisition and display devices (and your eyes) work in RGB. So RGB has to be converted to YUV on acquisition, and converted back to RGB for display. There are many minor variations in the way this is done, hence the rec.601, rec.709, FCC, SMPTE 470M, etc. nomenclature. But in almost all the systems the 8 bit luma (Y) is defined such that a value of 16 represents full black and 235 represents full white. Values below 16 and above 235 leave a little headroom for noise and occasional overshoots (as you get for example with sharpening filters used when capturing analog video). But Y values below 16 will not render darker than Y=16, and Y values over 235 will no render brighter than Y=235. In practice this may not be true, depending on the way particular devices are set up. But by definition full black is Y=16, full white is Y=235, and you should not count on values below 16 being any darker than 16, or values above 235 being any brighter than 235.

8 bit (per channel) Computer monitors use the full 0 to 255 range, with RGB=0 to represent full black, RGB=255 to represent full white. So when converting RGB to YUV it is customary to compress the 0 to 255 RGB range to the 16 to 235 Y range. Conversely, when converting Y to RGB the 16 to 235 Y range is expanded to 0 to 255 RGB.

Your camera is unusual in that it uses the full 0 to 255 range for the luma component. That means it requires specific handling for the picture to have the right black and bright levels when viewed as RGB. Handbrake is doing the correct thing when it converts your sources to "standard" h.264 -- it compresses the luma 0-255 range to 16-235. If you don't like that then you need to use special handling that isn't available in Handbrake (as far as I know, I don't use the program much). You could use Xvid4PSP which appears to ignore whatever it is in the MP4 header that indicates full range Y instead of the normal range Y.