-
DVCproHD banding in FCP
I’ve noticed that when working with Varicam footage captured via firewire that when displayed in Final Cut Pro there is some banding, often visible in clear skies and other smooth gradients.
I have not noticed the effect as severely when playing back footage from the camera. I recently became more interested in this as a project that I shot was edited in FCP and re-captured for color timing via HDSDI to uncompressed 8 bit. Banding was much improved via this method.
So this got me to thinking about this and I’m guessing that there is something about the DVCproHD codec in FCP that is different than the Panasonic hardware codec built into the camera and capture decks.
And then I thought that maybe it is just the way FCP displays the DVCproHD data when playing back. But then, the banding is still there when rendering into other formats so it seems that it’s not just the display of the data, it’s the actual decompression of the data that is negatively effected by the FCP DVDproHD codec.
Has anyone else noticed the phenomenon? Any suggestions for the best workflow to deal with it?
Thanks!
-bruce
Varicam/Steadicam Owner
Los Angeles, CA
http://www.brucealangreene.com -
11 Replies
-
Bruce,
Perhaps it has something to do with the monitor you’re viewing on; a scaling issue. I would venture to say that DVCPRO100 is DVCPRO100 and when you import to FCP you’re bringing in data, not video and the codec in the NLE which converts it to picture is the same as the one in the camera. In addition of course, if you’re looking at HD-SDI output there is the Kona or Blackmagic card to also consider in the process.
The only problem I ever notice is occasionally getting black square dot artifacts. There’s no rhyme or reason as to when and where. They are easily removed by cloning them out or by duplicating a proceeding or following frame.
JS
-
[john sharaf] “Perhaps it has something to do with the monitor you’re viewing on; a scaling issue. I would venture to say that DVCPRO100 is DVCPRO100 and when you import to FCP you’re bringing in data, not video and the codec in the NLE which converts it to picture is the same as the one in the camera”
Hi John,
That’s what I used to think…now I’m not so sure. I don’t think it’s a scaling issue as I’m displaying fcp on a sony CRT computer display. I’ve even output still frames to photoshop and the banding is clear in the photoshop version as well. What I’m calling “banding” may well just be the compression blocking as viewed in a smooth gradient…
So, I’m really suspecting that the decompression in the FCP codec is less pleasing to look at that the hardware codec in the Panasonic equipment.
The one test I can’t do is to play a DVCproHD clip from fcp through a kona card and into my Panasonic 17″ HD monitor because I don’t have a kona card and will need to upgrade the whole computer to add one 🙁 I guess my thinking here is that the Kona card does the decompression rather than FCP. Does the Kona card work this way?
-bruce
Varicam/Steadicam Owner
Los Angeles, CA
http://www.brucealangreene.com -
Bruce,
I believe it does (make the conversion in the Kona card). For that matter, I’ve had better luck importing through the Kona card (HD-SDI) and letting it make the conversion to DVCPRO100 than by using the FW option, so for this and the need for HD-SDI output for critical viewing, I highly recommend adding it to your FCP system.
In addition I’ve also seen “suspected” problems (artifacts) shown to me as jpg’s that I believe were introduced by the codec in NLE’s such as the Avid and do not really exist in the original recording.
A lot of these issues still reside in the arena of two or more products of different manufacturers not “playing well together”. Even though the Varicam has now been with us for probably five years, we’re still pushing the envelope in terms of what we’re doing with it and the attempted workflows. I don’t believe these “problems” will ever end, and just as there’s always the problem of scratching and/or lab errors with film, there will probably always be similar artifact issues with multiple compressions and exhibition on screens and projectors of different formats.
One thing in particular, I’ve noticed lately, because more and more of our work finds itself on the web, is that the PC and Mac have different gammas, such that what looks good on a Mac, looks dark on a PC. This is exactly what I’m talking about in terms of playing well with each other; this is an inherent hardware difference (no gamma standard) which is not accounted for in the software that’s used to exhibit the product, and I see no solution, and very little discussion of this important matter.
JS
-
[john sharaf] “One thing in particular, I’ve noticed lately, because more and more of our work finds itself on the web, is that the PC and Mac have different gammas, such that what looks good on a Mac, looks dark on a PC. This is exactly what I’m talking about in terms of playing well with each other; this is an inherent hardware difference (no gamma standard) which is not accounted for in the software that’s used to exhibit the product, and I see no solution, and very little discussion of this important matter. “
John,
It’s not really a hardware issue, but a legacy of software preferences. Macs default out of the box to gamma 1.8, even though the display hardware is more close to native gamma 2.2. But it’s quite possible to set a mac gamma to 2.2 or anything else in the monitor control panel.
I’m on a mac and for a long time I had my monitor set to gamma 2.2 so that all the images on the web would look the proper gamma (at least more of the time). Photoshop is monitor gamma aware so that it doesn’t change the appearance of images in photoshop, but the web is a color free for all.
Then, I discovered that FCP and quicktime (for the mac at least) assumes that your monitor is set to gamma 1.8 to display video. Even though video color-space is really 2.2, quicktime converts it for play back at gamma 1.8. Since quicktime is an Apple product one would think that it would use color sync to check for the monitor gamma, but it does not.
The result is that on my website, all the still photos were made for gamma 2.2 when I thought that most viewers would be using windows (i.e.. pc’s at gamma 2.2) as well as my early video clips (I corrected them for viewing at gamma 2.2). Then, from looking at my website visitor log, I’ve noticed that 75% of visitors that view the videos use a mac, and assuming that they don’t change the display gamma from how it came, are viewing on gamma 1.8 displays.
So, now I’ve changed my monitor gamma back to 1.8 to use with FCP and quicktime and all my new video clips are corrected to look right at gamma 1.8…
It’s a goofy, goofy gamma world.
-bruce
Varicam/Steadicam Owner
Los Angeles, CA
http://www.brucealangreene.com -
[Bruce Alan Greene] “That’s what I used to think…now I’m not so sure. I don’t think it’s a scaling issue as I’m displaying fcp on a sony CRT computer display.”
Are you viewing camera playout on a computer display through a computer display card?
The only way to tell would be to take the content back to tape and to play it out of the camera on the monitor you’ve been using out of the camera.
I think if you could play it out to your video monitor via a video I/O card, it would probably be closer to what you expect. We have an FCP system here using CRTs as displays and I would say that I see banding relatively often compared to my PC system…but the video out through the AJA IO doesn’t usually have it in evidence nearly as overtly.
TimK,
Director, Consultant
Kolb Productions,Creative Cow Host,
Author/Trainer
http://www.focalpress.com
http://www.classondemand.net -
[Tim Kolb] ”
Are you viewing camera play-out on a computer display through a computer display card?The only way to tell would be to take the content back to tape and to play it out of the camera on the monitor you’ve been using out of the camera.
I think if you could play it out to your video monitor via a video I/O card, it would probably be closer to what you expect. We have an FCP system here using CRTs as displays and I would say that I see banding relatively often compared to my PC system…but the video out through the AJA IO doesn’t usually have it in evidence nearly as overtly. “
Thanks Tim,
Unfortunately, I don’t have an in/out card or a deck to record on.
That said, even if the i/o card can deliver a better decompression (and I believe you that it does) the important question is whether it is safe to do any rendering from the original data in FCP? I ask this because it looks to me that once FCP decompresses the DVCproHD, the banding is rendered into the product, even when rendering to an “uncompressed” codec. And if this is true, then the only way to preserve the true quality of the image is to re-capture all the footage via i/o card into an uncompressed codec for all color correction and rendering. That’s kind of a bummer…
-bruce
Varicam/Steadicam Owner
Los Angeles, CA
http://www.brucealangreene.com -
[bruce alan greene] “So, now I’ve changed my monitor gamma back to 1.8 to use with FCP and quicktime and all my new video clips are corrected to look right at gamma 1.8…”
NO NO NO….
sorry bruce, ALL video plays on systems and production monitoring at 2.2 this is not a good idea for projects you plan to release to others ( and it will be rejected by standards)On your banding Issue, yes there are known compression issues with the 8bit DVCPROHD native color space, especially when working with light color or pastel (high key) gradients, this issue is most notable with sky’s and in underwater environments. IT has nothing to do with FCP per se, but with the compression of the codec itself.
These are the area’s when the 8bit native codec just does not hold up and it becomes crucial to work in a true editor and capture the baseband video so that you can work in 10bit.
gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows
Inside look at the IoHD -
[bruce alan greene] “That said, even if the i/o card can deliver a better decompression (and I believe you that it does) the important question is whether it is safe to do any rendering from the original data in FCP? “
unless you are working in prores, all FCP renders retain the 8bit color space.\
” ask this because it looks to me that once FCP decompresses the DVCproHD, the banding is rendered into the product, even when rendering to an “uncompressed” codec.”
if the file is captured then converted into a 10bit space PRIOR to starting the edit, 99% of the time you can work with the footage without exacerbating the banding.
“And if this is true, then the only way to preserve the true quality of the image is to re-capture all the footage via i/o card into an uncompressed codec for all color correction and rendering. “
com’on bruce, t that has been the process for ages, its called an online.
while the Native 8bit DVCPROHD space is good enough for a very wide variety of subjects, it is known not to hold up well in all cases, and then it is best to use the proper tools for the
level of content you are planning on outputting, and that sounds like you should be working in 10bit for this project.gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows
Inside look at the IoHD -
[gary adcock] “[bruce alan greene] “So, now I’ve changed my monitor gamma back to 1.8 to use with FCP and quicktime and all my new video clips are corrected to look right at gamma 1.8…”
NO NO NO….
sorry bruce, ALL video plays on systems and production monitoring at 2.2 this is not a good idea for projects you plan to release to others ( and it will be rejected by standards)
“Gary, Gary, Gary…:)
I think you might misunderstand me. I’m talking about making quicktimes for viewing on the web here, no standards apply unfortunately. What I was saying is that when viewing 2.2 video in quicktime on the computer screen (not output through a card to a video/broadcast monitor) it looks closest in gamma to the broadcast monitor (output through a card) when the computer monitor is set to gamma 1.8.
And, when creating a quicktime file to be viewed on the web, I have decided to cater to most of my audience who are watching on a mac monitor left at the factory default of gamma 1.8. Hope this makes sense.
[gary adcock] “On your banding Issue, yes there are known compression issues with the 8bit DVCPROHD native color space, especially when working with light color or pastel (high key) gradients, this issue is most notable with sky’s and in underwater environments. IT has nothing to do with FCP per se, but with the compression of the codec itself. “
Agreed, however…I’m not convinced that FCP/quicktime decompresses the data in the same way that the Panasonic decks do. I would test this out, but I don’t have the all the equipment necessary to do so. I’m just a camera guy…not a post production supervisor.
[gary adcock] “These are the area’s when the 8bit native codec just does not hold up and it becomes crucial to work in a true editor and capture the baseband video so that you can work in 10bit. “
My point here was that since it is possible to capture the original compressed data from the camera, it would be nice if one could put the data (after editing) into a 10 bit timeline and do all renders at 10 bit—coming out to the same place as doing an online, albeit with a lot more render time.
It’s my guess, and this is where I need your expertise Gary, is that FCP is flawed in the way it decompresses from DVCproHD so that it locks the poor quality decompression into the file before color correction renders are performed in 10bit uncompressed for example. Of course this is purely my conjecture, not to be confused with fact.
-bruce
Varicam/Steadicam Owner
Los Angeles, CA
http://www.brucealangreene.com -
[bruce alan greene] “when creating a quicktime file to be viewed on the web, I have decided to cater to most of my audience who are watching on a mac monitor left at the factory default of gamma 1.8. Hope this makes sense.”
Careful, not all browsers deliver video the same way, safari, for instance will deliver 1.8 gamma to a mac but 2.2 gamma on a PC. firefox always wants to deliver 2.2 gamma video.
part of your issue could also be Compressor – it is not the best of the alternatives.[bruce alan greene] “it is possible to capture the original compressed data from the camera, it would be nice if one could put the data (after editing) into a 10 bit timeline and do all renders at 10 bit—coming out to the same place as doing an online, albeit with a lot more render time. “
the camera only captures 8bit. it does the 10bit convert out the HDSDI only-
[bruce alan greene] ” FCP is flawed in the way it decompresses from DVCproHD so that it locks the poor quality decompression into the file before color correction renders are performed in 10bit uncompressed for example.”
over FW it is nothing but a data transfer, it is in the renders that the color space fails, as a suggestion convert the timeline to ProRes after capture and before the edit. then you will have the best quality.
however that content is going to band once again at the compression stage, just to get the image small enough to send over the web.
I only use H.264 or WMV9 for web compression, nothing else seems to hold up as well.
gary adcock
Studio37
HD & Film Consultation
Post and Production Workflows
Inside look at the IoHD
Reply to this Discussion! Login or Sign Up