|
|
| valja |
| Posted: Nov 25 2002, 10:41 PM |
 |
|
Advanced Member
Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02
|
Tried to optimise decoding with VDub 1.4.12 and noticed strange side-effect never seen before - for some frames bicubic (also precise bicubic) resize produces colored lines and dots on both left and rigth sides of the screen. Bilinear resize works well, with older versions also bicubic resize works well. Here examples:
Original:
Resized:
Note colored lines left and right.
Another resized:
Note colored line and dots on the right side.
What's wrong? |
|
| jcsston |
| Posted: Nov 26 2002, 03:06 AM |
|
|
Matroska Dev
Group: Moderators
Posts: 553
Member No.: 652
Joined: 3-November 02
|
I noticed that too. Must be a bug 
BTW Are you running a P4
--------------------
Use the Matroska file format |
|
| phaeron |
| Posted: Nov 26 2002, 04:06 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Argh....
I dropped a packuswb instruction from the MMX column resize core, causing the last pixel to be trashed. SSE2 codepath is not affected, although you can trigger it in the P4 build by disabling SSE2. Can be worked around by disabling MMX.
Will try to fix quickly.
|
|
| valja |
| Posted: Nov 26 2002, 05:42 AM |
|
|
Advanced Member
Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02
|
| QUOTE (jcsston @ Nov 26 2002, 06:06 AM) | | BTW Are you running a P4 |
This time no, it's a P2 (350MHz MMX).
@phaeron: Thanx for quick and clear explanation. |
|
| jcsston |
| Posted: Nov 26 2002, 06:01 AM |
|
|
Matroska Dev
Group: Moderators
Posts: 553
Member No.: 652
Joined: 3-November 02
|
I asked if you had a P4 because I thought the bug could have something to do with the new P4 enhancements.
This bug doesn't affect me much since I normally use AviSynth scripts for MPEG-2 decoding and I can resize there.
--------------------
Use the Matroska file format |
|
| jcsston |
| Posted: Nov 26 2002, 06:34 AM |
|
|
Matroska Dev
Group: Moderators
Posts: 553
Member No.: 652
Joined: 3-November 02
|
I just had a thought, the AviSynth resize would work in the YUV2 color space. But the VDub would convert the YUV2 to RGB and then resize in RGB.
Now which resize would have higher quality?
--------------------
Use the Matroska file format |
|
| Morsa |
| Posted: Nov 26 2002, 06:46 AM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
What I'm going to say is always applied to upsizing.
If you are going to downsize, it seems to me that there are no differences.
From what I´ve seen, resizing in RGB space gives you better results, although it is slower.
In fact if you could perform, before resizing , a little correction to both color layers ( as downsizing them to its actual size, then upsizing them with bicubic or Lanczos to the actual Luma size ) you could get far better results.
I've tested this some time ago and the results were amazing! |
|
| jcsston |
| Posted: Nov 26 2002, 07:04 AM |
|
|
Matroska Dev
Group: Moderators
Posts: 553
Member No.: 652
Joined: 3-November 02
|
That was a stupid question for me to ask.
The RGB would have a higher quality both ways.
YUV2 has 1 luma and 2 color channels with 1 color pixel in each channel for every 4 luma pixels (i think), if I resized down in the YUV2 space the color channels would still have a lower resolution than the luma. But in the RGB every pixel has the full range colors.
--------------------
Use the Matroska file format |
|
| Morsa |
| Posted: Nov 26 2002, 07:24 AM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
Exactly!!
Suppose you have a DV PAL source which color sampling is 4:2:0, if the source has a resolution of 640x480 and you downsample to 320x240 in RGB colorspace you'll get a better color sampling cause luma and color layers will have the same resolution: 320x240!! |
|
| valja |
| Posted: Nov 26 2002, 10:59 PM |
|
|
Advanced Member
Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02
|
| QUOTE (jcsston @ Nov 26 2002, 10:04 AM) | The RGB would have a higher quality both ways.
YUV2 has 1 luma and 2 color channels with 1 color pixel in each channel for every 4 luma pixels (i think), if I resized down in the YUV2 space the color channels would still have a lower resolution than the luma. But in the RGB every pixel has the full range colors. |
May be difference between RGB and YUV isn't very big. We have to remeber, that big part of every color information is inside luma channel. RGB shows three independent color levels, all counted from "black" level. Chroma channels shows difference from some grey level (luminance level) and in areas with low saturation this difference is small (most of R, G, B information is already inside luma channel). RGB may have advantage in case of contrast pictures with saturated colors (where difference from "gray" is big). IMHO RGB and YUV should be generally more or less equal.
There may be another reasons to use YUV space and frameserving by avisynth. Correct me if I'm wrong, but imho most(?) codecs are working in YUV space. Conversions YUV->RGB and back causes some (small) loss of information. A few consequtive conversions forth and back should show it clearly.
Cropping/resizing in avisynth allows to use VirtualDub "Fast recompress mode" and avoid these conversions YUV->RGB and back (RGB->YUV), also it works much quicker.
Finally have to admit, that I can't say, which way to prefer. I think it depends of film itself and editing made with film. |
|
| jcsston |
| Posted: Nov 27 2002, 12:38 AM |
|
|
Matroska Dev
Group: Moderators
Posts: 553
Member No.: 652
Joined: 3-November 02
|
In VDub evreything I process is recorded from TV Air or VHS (no DVD yet ), so I have to use noise reduction. I know AviSynth has noise reduction filters that work in YUV2 colorspace, but I like VDub's filters better  such as flaXen's VHS filter
--------------------
Use the Matroska file format |
|
| Morsa |
| Posted: Nov 27 2002, 01:34 AM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
I wasn´t talking about compression.
Believe RGB, if you're not going to compress, and you upsample your image 300% really makes a difference! |
|
| phaeron |
| Posted: Nov 27 2002, 03:12 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
It's true you can get better quality by filtering the chroma when upsampling, but you can trash chroma by a surprising amount and not have it be noticeable. MPEG-1 uses half-resolution for chroma, Indeo uses quarter resolution (88x60 for VCD-size!), and DV is quarter-res horizontally if NTSC. Lack of filtering on upsample is most noticeable in regions with deep red. Chroma upsampling is rather expensive and a hassle to code, incidentally.
The fact that a color conversion is lossy does not mean the losses will be cumulative over multiple conversions, or that the losses will significantly increase the variance in the signal. Also, that a codec works in YCbCr does not mean it uses the same colorspace as Avisynth. Motion JPEG is full-scale, not [16, 235] for Y, and MPEG-1 has chroma a half-pel off from UYVY/YUY2. RGB is well-defined in Windows, but YCbCr is not.
As for types of filtering, I have implemented Lanzcos3 in the resize filter while fixing it, and I have to say... the only difference I see from the cubic spline is that it runs slower. By the time you get out to the third node source pixels are contributing less than 1% of the total output energy and don't do a whole lot.
|
|
| Spire |
| Posted: Nov 27 2002, 09:07 AM |
|
|
Unregistered
|
| QUOTE (phaeron @ Nov 26 2002, 07:12 PM) | | The fact that a color conversion is lossy does not mean the losses will be cumulative over multiple conversions, or that the losses will significantly increase the variance in the signal. |
This reminds me: I recently made an alarming discovery related to this issue. Opening a Huffyuv-YUY2-compressed file in VirtualDub and then recompressing it back to to Huffyuv YUY2 (i.e., using Normal Recompress or Full Processing Mode) not only is lossy, but the loss is cumulative over multiple conversions! Each time this process is repeated, the picture degrades slightly (and the resulting .AVI file gets a little smaller, too).
After around five such recompressions, the degradation starts to become noticeable, and after 10 or so, it starts to become really bad.
I started to wonder just how bad it could really get. I created some test scripts to perform the recompression 10,000 times on a single video clip, and I found that after around 100-150 recompressions, things eventually stabilize, and the loss finally stops. However, by that time, the picture is so corrupted that the chroma is totally trashed and even the luminance is affected. If anybody is interested, I can post "before" and "after" frames here.
The question is, who's at fault here, Huffyuv or VirtualDub? When VirtualDub opens a Huffyuv YUY2 file, which one is doing the conversion to RGB24 -- VirtualDub or Huffyuv? Conversely, when saving back to Huffyuv YUY2, which one takes care of converting back?
If it's VirtualDub doing one conversion, and Huffyuv doing the other, then perhaps one or the other can be altered so that the cumulative loss can be prevented. If it's the same one doing both conversions (whether it be VirtualDub or Huffyuv), then it would seem to indicate a bug that should be addressed. |
|
| Morsa |
| Posted: Dec 8 2002, 06:13 PM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
I used Lanczos3 as an example. Just trying to say something better than nearest neighborhood.
Although with very big upsizings or when I supersample it gives me better results.
thread related
|
|
