|
|
| pathfinder |
 Posted: Oct 16 2002, 02:43 AM |
 |
|
Unregistered
|
Hello, everybody
I've been doing a black and white capture over a couple of days untill I noted a surprising thing - the file shows 24 bit depth! I wonder how many of those 24 bits are carrying usefull data after applying the grayscale filter in VD, and are the remaining bits actually waisted in the file if it's compressed with huffyuv or DivX (or they are never written there)? Also will those usefull bits be affected when I change the bit depth, say, to 16 bits?
Thanks a lot |
|
| phaeron |
| Posted: Oct 16 2002, 05:29 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
There is no specific 8-bit grayscale format -- you can do paletted 8-bit, but color palettes are an enormous pain and not too many programs bother with them anymore. VirtualDub will only read 8-bit paletted AVI files that have a single palette; it will not handle multiple palettes or capture a paletted file.
You need not worry about your compressed file, however. All modern codecs use a luma/chroma scheme for compression, so for your grayscale video the chroma axes will compress to nothing and the luma axis receives all the bits. You should compress your video as 24-bit, since 16-bit is 5/5/5 and will drop 3 bits per sample.
|
|
| fccHandler |
| Posted: Oct 16 2002, 05:46 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
(Hey phaeron, I was writing this when you posted; you beat me to it!  )
Huffyuv (being lossless) encodes all of the RGB bits. But DivX (and other MPEG codecs) convert RGB to YCbCr color space before compressing. In theory, this reduces your video to pure luminance (Y), and (Cb) and (Cr) reduce to zero. In practice, however, my own experience is that the compression ratio and/or quality is not very different from full color RGB. Why is that, I wonder?
--------------------
May the FOURCC be with you... |
|
| pathfinder |
| Posted: Oct 16 2002, 06:35 AM |
|
|
Unregistered
|
Hi, again
Thanks, Phaeron, a LOT. It's a relief to find out that DivX kills the unnecessary bits! Two days work of digitizing a movie series from a broadcast TV (no second tries X(8->) - original files deleted after processing and compression) were not totally wasted.
Though I set saturation to 0 in capture device settings, some chroma noise and oversaturated colors in commercials spill through the threshold. I use the grayscale filter to kill chroma noise. Just recently I noted that the TV filter has the Y (luma) option. I wonder does it differ from the grayscale filter on a YUV file? And which is better to use for a b&w movie?
Thanks again guys!!! |
|
| pathfinder |
| Posted: Oct 16 2002, 06:43 AM |
|
|
Unregistered
|
by the way, despite of the grayscale filter, after compression with DivX5 you can note some very faint green stains on the movie (not everywhere and not all the time). Does any one know why is that happening (a theory question)? |
|
| phaeron |
| Posted: Oct 16 2002, 06:45 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Remember that Huffyuv is essentially two codecs -- it has separate, although similar, compression algorithms for RGB and 4:2:2 YUV. (You can force it to convert RGB to YUV for better compression, but even with grayscale you will lose data since the full excursion for Y is [16, 235] and not [0,255].) I think there is a "decorrelate" function that essentially strips out the brightness component and then compresses [Y, R-Y, B-Y], but that still won't be totally effective as straight grayscale compression since the Huffman tables are tuned to accommodate some noise. This could be fixed by generating custom Huffman tables for each frame, but this would slow down our favorite capture codec.
As for DivX and grayscale, it's probably due to heavy chrominance subsampling. MPEG-1 runs at 4:2:0 (average 12 bits/pixel); Microsoft MPEG-4 squashes this all the way down to 4:1:0 (average 9 bits/pixel) and I suspect DivX does as well. In that case, you aren't removing much compressed chroma data to begin with, and the VLC tables for the format certainly aren't optimized for zero chroma as they are for natural chroma.
|
|
| phaeron |
| Posted: Oct 16 2002, 06:53 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The grayscale filter and TV filter's Y mode vary slightly in their coefficients. The grayscale filter is [R',G',B'] = 0.21R + 0.72G + 0.07B, while the TV filter is [R',G',B'] = 0.30R + 0.59G + 0.11B. No idea which one is better in general and I suspect in your case it doesn't matter. The TV filter is an artifact from when I thought it would be advantageous to process data in YIQ space, native NTSC encoding space; there isn't, so consider the filter deprecated.
As for the greenish hue in the compressed video, that may be indicative of a rounding or encoding error in the DivX codec -- one way a greenish tinge can result is a negative bias in the Cr and Cb values. Only the DivXNetworks guys could tell you for sure, however. MPEG coefficient decoding is tricky to do rapidly, and goofing up one tiny trick such as oddification can mess up your chroma without being noticeable except for extreme cases, such as a totally colorless input.
|
|
| fccHandler |
| Posted: Oct 16 2002, 07:39 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
The fix for the greenish hue might be an intermediate codec that would convert pure grayscale RGB (Red = Green = Blue) to pure grayscale YCbCr (Y = Red (or Green, or Blue), Cb = 0, Cr = 0), and pass that on to DivX.
...just a thought. 
--------------------
May the FOURCC be with you... |
|
| pathfinder |
| Posted: Oct 16 2002, 08:14 AM |
|
|
Unregistered
|
Thanks phaeron for the deapth in your comments
I am not an expert in MPEG algorithms, and so I don't quite get the implication of: [re: subsampling of chroma] "In that case, you aren't removing much compressed chroma data to begin with, and the VLC tables for the format certainly aren't optimized for zero chroma as they are for natural chroma." I just wonder what may happen if the stream being compressed contains 0 level "silence" in the U and V channels. What may get into the DivX file's U and V channels? Sterile scilence as well (or the encoding error)? Same for huffyuv? And how would DivX codec react to such a scilence during play back (add noise?)?
I ask those questions in reference to "one tiny trick such as oddification can mess up your chroma without being noticeable except for extreme cases, such as a totally colorless input." This is exactly my case - an old (1973) movie filmed on b&w film is broadcasted (in SECAM format). The only color wich the capture chip may see must be commercials and color noise of the broadcast and the tuner. The chip (by Nogatech) outputs in YUV 4:2:2. I wonder if it's better to just zero the U and V bytes through the whole captured file (stored in huffyuv), add other filters, temporarily recompress back to huffyuv and then compress it with DivX 2 pass mode.
If the idea to zero the U and V bytes may work. Then I wonder could it be done by just modifying the grayscale filter. The grayscale.asm has an IF branch and it looks like (I don't know assembler, but commets imply) the ELSE clause is processing the yuv format (though I wonder how that could be since the intro to the filter SDK states that all filters get an ARGB bitmap to process). Unfortunately, I can't read assembler, perhaps it already works this way (?)...
Thanks again for your help |
|
| pathfinder |
| Posted: Oct 16 2002, 08:23 AM |
|
|
Unregistered
|
Hey, fccHandler!!!
I think I just herd your thoughts while I was typing my lengthy reflections... The thing is I ALREADY have YUV stream. The Nogatech's chip and its decompressor driver outputs in YUV then it's compressed by huffyuv and then the file is opened and processed as YUV.
But phaeron's comment somehow gives food to thoughts that DivX behavior may not be strictly predicted towards 0s in U and V. I guess the "VLC tables for the format certainly aren't optimized for zero chroma as they are for natural chroma" may mean (though I don't know what's VLC) that they may not have a value for '0' chroma and this is why the greenish stain may be the lowest value for 0 chroma in the VLC table (I assume VLC table contains quantization values for each specific level in the signal).
|
|
| fccHandler |
| Posted: Oct 16 2002, 03:26 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
If you're processing the YUV stream through VirtualDub, Huffyuv is actually outputting RGB (VirtualDub's filters require this) and that is what is really being passed to DivX. If you choose "Fast recompress" it should pass the data on as YUV, but then you can't use VirtualDub's filters.
An alternative might be to use Avisynth to process the video, since it has filters that can operate in YUV space without converting to RGB. Don't know if it has a grayscale filter, though.
But even if you could ensure (or force) the zeroing of the chroma values in the YUV source, there's still no guarantee you'd get rid of the greenish hue, if phaeron is correct about it being due to error in the DivX codec. Oh well, I guess I've said enough about this.
--------------------
May the FOURCC be with you... |
|
| sh0dan |
| Posted: Oct 25 2002, 05:18 PM |
|
|
Avisynth Developer
Group: Vdubmod Alpha Testing Team
Posts: 41
Member No.: 327
Joined: 20-September 02
|
The greenish hue is most likely rounding errors in the RGB to YUV conversion.
Going back and forth between RGB (VDub) and YUV (AviSynth, DivX) is not completely lossless, so small rounding errors might occur.
You could try using AviSynth with a script like this | CODE | Avisource("file.avi")
converttoyuy2()
greyscale() |
And then use "Fast Recompress". This will deliver the data in YUV to the DivX codec with all color removed. |
|
| Neo Neko |
| Posted: Oct 25 2002, 07:02 PM |
|
|
VirtualdubMod Alpha tester
Group: Vdubmod Alpha Testing Team
Posts: 474
Member No.: 24
Joined: 11-July 02
|
Or the even simpler way is to get one of the newer stable compiles of Xvid with the greyscale encoding options and use them. |
|
| phaeron |
| Posted: Oct 26 2002, 02:31 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
RGB24/32<->YUV conversions should never produce colored pixels from grayscale input. The gray axis is well-defined in both colorspaces and any converter that tints images in that manner is not inaccurate but broken. The only case where this should occur is if you are using an RGB colorspace with an uneven bit distribution (16-bit 565).
|
|
