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. |
30th May 2018, 15:48 | #4082 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Yes.
I also had to update some external filters, most of their sub-filters are o.k., will work as-is, but some filters need to be updated for the new 32bit float UV ranges. For example: masktools2: mt_diff, predefined constants in lut expressions (finished, not released yet) fft3dfilter: chroma center |
3rd June 2018, 11:23 | #4083 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
New test build
Avisynth+ r2696 https://drive.google.com/open?id=1yU...bDpSdEbR6yugUm Compared to last test build (r2693): - ConvertBits from/to 32 bits assume full source/destination range only for RGB. Additional fix was in limited range conversion when source is 32 bits - Avisource: Greyscale 10, 12, 14, 16 bits for Y1[0][10] .. Y1[0][16] (not tested) Full list since last official release (r2664) Code:
- AviSource to support more formats with 10+ bit depth. http://avisynth.nl/index.php/AviSource When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below. When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format) you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64. The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace. Full support list (* = already supported): 'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery YV24 YV24 *YV24 YV16 YV16 *YV16 YV12 YV12 *YV12 YV411 YV411 *Y41B YUY2 YUY2 *YUY2 RGBP10 RGBP10 G3[0][10] r210 R10k r210 RGBP10 r210 R10k RGBP10 R10k RGBP RGBP10 G3[0][10] r210 R10k RGBP12 G3[0][12] RGBP14 G3[0][14] RGBP16 G3[0][16] RGBAP10 G4[0][10] RGBAP12 G4[0][12] RGBAP14 G4[0][14] RGBAP16 G4[0][16] RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32 RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24 RGB48 RGB48 BGR[48] b48r RGB64 RGB64 *BRA[64] b64a Y8 Y8 Y800 Y8[32][32] GREY Y Y8 Y800 Y8[32][32] GREY Y10 Y1[0][10] Y12 Y1[0][12] Y14 Y1[0][14] Y16 Y1[0][16] YUV422P10 YUV422P10 v210 P210 v210 YUV422P10 v210 P210 YUV422P10 P210 YUV422P16 YUV422P16 P216 P216 YUV422P16 P216 YUV420P10 YUV420P10 P010 P010 YUV422P10 P010 YUV420P16 YUV420P16 P016 P016 YUV422P16 P016 YUV444P10 YUV444P10 v410 v410 YUV444P10 v410 - Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels. U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1 Note: filters that relied on having the U and V channel center as 0.5 will fail. Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now compatible with z_XXXXX resizers (zimg image library, external plugin at the moment). - New function: bool IsFloatUvZeroBased() For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format: Check function availablity with FunctionExists("IsFloatUvZeroBased"). When the function does not exists, the center value of 32 bit float U and V channel is 0.5 When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5) - Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers) - Fix: Rare crash in FrameRegistry - Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths - Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits E.g. after a 8->32 bit fulls=false fulld=true: Y: 16..235 -> 0..1 U/V: 16..240 -> -0.5..+0.5 Note: now ConvertBits does not assume full range for YUV 32 bit float. Default values of fulls and fulld are now true only for RGB colorspaces. - Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue) - Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script - New: LoadVirtualdubPlugin update: - Update from interface V6 to V20, and Filtermod version 6 (partial) - VirtualDub2 support with extended colorspaces Allow RGB24, RGB48, RGB64 besides RGB32 AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless) AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless) Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8 Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert) - Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported - Supports prefetchProc callback (API >= V12 and prefetchProc is defined) - Supports when filter changes frame count of the output clip - Extra filter parameter added at the end of filter's (unnamed) parameter list Imported Virtualdub filters are getting and extra named parameter to the end: String [rangehint] This parameter can tell the filter about a YUV-type clip colorspace info Allowed values: "rec601": limited range + 601 "rec709": limited range + 709 "PC.601": full range + 601 "PC.709": full range + 709 "" : not defined (same as not given) Parameter will be ignored when clip is non-YUV How it works: the hint will _not_ change the internal VirtualDub colorspace constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen). Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx. Filter can either use this information or not, depending on supported API version and its implementation. E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it. - New function: BuildPixelType Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a template clip, from which the undefined format elements are inherited. "[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c" string family: YUV, YUVA, RGB, RGBA, Y int bits: 8, 10, 12, 14, 16, 32 string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB) bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8 clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10) Example#1: define YUV 444 P 10 family = "YUV" bits = 10 chroma = 444 compat = false oldformat = false s = BuildPixelType(family, bits, chroma, compat, oldformat) BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info() Example#2: Change only the bit depth of the format to 16 newbits = 16 c = last s = BuildPixelType(bits=newbits, sample_clip=c) BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info() - Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed. - Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init - Source: C api: avs_is_same_colorspace VideoInfo parameters to const - Project struct: changelog to git. - Planned: include current header files and def/exp file in installer |
4th June 2018, 15:03 | #4084 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Another test build, r2700, installer w/o Visual C++ Redistributables
https://drive.google.com/open?id=1LP...No3Bi6--2NtdzF Change since r2696: RGBAdjust fix and enhancements Full change since last official release (r2664): Code:
- Fix: RGBAdjust memory leak when used in ScriptClip - Enhanced: RGBAdjust new parameter: conditional (like in ColorYUV) The global variables "rgbadjust_xxx" with xxx = r, g, b, a, rb, gb, bb, ab, rg, gg, bg, ag are read each frame, and applied. It is possible to modify these variables using FrameEvaluate or ConditionalReader. - Enhanced: RGBAdjust: support 32 bit float ('analyze' not supported, 'dither' silently ignored) - Enhanced: AviSource to support more formats with 10+ bit depth. http://avisynth.nl/index.php/AviSource When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below. When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format) you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64. The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace. Full support list (* = already supported): 'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery YV24 YV24 *YV24 YV16 YV16 *YV16 YV12 YV12 *YV12 YV411 YV411 *Y41B YUY2 YUY2 *YUY2 RGBP10 RGBP10 G3[0][10] r210 R10k r210 RGBP10 r210 R10k RGBP10 R10k RGBP RGBP10 G3[0][10] r210 R10k RGBP12 G3[0][12] RGBP14 G3[0][14] RGBP16 G3[0][16] RGBAP10 G4[0][10] RGBAP12 G4[0][12] RGBAP14 G4[0][14] RGBAP16 G4[0][16] RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32 RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24 RGB48 RGB48 BGR[48] b48r RGB64 RGB64 *BRA[64] b64a Y8 Y8 Y800 Y8[32][32] GREY Y Y8 Y800 Y8[32][32] GREY Y10 Y1[0][10] Y12 Y1[0][12] Y14 Y1[0][14] Y16 Y1[0][16] YUV422P10 YUV422P10 v210 P210 v210 YUV422P10 v210 P210 YUV422P10 P210 YUV422P16 YUV422P16 P216 P216 YUV422P16 P216 YUV420P10 YUV420P10 P010 P010 YUV422P10 P010 YUV420P16 YUV420P16 P016 P016 YUV422P16 P016 YUV444P10 YUV444P10 v410 v410 YUV444P10 v410 - Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels. U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1 Note: filters that relied on having the U and V channel center as 0.5 will fail. Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now compatible with z_XXXXX resizers (zimg image library, external plugin at the moment). - New function: bool IsFloatUvZeroBased() For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format: Check function availablity with FunctionExists("IsFloatUvZeroBased"). When the function does not exists, the center value of 32 bit float U and V channel is 0.5 When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5) - Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers) - Fix: Rare crash in FrameRegistry - Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths - Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits E.g. after a 8->32 bit fulls=false fulld=true: Y: 16..235 -> 0..1 U/V: 16..240 -> -0.5..+0.5 Note: now ConvertBits does not assume full range for YUV 32 bit float. Default values of fulls and fulld are now true only for RGB colorspaces. - Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue) - Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script - New: LoadVirtualdubPlugin update: - Update from interface V6 to V20, and Filtermod version 6 (partial) - VirtualDub2 support with extended colorspaces Allow RGB24, RGB48, RGB64 besides RGB32 AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless) AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless) Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8 Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert) - Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported - Supports prefetchProc callback (API >= V12 and prefetchProc is defined) - Supports when filter changes frame count of the output clip - Extra filter parameter added at the end of filter's (unnamed) parameter list Imported Virtualdub filters are getting and extra named parameter to the end: String [rangehint] This parameter can tell the filter about a YUV-type clip colorspace info Allowed values: "rec601": limited range + 601 "rec709": limited range + 709 "PC.601": full range + 601 "PC.709": full range + 709 "" : not defined (same as not given) Parameter will be ignored when clip is non-YUV How it works: the hint will _not_ change the internal VirtualDub colorspace constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen). Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx. Filter can either use this information or not, depending on supported API version and its implementation. E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it. - New function: BuildPixelType Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a template clip, from which the undefined format elements are inherited. "[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c" string family: YUV, YUVA, RGB, RGBA, Y int bits: 8, 10, 12, 14, 16, 32 string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB) bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8 clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10) Example#1: define YUV 444 P 10 family = "YUV" bits = 10 chroma = 444 compat = false oldformat = false s = BuildPixelType(family, bits, chroma, compat, oldformat) BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info() Example#2: Change only the bit depth of the format to 16 newbits = 16 c = last s = BuildPixelType(bits=newbits, sample_clip=c) BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info() - Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed. - Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init - Source: C api: avs_is_same_colorspace VideoInfo parameters to const - Project struct: changelog to git. - Planned: include current header files and def/exp file in installer |
5th June 2018, 13:23 | #4085 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
As I understand it, when using GetFrame(), pitch can vary on a per-frame basis for all planes. Is it possible to get the maximum possible pitch for each plane?
The reason I ask is I'd like to avoid painful reallocations, so if I can simply allocate the maximum pitch * vi.height (right shifted by GetPlaneHeightSubsampling()) for each plane, then I don't have to worry about it exceeding my initial allocation later on. Last edited by `Orum; 5th June 2018 at 13:47. |
5th June 2018, 14:23 | #4086 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
Pitch can change because of interleaving of cropped clips, I forget what the new rules are on avs+ concerning crop and Align arg, but on v2.6 standard, Align is False by default, and so is much more likely to do a Soft Crop, ie Subframe() and SubframePlanar(), so pitch could be pretty much any size. (I take it that you would like it to work on avs standard too). Output frame pitch is guaranteed identical. [EDIT: When calling NewVideoFrame, ie not simply passing though a frame like in ClipClop or ReplaceFramesSimple.] IanB Torture Test Code:
.... A=SelectEvery(3, 0).AddBorders(0,0, 16,0).Crop(0,0, -16,0) B=SelectEvery(3, 1).AddBorders(0,0, 32,0).Crop(0,0, -32,0) C=SelectEvery(3, 2).AddBorders(0,0, 64,0).Crop(0,0, -64,0) Interleave(A, B, C) .... https://forum.doom9.org/showthread.p...re#post1603626 https://forum.doom9.org/showthread.p...re#post1628159
__________________
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; 5th June 2018 at 15:17. |
|
5th June 2018, 14:53 | #4087 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Alignment:
Plane pointers and pitches are 64 bytes aligned in recent Avisynth+ versions (but it was 32 bytes before - avx and avx2-safe), this is the minimum. It can be larger, when NewVideoFrame is called with a larger align value, e.g. 128 But there is no guarantee that a pitch is simply an up-aligned value of the plane width, framebuffers are mostly re-used internally to avoid reallocation. Plus, as StainlessS mentioned, a Crop (in avs+ always producing an aligned output, the alignment rule can never be broken), or SeparateRows can simply change the pitch value internally w/o making a frame copy. Last edited by pinterf; 5th June 2018 at 15:33. Reason: SeparateRows instead of SelectEven |
5th June 2018, 15:25 | #4088 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Made edit in my previous post, I should have caught that.
Presumably, MakeWritable can change Pitch from original input too. EDIT: On frame like this for instance: Quote:
__________________
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; 5th June 2018 at 15:34. |
|
5th June 2018, 16:18 | #4089 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
Okay, so I'm guessing the best bet here is to get the per plane pitches for the first frame, and for every later frame check if they're increased. If so, recreate my buffer with a larger size. Unless there is some better option I'm not thinking of...
|
5th June 2018, 16:27 | #4090 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
I guess you don't have to repeat any pitch for your own buffer, just allocate whatever is sufficient?
__________________
VirtualDub2 |
5th June 2018, 17:05 | #4091 | Link | |
Registered User
Join Date: Sep 2005
Posts: 178
|
Quote:
However, if processing is done on a CPU or integrated GPU (or really anything with unified memory between host and device), this incurs an additional copy operation, which I'd like to avoid. Fortunately, this can be avoided in these circumstances (and already is in my current code), as when you create a buffer with CL_MEM_USE_HOST_PTR no copying is done anyway—or so I assume. It certainly is faster than an explicit copying of the buffer. Last edited by `Orum; 5th June 2018 at 17:16. |
|
9th June 2018, 10:00 | #4092 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
On another note, I've noticed what I think is some color shift toward Cb-/Cr- with the ColorYUV(levels="TV->PC") / ColorYUV(levels="PC->TV"). The results look different from what I see with the conversion filters within MPC-HC, and while that means that problem could be in either MPC-HC or AviSynth+, I suspect it's in AviSynth+. Why? Consider the following script:
Code:
function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") } ColorBars(pixel_type="YV12") Interleave(last.s(), last.s().s().s().s().s().s().s().s().s().s().s().s().s().s().s().s()) # Initial clip calls s() once because ColorBars() has some strange levels ColorYUV(analyze=true) Edit: Animated for those too lazy or unable to run the script on their devices Last edited by `Orum; 9th June 2018 at 10:14. |
9th June 2018, 10:56 | #4093 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Is it (in the main) perhaps down to a part of the 'pluge' (think thats what its called) being @ luma value 7 [EDIT: and 242] (ie non TV range).
Code:
A=ColorBars(pixel_type="YV12").BicubicResize(480,360) B=A.ColorYUV(levels="TV->PC") C=B.ColorYUV(levels="PC->TV") A=A.ColorYUV(analyze=true) B=B.ColorYUV(analyze=true) C=C.ColorYUV(analyze=true) StackVertical(A,B,C) EDIT: Did not notice this line, Quote:
But even with pluge fixed with eg limiter, does exhibit strange behaviour as pin pointed by Orum. ie like this Code:
function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") } # Initial clip calls s() once because ColorBars() has some strange levels ColorBars(pixel_type="YV12").Limiter Interleave(last, last.s().s().s().s().s().s().s().s().s().s().s().s().s().s().s().s()) ColorYUV(analyze=true) EDIT: Limiter dont work as required, mod to Levels [EDIT: This is rubbish, dont know why I thought Limiter did not work, it does] Code:
function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") } ColorBars(pixel_type="YV12").Bicubicresize(480,360) Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels A=Last B=last.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true)) EDIT: Only 1 iteration Code:
function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") } ColorBars(pixel_type="YV12").Bicubicresize(480,360) Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels A=Last B=last.s #.s.s.s.s.s.s.s.s.s.s.s.s.s.s StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))
__________________
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; 13th June 2018 at 07:59. |
|
9th June 2018, 15:12 | #4094 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
maybe it's caused by coloryuv levels work as levels(16,1,235,0,255)~levels(0,1,255,16,235)
without maintain chroma planes centered on 128, like a mergechorma(levels(16,1,235,0,255),levels(16,1,240,0,255)) will do
__________________
powered by Google Translator |
9th June 2018, 20:45 | #4095 | Link |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
What if you run the test script in 16-bits dithering back to 8-bits at the end instead of running it multiple times in 8-bits? That should point to either rounding errors or perhaps a rounding bias vs. an error in the calculations.
Last edited by Stereodude; 9th June 2018 at 20:50. |
9th June 2018, 21:10 | #4096 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Alternatively, you can use smoothlevels and set the chroma processing to zero
By default, lato set it at 100 (from 0-200) or intermediate e.g using stainlesss's (enough sssss's ? )test Code:
ColorBars(pixel_type="YV12").Bicubicresize(480,360) Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels A=Last B=last.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true)) #function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") } function s(clip c) { return c.smoothlevels(preset="tv2pc", chroma=0).smoothlevels(preset="pc2tv",chroma=0) } |
9th June 2018, 21:25 | #4097 | Link | |
Registered User
Join Date: Sep 2005
Posts: 178
|
Quote:
When you add dithering, I think if anything that would only muddy the waters (as then you wouldn't be sure if the source of any shift was ColorYUV() or ConvertBits()). It would be interesting to know if it affects HBD clips, though I suspect if it does it may take more instances of conversion to get the same amount of error (in terms of relative distance). Sure you can do that, but aren't chroma planes supposed to be changed when doing TV->PC level conversion? If not one could simply do a MergeChroma() as well... Last edited by `Orum; 9th June 2018 at 21:28. |
|
9th June 2018, 22:26 | #4098 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
__________________
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 ??? |
|
9th June 2018, 22:30 | #4099 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Maybe. I think that was the reason he chose intermediate as the default setting (chroma is processed intermediate strength). You can leave it default 100, or increase it to 200 , or 0 for YLevels like behaviour. Eitherway, you don't get contamination of greyscale patches with smoothlevels (you can disable dithering too as well) . ie. U=V . So it is a problem with coloryuv
|
9th June 2018, 23:15 | #4100 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
I took RGB test pattern (0-255), greyscale, R,G,B . ConvertToYV24(matrix="pc.709") , then PC->TV, PC->TV eight times , then back to TV. Dithering is disabled for all . The RGB screenshot used "PC" levels for the original, "REC" for the others (because they were scaled to TV)
"TV" levels means U,V should be limited 16-240, so chroma=100 looks correct at least for the max U,V value Not only is there a green shift for coloryuv, there are more weird patterns |
Thread Tools | Search this Thread |
Display Modes | |
|
|