Knowledge is power. Even if this article is not gonna be very long.

I was shocked to see that Adobe Première, a NLE that's been in development for 17 years and popular enough for the BBC to use it, messes up chroma channels in output where the input is progressive HDV. The internet is not soothing me; I cannot find people discussing similar difficulties. The goal of this third DV article is just to warn you, if you're a Première user, and to get some helpful input on this, if there's a walkaround. If you know more, please leave a message.

History:

Digital Video and the YUV Color Model
Digital Video: HDV and quality control

Première and the MPEG-2 Chroma Errors

Progressive HDV

The last two or tree years, HDV camcorder developers became intelligent and implemented the ability to record full progressive video on MiniDV tapes. As we all know, the MiniDV specification mandates that video is stored interlaced. Therefore, 25p video is stored as 25i on tape, by separating the progressive frame into two fields and storing those as separate fields. Hence the captured MPEG-2 TS has the interlaced flag set.

Many people don't know this. But it's done because, officially, 25p is not possible (or considered incompatible - whatever). Avid Xpress (afaik; didn't use the very latest version) doesn't even have an HDV Progressive project setting (and that sucks) because as far as they are concerned it does not exist. Since Adobe is more about what the market wants, and not about what HDV law sais, they do offer HDV progressive project settings. If you forget about this or if you use Avid Xpress, your transitions will be calculated as interlaced, resulting in unintentionally horizontally striped looking images, as if a junior student converted interlaced material for progressive playback.

With that said, the problem here is not gonna be affected by the choice of a progressive or interlaced HDV project.

MainConcept's MPEG field settings

I actually don't know where the problem arises. It seems that the MPEG-2 encoder's field setting has some influence on the output, but what about a format where you cannot set this option? What if you want to export a file sequence? Why would I want to do that? Because I prefer to archive my projects as MPEG-4.10/AVC AKA h.264. It's the single most advanced widely accepted codec out there (hence the abbreviation AVC for Advanced Video Codec). BUT only if you use a decent encoder, because the one (licensed) by Adobe produces a poor excuse for h.264. I prefer x264 in combination with . It's free software, and x264 has been declared best h.264 encoder in a row for 3 years. But, you know, whatever. It's your good right to want to export an image sequence, even if you don't have a good reason. So hell. Imagine you need that. Then you're screwed. Let me show you the problem.

So what's the chroma problem?

Testsubject

I have captured some footage from my dad in the garden. Imagine it being used in a progressive project. Check it out:



Nothing out of the ordinary, right?

Note that from now on, when I'm comparing actual pixels in that image, it will look squashed because I will leave the source pixels untouched and, you know, HDV is anamorphic 1440x1080 instead of square pixel 1920x1080.

Color comparison

Okay, imagine we export a tiff file sequence because we want the exact lossless sequence to tamper with. Maybe feed it to our home-made encoder or whatever the reason. There's not really much to tweak, except for choosing another format or resolution. Anyway check this out:



Looking reasonable, eh? The colors are slightly off in the exported (RGB) frame. That's because the ITU-R Recommendation BT.709, the standard for HDV, does not treat colors equally. Première undoes this transformation when outputting an RGB frame.

I am still not sure if this is good or bad. I don't care what looks better, I care whether the BT.709 tainted image is how it's supposed to look, or if it's just done because your screen does a better job at making it look like the untainted image that way. In the former case, I consider this bad. Just as bad as Première not letting you say if an imported sequence is already BT.709 tainted. Avid Xpress lets you define this.

Supers comparison - Première CS3 is NOT fine

At this point I want to take a minute and explain to you that the above comparison is not all there is to it. The YUV - RGB conversion errors mentioned in the previous DV article (HDV and quality control) are also a problem in Première CS3; even though Première works in YUV since Première became Première Pro, it still crops away the supers - both in RGB frame export as in YUV MPEG export.

See, in the previous comparison, I cropped the original capture to [16-235] to make them comparable. We know from the previous article that the HDV does in fact have data in superwhite, which is just thrown away. Let's see for ourselves. In the following comparison I cropped 180 to 0 for easy super watching.



With 1a being the original capture, you can see that the exported frame (1b) does in fact crop white to 255. If we take 1a and crop it to [16-235], we get approximately 1b, al be there some differences probably because luma is not the same as luminance (and I just sort of told you that Première converts luma back to luminance on RGB output).

"Cheater! You compare YUV input to RGB output!" I hear you say. Well my friend, I only did this to show that not even a frame sequence output is save from Première's cropping attitude. I compare YUV output for you in 2a - 2d.

Again we start with the original capture 2a. We export an MPEG-2 TS 2b, ready to be stored back on MiniDV. You can see that everything above 235 is held back! If we crop YUV white back to RGB white (235 -> 255) in 2c, it's suddenly equal to the cropped original frame 2d, which we used in the color comparison above (but ofcourse without the super exaggeration).

There you have it. Première is being very disappointing in this area.

That's why I want to use Avid Xpress for my product. My problem is that I want to do the offline montage in Première because I have a CS3 Master Collection license. I have access to Avid Xpress for the online montage, but that's not important at the moment. What if I want to render parts, do whatever, reimport them, go ballistic and then some. How can I bring my supers through this process? I really don't know. Please leave a message if you've got any hints on this.

-update- (June 18, 2008)

Lordtangent from hv20.com pointed out the Max Bit setting does in fact reïntroduce supers. After checking it out, enabling
Maxmimum Bit Depth does indeed bring them back when used in conjunction with a tool that tones down the brightness, such as ProcAmp or Curves. Unfortunately, this is a manual approximation. Precise tools like Levels work as 8 bits per channel effects and won't bring supers back. This will be great for montages to the eyeball, as long as you know you're not literally recreating the source footage and rounding errors will degrade the footage. To enhance eyeball-mode, right-click your display monitor and set the display mode to RGB Parade.

Here's a quick comparison to see what I mean:



So, good to know, but unfortunately an 8 bits per channel workflow doesn't just keep your data original. Because now your footage will be degraded (where, for example, Avid Express performs a direct stream copy from the source, if nothing was changed), and - more importantly - not even a core 2 duo can play this back fluently so you have to finish your comp in two steps, and switch back and forth annoyingly (and unnecescarily timeconsuming) when you got to alter the montage afterwards.

Still, if you want those supers, I created a curve preset that gets more or less the exact right value for HV20 footage. Here it is:
RED SuperWhite HV20.zip

You should use the 'exact' preset, unless you're not satisfied with a certain shot where a lot of focus is on the bright area.

Oh yeah, back to chroma

Remember that day where you was reading an article about chroma errors in Première? It probably showed a comparison between lossless export against the YUV footage used for that same export. Apart from colors tainted because of BT.709, all seemed fine. Ok, now check the very same images, compared when zoomed-in 200%. I've selected certain areas of contrasting chroma:



Please don't email me about how I confuse YUV with Y'CbCr. I am naming the colormodel, not the space!

I hope you noticed the problem, even though our eye is very insensitive to chrominance compared to luminance. Let me show the U and V components in grayscale to help you see the problem:



You see? It sure looks a lot like a wrong field order or something. Joke is: there is no field order for image output! There is no option whatsoever to fix this. Whether your HDV project is 25i (50i) or 25p, whether your bitdepth is 8 bit or maximum...

And you don't have to try starting a 25i HDV project with custom settings to force - against specification - the projects fieldorder to be bottom first. After all, it looks like internal field handling goes wrong. (Only the chroma part though, but who wouldn't try this, right?)

I tried that. No difference whatsoever.

There is no escape.



-update- (June 9 2008)

Using Photoshop in Lab mode, you can (sort of) edit U and V as a and b. Since chroma looked like a wrongly interlaced material, I tried manually swapping lines. I don't know if Première does mandatory de-interlacing of chroma or is assuming HDV to be 4:2:2 instead of 4:2:0 (would explain the lines, but would still be require interlacing), but (if I didn't get confused) it's fixed by swapping these lines in the chroma channels:

1,2,3,4 -> 1,3,2,4

I filed a bugreport to Adobe.

-update- (January 8, 2009)

2Bdecided from hv20.com suggests that Première indeed does mandatory chroma interlacing because HDV streams have their interlace flag set, but the finger of blame should be pointed at the Canon HV20 camera for not interlacing their chroma like they should according to the specs.

I tried mimicing the Première behavior by forcing chroma interlace decoding through AviSynth like so:But after this step I cannot extract a honest U or V channel for comparison. So all we can do is eyeball-compare the resulting image. And although this indeed introduces a chroma error, it appears it's not the same as Premières.




Back to Photoshop in Lab mode for manual figuring. The order of lines that made a good picture contradict what my eyes see in the RGB image, but still: To create a clean UV, swap (UV) line numbers like so:

1,2,3,4,5,6,7,8 -> 1,2,5,6,3,4,7,8

If this is correct, the cause of the error is a mix of both the HV20 and Premiere:

• HV20 writes progressive chroma fields in an MPEG stream that is flagged as interlaced.
  
• Première assumes the MPEG stream is 4:2:2 while HDV specs clearly say it's 4:2:0, resulting in a mess.
  

But to tell you the truth, I am not sure. I don't know exactly how 4:2:2 and 4:2:0 are stored and interpreted. But the fact is that Première swaps chroma lines, and AviSynth swaps pairs of chroma lines. What would you conclude? Don't hesitate to post your thoughts below.



Now let's check out how Première handles chroma in YUV (HDV/MPEG-2) export. See the next page.

Pagina's:
[1][2] Volgende pagina (2) >>