Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
24th October 2016, 06:45 | #2482 | Link |
Registered User
Join Date: Jul 2003
Location: India
Posts: 890
|
Many thanks for this. I still need few clarifications. Sorry to bother you. For the 10 t0 14 bit depth formats is it correct to assume that avs+ provides to the plugin 16 bit values with the MSB s filled in with appropriate number of zeroes.
I also infer that packed RGB formats support only 8bit or 16 bit per color . In case of float U and V values, vapoursynth uses -0.5 to + 0.5.range. Any reason for this departure by AVS+? Which of these are standard? |
24th October 2016, 08:11 | #2483 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
There are places in the core filters however where I had to make extra checkings for the valid values, mostly in functions that use lookup, to avoid overindexing a 10 bit lut table with a falsely presented higher pixel value. Or in Histogram. But for most of other filters there is no pre-check, that would slow down the processing. No reason, for most of the internal filters it was much easier not to deal with the range shift, UToY, VToY works transparently, did not have to make special cases for differently handling U and V just for float, etc. And this three months timeframe was clearly not enough to look at all these problems and questions from an independent, external overview. Last edited by pinterf; 24th October 2016 at 08:17. |
|
24th October 2016, 10:50 | #2484 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Avisynth Plus Quick reference guide
Color spaces Greyscale (Y only)
ComponentCount() for greyscale formats returns 1 YUV: planar format with a luma (Y) and two chroma (U, V) channels
Check#1: Is420, Is422, Is444 (instead of IsYV12/IsYV16/IsYV24 which are for 8 bits only) Check#2: IsYUV for compatibility reasons, IsYUV returns true for YUY2 and Y also For strict checking one can check IsPlanar (for distinct from YUY2) and ComponentCount==3 (for distinct from greyscale) YUVA: planar format with a luma (Y), two chroma (U, V), and one Alpha (A) channels
Check#2: IsYUVA ComponentCount for YUVA returns 4 Note: YUVA is a separate color space family, in order to handle YUV and YUVA clips, you have to check for YUVA separately. Packed RGB 8 bits: RGB24, RGB32 (BGR and BGRA internally) 16 bits: RGB48, RGB64 Check: IsRGB ; note: IsRGB now true for planar RGB(A) color spaces. Check2: IsRGB24, IsRGB32, IsRGB48, IsRGB64 Planar RGB, RGBA: RGB family with 3 or 4 planes of colors Plane order is GBR and GBRA internally 8 bits: RGBP, RGBAP or RGBP8, RGBAP8 10, 12, 14, 16 bits: RGBP10..RGBP16, RGBAP10..RGBAP16 32 bits (float/Single precision): RGBPS, RGBAPS Check: IsPlanarRGB or IsPlanarRGBA respectively Check#2: generally IsRGB is also true Colorspace conversions
YUV420: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s Greyscale: c[matrix]s others: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s
(c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s) matrix parameter can have a new value
Colorspace conversions are working within the same bit depth: e.g. you cannot convert a 10 bit YUV420P10 to RGB64.
Bit depth conversion ConvertBits(bits[,truerange,dither) Old versions: ConvertTo8bit, ConvertTo16bit(bits), ConvertToFloat I recommend that you use the ConvertBits format. For Y, U and V channels the conversion is a simple bit-shift. For R, G, B and A channels the pixel values are "streched" in order to have 0..255 to be mapped to 0..65535 At the moment you cannot choose this behaviour as a parameter. parameters:
Compatibility conversions Conversions for hacked 16 bit formats. For filters that use 16 bit video data in a fake 8 bit colorspace. Avisynth plus provides built-in conversions for your convenience until more plugins supporting high bit depth appear.
Misc. video info properties
Last edited by pinterf; 24th October 2016 at 11:36. |
24th October 2016, 12:16 | #2485 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,547
|
What's the AVERAGE matrix good for? Is this an odd attempt at naming YCgCo or something else?
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
26th October 2016, 15:31 | #2486 | Link |
Registered User
Join Date: Oct 2011
Posts: 275
|
Hello,
I always used to add a logo on my videos using this command : Now in avisynth r2290 x64 it returns me this : [IMG]https://s14.postimg.org/unu51lwc1/22317820161026153618crcr.png [/IMG] I read the previous post about references and tried with ConvertToYUV420() instead of ConvertToYV12() but the result is the same as last picture. If i leave the ConvertToYV12() where it is the result is always messed up, if i move it at the end of the script it works. Don't know if i understand everything correctly or missing something, i'm a bit lost in this now. If anyone have a clue about this please, thanks a lot for the help. Last edited by Yanak; 23rd January 2018 at 00:21. |
26th October 2016, 16:39 | #2487 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
|
|
26th October 2016, 18:47 | #2489 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Expected sooner, but the first bug was reported. Big thanks for it, really.
The fix is available: Avisynth Plus r2294MT Avisynth Plus r2294-MT Date: 20161026 - Fix: Overlay 8 bit YV12 and possibly YUY2 - New: DirectShowSource and AviSource 16-bit RGB input support (BGR[48], BRA[64]) The addition came from our new contributor, ignus2. Changed files compared to the r2290 release: avisynth.dll and directshowsource.dll |
27th October 2016, 13:33 | #2492 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,297
|
Is something like this still working with all these new format/size, or should i do otherwise ?
Code:
const int src_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width); |
27th October 2016, 14:32 | #2493 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Whats wrong with this ?
Code:
const int src_width = src->GetRowSize(PLANAR_Y) I should not imagine that anything has changed in AVS+
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
27th October 2016, 14:34 | #2494 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
For non-planar sources BytesFromPixels(1) will return RGB24: 3 RGB32: 4 RGB48: 6 RGB64: 8 YUY2: 2 If you want to get the byte size of a row (within one plane for planar or the whole packed line for old RGB formats), by using BytesFromPixels(width) you will get the occupied bytes of one row. I suppose you use it in resampler, this is how it is used there: int work_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width) / pixelsize where pixelsize is vi.ComponentSize() (1 for 8 bits, 2 for 10-16 bits, 4 for float) |
|
27th October 2016, 18:01 | #2496 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
About 16-bit RGB support:
I'd like to have some opinions here. The fourccs I added to AviSource/DirectShowSource was based on what ffmpeg defined for them (bgr48le: BGR0 ie. BGR[48], bgra64le: BRA@ ie. BRA[64]): https://github.com/FFmpeg/FFmpeg/blo...bavcodec/raw.c Bottom-first vs Top-first Currently, afaik, packed RGB (both 8/16-bit) is always stored inside avs+ upside down (bottom-first). This is OK (doesn't matter), the question is how to handle 16-bit RGB data when it enters/exits avs+. We all know for DIB formats inside avi/vfw/dshow the sign of the height matters: negative height means top-first, positive height means bottom-first. BGR0 and BRA@ are basically the 16-bit equivalents of BI_RGB 24/32 bit, however it is unclear whether they should be treated as DIB or not (meaning: should the sign of the height matter or not). We had a long discussion with shekh about this on how to interpret it, and we think these formats don't qualify for the DIB rule, so the sign of the height shouldn't matter (as they are separate fccs), or should it? ^Opinions needed here. The reason fcc:BI_RGB with bits:64 doesn't work (when coming from a codec for example) is that it makes dshow croak. I believe it is because dshow tries to match to a mediasubtype, and there is none for BI_RGB 64bit, so it fails. So the only option is to use some fourcc, for which the only one existing is defined in ffmpeg (the fact that ffmpeg however cannot read back AVIs written by itself containing BGR0/BRA@ fourcc is another story). Y8 as DIB Avs+ AviSource/DirectShowSource treats Y8 as DIB meaning the sign of the height matters and also expects 4-byte boundary padding. Why is that (source)? Greets, I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... |
27th October 2016, 18:07 | #2497 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,547
|
This is simple. Planar formats aren't aligned to 4 bytes. What's a packed format? Formats with only one plane. Y8 has only one plane and thus follows this rule. Note that partially packed formats like NV12 with its two planes aren't packed. This is common wisdom and you'll notice corrupted output everywhere once you stop following it. See AVFS bugs, and probably some ancient vdub blog posts and the avisynth vfw code. That part has nothing to do with DIB btw.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet Last edited by Myrsloik; 27th October 2016 at 18:10. |
27th October 2016, 18:24 | #2498 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
EDIT: And why does Y8 take the sign of the height into account (in AviSource)? Is it also something common I'm not yet aware of? Any thoughts on 16-bit packed RGBA (the other question)?
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... Last edited by Ignus2; 27th October 2016 at 18:40. |
|
27th October 2016, 23:00 | #2499 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
This may be strange, but why we don't has hex colors (aka Web colors)?
I think it will be useful in Motion Analyze
__________________
See My Avisynth Stuff |
27th October 2016, 23:20 | #2500 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
I've no idea how you would want the hex colors arranged (if more than 8 bits per channel),
but maybe some of the scripting here could be persuaded to provide whatever you require. http://forum.doom9.org/showthread.ph...si#post1711065 EDIT: Colors are from Avisynth provided colors_rgb.avsi in plugins folder. Quote:
EDIT: And see here:- http://avisynth.nl/index.php/Color_presets
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 27th October 2016 at 23:49. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|