YUY2 vs RGB24 vs Y800

[jagabo]

1. I tried your alternate way and created RGB uncompressed. When I tried to run it through the Debayer filter I got the message that "input to filter must be YV12"

Add ConvertToYV12() right after AviSource():

AviSource("RGB.AVI")
ConvertToYV12()
FlipVertical()
FlipHorizontal()
DebayerFilter(swap=0)
FlipHorizontal()

2. Tried original method with actual Y800 capture .avi with dimension of 392 x 288. Error message "image pitch and width doesn't match"

I couldn't reproduce that error message. But it looks like the debayer filter requires a mod 32 frame size (integer multiple of 32) to work properly. You would either have to add 24 or subtract 8 from the 392 pixel width with AddBorders(0,0,24,0) or Crop(0,0,-8,-0). If you AddBorders() you can crop that border away after debayering:

AviSource("Y800.avi") #392x288 video
ConvertToYV12() #if necessary
AddBorders(0,0,24,0)
FlipVertical()
FlipHorizontal()
DebayerFilter(swap=0)
FlipHorizontal()
Crop(0,0,-24,0)

Gavino mentioned this earlier in this thread:

"At the end of the thread, there is a different plugin which does have source code.
(See http://forum.doom9.org/showthread.ph...52#post1108152.)
It gives you the choice of either bilinear or nearest neighbour interpolation - for a description of the parameters, see the top of source file demosaic.cpp."

Is there any way to use this filter. I tried but failed. I just don't know enough about writing the script....

You have to explicitly load the plugin at the start of the clip. Starting with his sample script:

LoadCPlugin("C:\Program Files\AviSynth 2.5\plugins\demosaic.dll")

ImageSource("image.jpg")
ConvertToYV12()
Demosaic(xoffset = 1, yoffset = 0, method = "bilinear")
RGBAdjust(r=1.0, g=1.1, b=1.8, a=1.0, rb=0.0, gb=0.0, bb=0.0, ab=0.0, rg=1.00, gg=1.00, bg=1.00, ag=1.00, analyze=false)

The script for your Y800.AVI:

LoadCPlugin("C:\Program Files\AviSynth 2.5\plugins\demosaic.dll")

AviSource("Y800.avi")
Demosaic(xoffset = 1, yoffset = 1, method = "bilinear")
#RGBAdjust(r=1.0, g=1.1, b=1.8, a=1.0, rb=0.0, gb=0.0, bb=0.0, ab=0.0, rg=1.00, gg=1.00, bg=1.00, ag=1.00, analyze=false)

Bilinear or Nearest Neighbor is slightly inferior to what the DeBayer() filter does. On the other hand Demosaic() gives you the ability to specify where the subpixels are located and doesn't require mod 32 frame sizes. The color adjustment he does after debayering appears to be correct(ish) for his sample image but adds a very blue cast to your Y800 video. I disabled the color adjustment in the above script to match the colors DeBayer() is delivering.

[Gavino]

2. Tried original method with actual Y800 capture .avi with dimension of 392 x 288. Error message "image pitch and width doesn't match"

I couldn't reproduce that error message. But it looks like the debayer filter requires a mod 32 frame size (integer multiple of 32) to work properly. You would either have to add 24 or subtract 8 from the 392 pixel width with AddBorders(0,0,24,0) or Crop(0,0,-8,-0).

I don't think Crop(0,0,-8,-0) will work for this problem because by default Crop() leaves the pitch unchanged. You would need to use Crop(0,0,-8,-0, align=true).

Edit: In fact, to make it work with Crop you would have to crop off the left hand side (to change the starting alignment), as well as using align=true (to force a copy to a newly aligned frame):
Crop(8,0,0,0, align=true)
But as you say, AddBorders is a better approach anyway as (unlike a crop) it can be reversed after the debayering.

[201flyer]

Gavino and Jugabo,

Thank you so much for all this information. It will take me a while to digest it and experiment, which I will!

In the meantime, and for the sake of completeness in this thread on Y800, 2 additional ways to DeBayer have emerged from discussions elsewhere.

1. There is an excellent DeBayering filter available for VirtualDub. http://www.inf.ethz.ch/personal/lballan/demo.html
Very simple to use and gives excellent results.
The VirtualDub plugin supposedly uses a very advanced algorithm (Demosaicing with Directional Filtering and a Posteriori Decision), see http://www.danielemenon.netsons.org/pub/dfapd/dfapd.php.

2. A new tool (stand alone) as part of a freeware astronomy image capture program called Firecapture: http://firecapture.wonderplanets.de/help/debayer.html

The Debayer Tool is located in the program folder. It's quite interesting in that it allows the selection of several different DeBayering methods. My experiments thus far are very favorable towards "AdaptiveSmoothHue."

[Gavino]

The VirtualDub plugin supposedly uses a very advanced algorithm (Demosaicing with Directional Filtering and a Posteriori Decision), see http://www.danielemenon.netsons.org/pub/dfapd/dfapd.php.

That's the same method mentioned by the author of the Avisynth DebayerFilter plugin (although it's not 100% clear that the final implementation uses it since there is no source code). Since one of the authors of the VirtualDub plugin (Daniele Menon) is also a co-author of the original algorithm, you can have more confidence in that implementation.

Note in passing that VirtualDub plugins can be used in an Avisynth script, using LoadVirtualDubPlugin().

[jagabo]

1. There is an excellent DeBayering filter available for VirtualDub. http://www.inf.ethz.ch/personal/lballan/demo.html

That one seems to work better than the others.

[Gavino]

Revisiting this, does the issue of 'TV' v 'PC' levels come into play at any stage?
I presume the raw sensor output is 0-255 - is that what is recorded in the Y800 file?
When VirtualDub converts Y800 to RGB, does it assume the input is 16-235 (as it would for YUY2 or YV12), or does it treat it specially as 0-255?
The issue also arises when opening the Y800 file in Avisynth. If the source filter or codec delivers RGB, it is important that the conversion is done correctly. Similarly, any YUV<->RGB conversions in the script itself may need to be done with a 'PC' matrix rather than the default 'TV' one.

[jagabo]

Revisiting this, does the issue of 'TV' v 'PC' levels come into play at any stage?
I presume the raw sensor output is 0-255 - is that what is recorded in the Y800 file?

As far as I can tell, yes. The sensor is RGB.

When VirtualDub converts Y800 to RGB, does it assume the input is 16-235 (as it would for YUY2 or YV12), or does it treat it specially as 0-255?

The "Y" plane is raw RGB values, not YUV luma. The Debayer filter simply fills in the holes.

But you're right, the ConvertToYV12() in the earlier AVS scripts might need to be changed to ConvertToYV12(matrix="PC.601") or ConvertToYV12(matrix="PC.709") to keep from compressing the contrast. I didn't notice how the AviSynth debayer filters handled the colorspace.

[Gavino]

The "Y" plane is raw RGB values, not YUV luma. The Debayer filter simply fills in the holes.

You and I know that, but does VirtualDub know?
I was referring to using VirtualDub to convert Y800 to RGB prior to Debayering:

By the way, you can convert the Y800 image to uncompressed RGB simply by opening it in VirtualDub and saving as uncompressed RGB. That will be easy to open in AviSynth with AviSource and won't require ffdshow (VirtualDub has a built in Y800 handler).

This seems to be the method 201flyer used in the end to avoid problems opening Y800 in Avisynth.
Does this conversion conserve the full input range?

[jagabo]

The "Y" plane is raw RGB values, not YUV luma. The Debayer filter simply fills in the holes.

You and I know that, but does VirtualDub know?

It looks like you're right. Experimentally, VirtualDub is handling the Y800 data as Y and applying the usual rec.601 contrast expansion on conversion to RGB. AviSource("filename.avi", pixel_type="RGB32") doesn't apply the contrast expansion (although this may depend on the Y800 decoder that's being used).

Opening the Y800 AVI file directly in VirtualDub and debayering:


Using AviSource("y800.avi", pixel_type="RGB32") and debayering in VirtualDub:

[Gavino]

It looks like you're right.

I was just asking a question - thanks for answering it.

Experimentally, VirtualDub is handling the Y800 data as Y and applying the usual rec.601 contrast expansion on conversion to RGB. AviSource("filename.avi", pixel_type="RGB32") doesn't apply the contrast expansion (although this may depend on the Y800 decoder that's being used).

I think this means that 201flyer's earlier results were wrong.
Values in the range 16-235 would be expanded to 0-255 and those outside 16-235 would be lost (ie crushed to 16 or 235).

It seems the only correct way would be to open the Y800 file using AviSource with pixel_type="YV12" or "YUY2" (or another source filter which delivers YUV), which is what he had trouble getting to work.

[Archimedes1]

About two years ago, I wrote a debayer function for AviSynth based on NNEDI. The thread can be found here.