Red Vertical Banding in DVX100B - Does it need repair?

from phaeron, Virtualdub Developer @ http://forums.virtualdub.org/

"I didn't want to bother hooking up to DirectShow, so I wrote my own DV decoder for VirtualDub. The most likely reason for the discrepancy is that my decoder interpolates chroma, whereas apparently some commercial decoders don't. It's probable that the NLE programs you are using are all using the same codec that is installed on your system. Red is just about the worst situation here, btw.

I haven't tested it much, but I think the open source Lagarith codec also does a good job at interpolating chroma."
 
i just tried using this Lagarith lossless codec. Vegas and VDub handle it the same as they do their RGB uncompresed, ie. vegas blocking, Vdub not. BUT, it creates a file size about 1/5 of a normal RGB, so now rendering all my DV footage in Vdub to lagarith lossless before sending it to Vegas is a viable option ;) though not ideal.
looks like im guna have to find a way to change the DV decoder. FUN.
 
sorry about making 4 posts in a row here.

phaeron actually meant to say Cedocida codec, not Lagarith.
its an open source dv codec.
well i installed this and my issues with the colour red are a thing of the past.
can be found here:
http://neuron2.net/misc/cedocida017.zip

why oh why oh **/# why are the most expensive NLE's, built specifically to use DV, not incorporated with decent DV codecs!!!!!!!!!!!!!!!!!!

egh. so much for the 'avoid reds' 'blame all dv codecs' 'add blur' 'blame colour spacing' excuses which, as far as i can tell, are the only ones on offer at this forum.

hope ive been a help.
 
kill_me_killroy said:
egh. so much for the 'avoid reds' 'blame all dv codecs' 'add blur' 'blame colour spacing' excuses which, as far as i can tell, are the only ones on offer at this forum.

hope ive been a help.
Click to expand...

Listen, it's important to understand the technology. There are limits to the colorspace. People starting out with DV need to learn what to expect when they capture from their camera.

If this codec, or some other DV codec is doing some smoothing or other chroma reconstruction, then that's fine, but realize that it is manipulating the image and may have unintended consequences to image quality. A codec that automatically smoothes and is not configurable can be problematic, such as some of the earlier codecs that had horrible recompression.

In the end it's best to understand how the codec you are using operates. I'd look into what method your codec is using, so it doesn't bite you in future.

Personally, I am currently using the DV Rebel's Color Median technique to smooth color, and saving as uncompressed AVI. I've got the time and storgae to pull it off for most of my projects, but it's not for everyone.
 
yes there are limits to colour space compression and DVs algorithms. these limits are demonstrated by the results from vdub's dv decoder and the cedocida dv decoder, which have rough edges and slight blocking on all colours- a by product of colour space compression on dv codecs and near enough all other lossy video codecs.
Then on the other hand there are badly built decoders, such as vegas, windows, panasonic, that aswell as having the issues as above also turn your red pixels into big blocks of 2x2 reds. maybe this is only an issue when these decoders deal with pal dv. maybe when dealing with ntsc dv it has issues with 4x1 red blocks, or maybe when they built the decoders they built them properly for ntsc colour space and not pal coulor space. But I know for me, they are doing it wrong. Also the vegas dv decoder brightens the image considerably as well as screwing reds up.

And the decoders that are doing it right are not adding blurs, smoothers, filters of any kind, or even magic, just reading all the information that is in the file, decoding it and displaying it.

you are right to point out the need to test for generation loss (though not because of some filter application) with this codec, it may be a good decoder but is a good encoder, for me though it is a mute point; why not output to RGB uncompressed, or now even Lagarith lossless codec, for further steps in image manipulation. But even then i would rather have the ability to read reds properly over the ability to compress the dv file to dv a bunch of times. and im not suggesting here that this codec would be worse than any other in that respect, im just saying i havnt tested it and if it does, so what? Atleast you get your image right to start with. besides which, it being an open source project means that it will be thoroughly tested by users and regularly updated, perhaps it is this difference that means it is getting the image right and the other commercial dv decoders have got it wrong.
 
Last edited:
kill_me_killroy said:
Then on the other hand there are badly built decoders, such as vegas, windows, panasonic, that aswell as having the issues as above also turn your red pixels into big blocks of 2x2 reds. maybe this is only an issue when these decoders deal with pal dv. maybe when dealing with ntsc dv it has issues with 4x1 red blocks, or maybe when they built the decoders they built them properly for ntsc colour space and not pal coulor space. But I know for me, they are doing it wrong. Also the vegas dv decoder brightens the image considerably as well as screwing reds up.

And the decoders that are doing it right are not adding blurs, smoothers, filters of any kind, or even magic, just reading all the information that is in the file, decoding it and displaying it.
Click to expand...

Actually, it is quite the opposite of what you say.

It is the decoder that show you 2x2 blocks for PAL and 4x1 blocks for NTSC that is most accurate. In PAL, the Cr and Cb color channels are only 360x278 resolution. In NTSC, 180x480. That is what is recorded to tape. Not a lot of color information. When displayed at the full resolution, it's blocky.

A codec that doesn't show this type of blockiness is not "reading all the information in the file, dcoding it and display it." Rather, it is doing some type of interpolation, deartifacting, smoothing, etc. to give you a smoother image.

I'm not arguing that the image doesn't look better in your examples, it does. It's just not recorded to tape like that, it's your codec that is creating that image.
 
You must log in or register to reply here.
Back
Top