AviSynth+ thread Vol.2

[pinterf]

Avisynth+ 3.7.2 test 12 (20220303) (https://drive.google.com/uc?export=download&id=1PMdVp0U0Jq9b88ahg20SBotU_UB-w3oP)
20220303 3.7.2-WIP
------------------
- propCopy: able to specify that the property list is negative.
bool "exclude" = false # default: "props" is positive list

propCopy(org,true,props=["_Matrix", "_ColorRange"], exclude=false) # merge only two properties
propCopy(org,true,props=["_Matrix", "_ColorRange"], exclude=true) # merge all, except listed ones
propCopy(org,props=["_Matrix", "_ColorRange"]) # erase all then copy only selected
propCopy(org,props=["_Matrix", "_ColorRange"], exclude = true) # erase all, then copy all, except listed ones

- Version()
New optional parameters

int length, int width, int height, string pixel_type, clip c

Version clip defaults:
length=240, width = -1, height = -1 (-1: automatically sized to fit for font size 24)
pixel_type = "RGB24"

When 'clip' (a format template) is specified then pixel_type, length,
fps data, width and height are defined from it.
If any additional 'length', 'width', 'height', 'pixel_type' parameter is given, it overrides defaults.
When width and height is given and is <= 0 then it is treated as 'automatic'

Covers feature request Issue #261

- BlankClip: allow 'colors' size more than actual number of planes.
If an array is larger, further values are simply ignored.
- BlankClip, AddBorders, LetterBox: no A=0 check for non-YUVA
- Fade filter family new parameters
int 'color_yuv'
array of float 'colors'
similar to BlankClip
- MergeRGB, MergeARGB
- add MergeARGB parameter "pixel_type", similar to MergeRGB
- accept pixel_type other than packed RGB formats, plus a special one is "rgb"
- output format is planar rgb(a) (MergeRGB/MergeARGB) when
- pixel_type = "rgb" or
- pixel_type is empty and
- either input is planar RGB
- either input is different from 8 or 16 bits (no packed RGB formats there)
- pixel_type is explicitely set to a valid planar rgb constant e.g. "RGBP10"
- Accept planar RGB clip in place of input clips and the appropriate color plane is copied from them
- Fill alpha channel with zero when MergeRGB output pixel_type format is specified to have an alpha plane
- frame property source is the R clip; _Matrix and _ChromaLocation are removed if R is not an RGB clip

[gispos]

Avisynth+ 3.7.2 test 12 (20220303) (https://drive.google.com/uc?export=download&id=1PMdVp0U0Jq9b88ahg20SBotU_UB-w3oP)

Thanks, for 32bit Is there only the XP version?

[kedautinh12]

Thanks, for 32bit Is there only the XP version?

No, it's can use in another windows ver

[pinterf]

Yes. XP and newer.

[gispos]

I assumed that, but I thought that the XP version is neutered. :)

[LigH]

It may contain a more compatible but slightly outdated threading code?

[pinterf]

I assumed that, but I thought that the XP version is neutered. :)
There is still an option for the v141_xp toolset in Visual Studio 2022 though I'm still using Visual Studio 2019; my developer PC migration is in progress since January.
But I hate it, for some reason building an XP version takes at least 25 minutes, while normal version is ready in 3-5 minutes.
Threading code - static variable initializing - is not thread safe in XP versions (-Zcthreadsafeinit- option is needed), I met this phenomenon only once, in masktools2, when I spent some days understanding a thing that normally was impossible to happen, then had to do a workaround.

[FranceBB]

Speaking of compilation, has anyone ever done a speed test when comparing the normally compiled x64 version (non XP one) which targets SSE2 and a re-compiled x64 version (non XP one) that targets AVX2 to see if there are any speed benefits?
The reason why I'm asking this is that IF there are speed benefits, we might have the x86/x64 XP version still compiled with Zc:threadSafeInit using v141_xp targeting SSE2 and the x86/x64 non XP ones compiled with v142 and targeting AVX2 instead so that those with a newer OS but an older CPU will still be able to "fallback" on the XP versions which are SSE2 proof and those with new beefy machines can benefit from AVX2 for the C/C++ part of the code that doesn't have intrinsics.
What do you think?

[pinterf]

Speaking of compilation, has anyone ever done a speed test when comparing the normally compiled x64 version (non XP one) which targets SSE2 and a re-compiled x64 version (non XP one) that targets AVX2 to see if there are any speed benefits?
The reason why I'm asking this is that IF there are speed benefits, we might have the x86/x64 XP version still compiled with Zc:threadSafeInit using v141_xp targeting SSE2 and the x86/x64 non XP ones compiled with v142 and targeting AVX2 instead so that those with a newer OS but an older CPU will still be able to "fallback" on the XP versions which are SSE2 proof and those with new beefy machines can benefit from AVX2 for the C/C++ part of the code that doesn't have intrinsics.
What do you think?
Targeting SSE2 means only that the DLL needs at least SSE2.
Most internal codes however benefit SSE4.1, AVX, AVX2. Almost all internal filters have both SSE2/SSE4.1 and AVX/AVX2 versions. Choosing the best available version is dynamic. Support for modern processors does not mean that the whole DLL is compiled for e.g. AVX2. One single DLL contains all processor versions, it's the filter writer's task to run the appropriate version, e.g. if I'd let run SSE4.1 version of a resizer on an old AMD it would crash.

So Avisynth built for XP still contain all AVX/AVX2 optimizations. These AVX+ optimizations are not available on XP because Windows XP as an operating system does not support saving extra AVX/AVX2 registers so their use is disabled. Even if the processor has AVX2 instruction set, it won't be reported as a processor feature under XP, so the function dispatcher will use at most SSE4.1 versions of internal filters.

[FranceBB]

I know, but I was wondering about the plain C++ part of the Avisynth core, whether it would benefit or not, but at this point I think everything in the core (I mean in the frameserver itself including all functions) has the relative assembly optimization which will be picked dynamically every time it loads and it detects the instructions set of the host CPU, right?

The reason why I asked is that I know that for instance some external plugins are in C++ only, so it's up to the compiler to generate optimized code given that there are no manually written intrinsics, however if I got it right this doesn't apply to the AVS core, so to the frameserver itself, 'cause everything inside the core HAS manually written intrinsics anyway and those will be picked dynamically at run time so that each CPU goes to the appropriate codepath, so the compiler doesn't have to optimize anything at all given that everything has already been written by a human being, right?

[DTL]

"and the x86/x64 non XP ones compiled with v142 and targeting AVX2 instead"

AVX is a decade+ old. If you can build the executable it is better to set optimization to your current CPU architecture. If your CPU is AVX512 - set it to compiler and it may use extra register file available in AVX512-capable chip. It is 4 times larger in compare with old AVX. Also if possible - try intel optimizing compiler and multi file interprocedure optimization. It may also make some visible performance gain. Currently several different C/C++ compilers available and may generate significantly different executable (even from intrinsics - it is not hardcoded ASM but only a 'good hint' to compiler). So the more AVS goes away from hardcoded asm to intrinsics - the more it depend on exact compiler even in 'pseudo-asm' of its part.

Also typically the large complex projects are shipped with 'fail-safe' compiler options to make building somehow working executable easier. But it not mean it is fastest possible - because more complex compiler options like interprocedure optimization may cause build fail. So if someone have time to experiment - it may take a day or days to try different compiler options and different compilers to make best speed executable even without touching program text at all. Each compile is slow so it takes hours to test several compile options with full rebuild.

[wonkey_monkey]

According to the Wiki page on Expr:

string scale_inputs = "none"

"floatUV": (since v3.5) chroma pre and post shift by 0.5 for 32 bit float pixels, thus having them in the range of 0..1 instead of -0.5..+0.5 during Expr evaluation

I'm on 3.7.1 (compiled from source) but when I tried this parameter value, I got this error:

https://i.imgur.com/Bdx6i8K.png

Which is wrong, the Wiki or the source code?

[Reel.Deel]

Blankclip(pixel_type="YUV444PS", colors=[1,1,1])
Expr("x .5 -", scale_inputs="floatUV")

Works for me, I'm using 3.7.2 test12.

[LigH]

Check if you really use the AviSynth version you believe to use, and the color mode this feature may require...

[wonkey_monkey]

I figured it out. scale_inputs is case sensitive, which I didn't expect, and also the error message needs updating to include "floatUV" as one of the reported options (line 5958 of exprfilter.cpp)

[pinterf]

I figured it out. scale_inputs is case sensitive, which I didn't expect, and also the error message needs updating to include "floatUV" as one of the reported options (line 5958 of exprfilter.cpp)
yay. I have approximately zero motivation fixing it nowadays. My mind is all elsewhere. On my morning bike commute I dropped some tinned food at a humanitarian aid center in the central railways station for Ukrainan refugees.

[wonkey_monkey]

Sorry if you took it as a demand for immediate action - it wasn't - but I'm just reporting a bug...

[pinterf]

Sorry if you took it as a demand for immediate action - it wasn't - but I'm just reporting a bug...
No, no, nothing wrong with it, it's just difficult to express my feelings properly.

[pinterf]

I think parameter values (e.g. matrix names) are usually case insensitive. Names of frame properties however are case sensitive.

[wonkey_monkey]

No, no, nothing wrong with it, it's just difficult to express my feelings properly.

No problem. I find some of my feelings on the matter quite easy to express with four-letter words, but... forum rules and all that.

[pinterf]

Parameter value is now case insentive and the error message contains floatUV as well. Thanks for the report.

[SeregaDS]

yay. I have approximately zero motivation fixing it nowadays. My mind is all elsewhere. On my morning bike commute I dropped some tinned food at a humanitarian aid center in the central railways station for Ukrainan refugees.

Thank you from Ukraine!
p.s. sorry for offtop

[Dogway]

Many camcorders and video capable cameras now are using 16-255 that contain extra highlight information (superwhites) to be retreived later on processing. You can even display this range on a capable device (there are such projectors).

Recovering this post to ask about adding official "_ColorRange" mode 2 as a new range parameter. I had it in TransformsPack for some time but I wasn't sure whether it was a marginal case. I see it now in repeated places, also used in some HLG 10-bits. It has several names, SMPTE+, Camera Range or Extended Range, so whatever fits. Not for now but when you get back to AviSynth, take your time.

The allowed range changes in this case as it uses the Limited Range flag, for the higher bound it uses the data max (https://github.com/Dogway/Avisynth-Scripts/blob/9502f348ac29a8c0438b0eadf47ae4b2424a9522/ExTools.avsi#L7201) values. For example 64-1019 for 10-bit HLG.

[ryrynz]

No, no, nothing wrong with it, it's just difficult to express my feelings properly.

Except when it comes to doing something outside, your excitement is palpable.

[FranceBB]

Except when it comes to doing something outside, your excitement is palpable.

Ferenc Pinter, a skilled developer and an amazing human being for everything he does online and offline. ;)

[pinterf]

Perhaps our last chance is to talk to Zavulon and Geser and ask them to unify their force together behind the scenes to stop this one man show. (Characters from Night Watch/Day Watch book series - Ночной дозор/Дневной дозор - one of my favourites, re-read them many times.)

[pinterf]

Recovering this post to ask about adding official "_ColorRange" mode 2 as a new range parameter. I had it in TransformsPack for some time but I wasn't sure whether it was a marginal case. I see it now in repeated places, also used in some HLG 10-bits. It has several names, SMPTE+, Camera Range or Extended Range, so whatever fits. Not for now but when you get back to AviSynth, take your time.

The allowed range changes in this case as it uses the Limited Range flag, for the higher bound it uses the data max (https://github.com/Dogway/Avisynth-Scripts/blob/9502f348ac29a8c0438b0eadf47ae4b2424a9522/ExTools.avsi#L7201) values. For example 64-1019 for 10-bit HLG.
If supported, this parameter has some side effects as well; conversions must somehow support and act upon this value.
Or do you think this value must be treated simply as passthrough and being not forbidden?

Btw, sometimes I was missing another possible extension of this flag: when a limited chroma plane is extracted to a single Y clip. The plane then would be flagged as "Limited-Chroma".

[Dogway]

I was thinking only on acknowledging the index value as I don't have plans to work with it for the time being, so a passthrough I guess.
I searched for some officiality on papers but didn't find any, just some words on the fact that "super-white" is a thing. Here (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-4-2021-PDF-E.pdf#[{"num":173,"gen":0},{"name":"XYZ"},54,770,0]).
This blog post from the BBC assumes the practice. Harsh vs. Normal (https://www.bbc.co.uk/rd/blog/2020-06-lut-format-conversion-hdr-video-production)
Also found this (https://www.nacinc.jp/wp-content/uploads/2014/12/PRM-4220_Brochure_JP.pdf) product brochure of a Dolby reference monitor where they acknowledge SMPTE+ as a valid range.

I recall also reading about mixed ranges for luma and chroma, not sure if that's what you refer to.

[FranceBB]

just some words on the fact that "super-white" is a thing. Here (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-4-2021-PDF-E.pdf#[{"num":173,"gen":0},{"name":"XYZ"},54,770,0]).
This blog post from the BBC assumes the practice. Harsh vs. Normal (https://www.bbc.co.uk/rd/blog/2020-06-lut-format-conversion-hdr-video-production)


In this case this is indicated for signals routed through SDI cables and in that case we can have Super Whites and Super Blacks, but there's a catch: the last 4 bits of the full 10bit signal MUST NOT be used (same goes for the first 4 bits). Those packets are important 'cause we rely on timecodes to have everything synced with the central clock which is the very same generator inside the same location which connects each and every device connected (from VTRs to Hardware Encoders to Playout Ports etc). If a timecode "skip" is detected, there are all kind of alarms as the signal might be compromised etc. Also, without having this, a signal might be out of phase which is why every signal which is routed through SDI is ALWAYS referenced. (I mean, you can have things that are not, but nobody in his right mind would ever do that). Anyway, this is because those bits are reserved to the synchronization packets which compose the timing reference signal, which is why you cannot have a real Full Range signal carried through SDI cables, which is what is used across the world by literally every broadcaster. That being said, you almost always have Limited TV Range signals in 0.0-0.7V for luma which of course corresponds to 64-940 and -0.3V, 0.3V for chroma (https://i.imgur.com/HRLItw3.jpeg) (yes, chroma is "lower" in voltage than luma 'cause we go from -0.35V which correspond to 64 to +0.35V which corresponds to 960). In other words, even if you have a Full Range signals, 0–3 and 1020–1023 are never used and also the overwhelming majority of signals are Limited TV Range anyway and whenever there's something slightly out of range, that's almost always clipped out by some hardware to get a real Limited TV Range signal out to the user. In the screenshot I posted, we have Limited TV Range Luma with Limited TV Range Chroma + Overshooting which exceed the +0.35V (so outside of the 960) and you can see it in the FlatLumaChroma (on the right had side, chroma, in the middle there's luma).

Oh and by the way, this is actually the reason why Studio RGB exists, given that RGB is supposed to be always Full Range (but you can't work in Full Range in SDI) and this is why the LUTs I've got from several studios all work in Studio RGB (so RGB but in Limited TV Range).


I recall also reading about mixed ranges for luma and chroma, not sure if that's what you refer to.

I've never ever seen that, but hey, everything can happen eheheheh


By the way, the article from the BBC is surprisingly describing almost everything we've been doing in the past for things like football games.

[Dogway]

Ah that's good to know, I had been wondering for some time what happened to synchronization in Full Range signals... The papers don't state that "Video Data" range also applies to Full Range. This can come handy if/when I decide to encode a few things, the issue though is whether there is an intermediary conversion (well there is if I encode as YCbCr Full Range), the conversion to Full RGB is going to be flawed as the range equations assume the full signal range for Full Range flagged streams.

For example:
ConvertBits(10,fulls=false,fulld=true)
Saturates the full range.

I've never ever seen that, but hey, everything can happen eheheheh
I think the mixed plane range thing was for xvYCC extended gamut, but don't call me on that.

[FranceBB]

Ah that's good to know, I had been wondering for some time what happened to synchronization in Full Range signals... The papers don't state that "Video Data" range also applies to Full Range. This can come handy if/when I decide to encode a few things, the issue though is whether there is an intermediary conversion (well there is if I encode as YCbCr Full Range), the conversion to Full RGB is going to be flawed as the range equations assume the full signal range for Full Range flagged streams.

For example:
ConvertBits(10,fulls=false,fulld=true)
Saturates the full range.




I know, but I don't think we should change the way our conversions work only because of an SDI limit. On the other hand, this is prompting me to experiment a bit instead of trusting the proprietary Blackmagic and AJA hardware conversion to get it right, so I'm gonna try to change the card from Narrow Range to Full and see what happens and if it gets the conversion "right" for SDI (it probably does). :)

[DTL]

"the last 4 bits of the full 10bit signal MUST NOT be used (same goes for the first 4 bits). "

Not 4 bits but 4 code values of 10bit encoding. It is 2 bits.

The idea before strange float moving to 0..1.0 range in float encoding was very simple: Base levels encodings are 8bit and any higher is fractional refining inbetween 8bit codelevels. So in 8bit data paths (with possible SDI parts) sync (+ANC) reserved code values are 0 and 255. The 1,2,3 in 10bit are dangerous because if somwhere performed truncating 2 LSBs to 8bit it will result in 8bit-zero that is reserved codevalue (and may cause data parsing error). But if all processing in 10bit (or higher) - it still safe. In non-SDI workflows all codevalues from 0 to MAX may be used because there is no need to SDI sync and ANC data parsing from bitstream.

"a signal might be out of phase which is why every signal which is routed through SDI is ALWAYS referenced"

SDI is designed as self-describing bitstream format (that is sync codevalues sequencies are for) so can be re-phased to any local reference clock by 'frame sync' hardware units (it can parse incoming SDI bitstream without external reference syncs and write to internal frame buffer and read using external clock reference). For file-based workflows it is deprecated info because file based do not need special line and frame start-end detection codevalues or special reserved sequencies (and even in most cases do not keep line and frame blanking data with sync code values sequencies).

So keeping special reserved code values todays may be never need by anyone in full file-based workflows. If even some SDI transmitter still required to someone and being feed by 0..255/0..1023 file - it may simply clamp levels to 1..254 or 4..1019 in active lines codevalues because it knows it is frame data and not SDI service (or ANC) data (service data is placed in SDI bitstream outside time of sending active line data). It will be slight distortion but may be not any visible.

[FranceBB]

So keeping special reserved code values todays may be never need by anyone in full file-based workflows. If even some SDI transmitter still required to someone and being feed by 0..255/0..1023 file - it may simply clamp levels to 1..254 or 4..1019 in active lines codevalues because it knows it is frame data and not SDI service (or ANC) data (service data is placed in SDI bitstream outside time of sending active line data). It will be slight distortion but may be not any visible.

Yep, which is why I don't think we should change any of the current behaviour in avisynth for that matter, but yeah you're right. :)

[Dogway]

Great explanation, well that basically tells that full range for broadcast is a big nono. I guess "full range" is a concept that started to rise with full file-based workflows where these constraints don't apply.
By the way reading around on the papers for HDR they even encourage full range for PQ, in this space over/undershoots are minimal so no data is clipped.

[DTL]

"encourage full range for PQ, in this space over/undershoots are minimal so no data is clipped."

Full-range PQ may be used as poor-people HDR in 10bit-only limited workflows (and end-user distribution). Also for film-look tuned content without significant 'normal' over/undershoots. Mathematically PQ is the most awful non-linear transfer and most prone to additional over/under shoots and other distortions if filtered/processed in non-linear form. So 10bit full-range PQ encoding simply prefer to minimize tone distortions like banding and allow to have more 'frequency' distortions. Clipping of over/under shoots to full range integer will cause a bit less sharpness and may cause additional ringing distortions (depending on processing/displaying). But in HD/UHD it may be less critical. I hope as the hype around HDR fades away the full-range PQ 10bit transfer will be removed from general use (or the 12..12+ bits forms with 'standard moving pictures' narrow range encoding will be used or float).

[Dogway]

About the Data Range in Full Range signals, extracted from ITU BT.2100:
Note 9b – Some digital image interfaces reserve digital values, e.g. for timing information, such that the permitted video range of these interfaces is narrower than the video range of the full-range signal. The mapping from full-range images to these interfaces is application-specific.

From BT.2408:
The full range representation is useful for PQ signals and provides an incremental advantage against visibility of banding/contouring and for processing. Because the range of PQ is so large, it is rare for content to contain pixel values near the extremes of the range. Therefore, over-shoots and under-shoots are unlikely to be clipped.

Full-range PQ may be used as poor-people HDR in 10bit-only limited workflows (and end-user distribution). Also for film-look tuned content without significant 'normal' over/undershoots. Mathematically PQ is the most awful non-linear transfer and most prone to additional over/under shoots and other distortions if filtered/processed in non-linear form. So 10bit full-range PQ encoding simply prefer to minimize tone distortions like banding and allow to have more 'frequency' distortions. Clipping of over/under shoots to full range integer will cause a bit less sharpness and may cause additional ringing distortions (depending on processing/displaying). But in HD/UHD it may be less critical. I hope as the hype around HDR fades away the full-range PQ 10bit transfer will be removed from general use (or the 12..12+ bits forms with 'standard moving pictures' narrow range encoding will be used or float).

I forgot to say that I would be using 12-bit which is the recommended bitdepth for minimizing banding, although 12-bit profiles are not existant in x265. I think this may be caused becaused 12-bit is composed of 10-bit + 2-bit dual layer in profile 7.
I don't even have an HDR TV, but I directly see the benefits in details rendition in dark areas after tonemapping.

I don't know why you affirm that PQ is the worst space for over/undershoots, log space which shares the same principles (highlight rolloff) is used in compositing explicitly to avoid over/undershoots, you can read more about it here (https://library.imageworks.com/pdfs/imageworks-library-cinematic_color.pdf#page=37).

[FranceBB]

Because the range of PQ is so large, it is rare for content to contain pixel values near the extremes of the range. Therefore, over-shoots and under-shoots are unlikely to be clipped.

That is correct. Being it a totally logarithmic curve like Slog, Clog, LogC etc, it starts high, so it appears as if it sits in the middle, as shown by the waveform monitor: Img1 (https://i.imgur.com/teEiuao.png) - Img2 (https://i.imgur.com/fP2SS3N.png) - Img3 (https://i.imgur.com/TjRoAm9.png)

so it's highly unlikely values will ever be clipped out.


log space which shares the same principles (highlight rolloff) is used in compositing explicitly to avoid over/undershoots

yep.



I forgot to say that I would be using 12-bit which is the recommended bitdepth for minimizing banding, although 12-bit profiles are not existant in x265.

Uh? there's --profile main12 along with main422-12 and main444-12 afaik (untested, though).


I think this may be caused because 12-bit is composed of 10-bit + 2-bit dual layer in profile 7.


Yeah, you're right, that's the thing, the standard is indeed 10bit only and the only way you have to get 12bit would be via Dolby Vision with dual layer, 'cause if you encode directly to 12bit I have no idea how many hardware decoders are out there, capable of decoding it correctly, unfortunately :(
And it's a shame, really, 'cause most masterfiles are 12bit MJPEG2000 4:4:4 (and rarely some of them DNXHQX 4:2:2 or 4:4:4 12bit), so it would make sense for the public to get something like that rather than a dithered down 10bit version. On the other hand, as long as you're gonna have 1000 nits in PQ, you're gonna be fine with 10bit. The only reason why sometimes in productions you can find pseudo-full-range PQ is that they're trying to take advantage of the extra head given by not having to stay within the narrow range (Limited TV Range) limit to overcome the 10bit limitation and have more stops and therefore more nits. This is a bit like what Sony did for HLG by doing it in 8bit full range, hoping that using all the 255 values of the full range would overcome the limitation and allow people to shoot HLG with 8bit based cameras. They somehow succeeded in the sense that people were no longer stuck on BT709 SDR 100 nits, but the problem was that you couldn't have more than 699 nits (I don't remember how many stops) with full range 8bit HLG, 'cause you needed 10bit to get to 1000 as you didn't physically have enough values to correctly represent the signal. So, in a nutshell, history is repeating itself and I suspect we're gonna have everything in 12bit Narrow Range (Limited TV Range) in not so many years into the future. In SDI this is achieved with something called "multi-link" connection in which you're basically making use of multiple SDI cables working together to create the final output and I think you have MSB and LSB there too but I'm not familiar at all 'cause here in Italy we're stuck with 10bit (although I think the UK side works in 12bit, but I don't know their workflows, so...) ;)

[Selur]

Uh? there's --profile main12 along with main422-12 and main444-12 afaik (untested, though).
I agree 12bit x265 encoding works fine here,...

[Dogway]

Yep sorry, I've been out of touch on encoders for some time, good news then for 12-bit on x265. I think I got it mixed with x265 not supporting IPTPQc2 matrix, not sure if that's possible. Anyway, just waiting for LCEVC support in x265.

[DTL]

"From BT.2408:
Quote:
The full range representation is useful for PQ signals and provides an incremental advantage against visibility of banding/contouring and for processing. Because the range of PQ is so large, it is rare for content to contain pixel values near the extremes of the range. Therefore, over-shoots and under-shoots are unlikely to be clipped."

1. The typical Avisynth processing workflow is not linear domain data but transfer-function domain data. So if applying any 'sharpening' in this domain - it still easy to get over/under shoots below zero (black) and over max system white.

2. I think most of real content have real zero black level (video black and numerical zero in scene light). Not some 'HDR-dark level' converted into far from system black levels code levels in PQ transfer domain. So some sharpening applied to the film-look 'makeup' will cause below-black level undershoots. If using 'full range' with system black code level 0 and resticted negative numbers - it will cause clipping of below-black data undershoots. Also any artificial generated content like 3D render or CG must also have non-zero HDR blacks to follow this idea of non-clipping undershoots in full-range' I not sure if HDR content providers follow this idea. Also if even every HDR content provider uses non-zero HDR darks to save from clipping undershoots below zero code level - it actually creates 'common use HDR non-zero dark that it assumed as HDR black' designed to save from clipping undershoots below zero code level. And this practice will be equal to simply using non-zero code level to encode zero-light level and have footroom for data undershoots.

Due to limitations of physical optics - it never can create zero brightness level at sensor from non-totally dark scene (if scene even do have zero emitting areas like special light traps). So real optical cameras have adjustments to compensate lens glare/flare and increase contrast to 'infinity' adjusting master black to put some scene non-zero black to output black code levels. No any real physical camera can shoot 'bipolar HDR' with increased range below 'standard' and above 'standard'. All 'HDR' is about less clipping of highlights, not about better capturing of low light real scene parts. So the low scene data levels are totally artificial product of glare/flare compensation and manual master black and other camera adjustments (like black stretch and tons of other non-real scene light tricks of camera manufacturers). The real dynamic range of typical lens is about 500 (may be some thousands for outstanding lens) for 'high key scene' and it fit in SDR 8bit good.

The footroom for SDR undershoots below black is about 14/253 - about 5% of total data range and I think it was selected after long debates of the great engineers of the past to make things not very bad. It eats a lot of expensive range but may be add to the quality. So total disabling of undershoots for HDR looks like not good idea.

Also most 'video-look' makeup footage do have significant over/undershoots and samples values may travel below/under system black code level.

" stuck on BT709 SDR 100 nits"

SDR may have recommended something around 100 nits for indoor setups but it is about colour imaging without strict real physical brightness mapping. So SDR content may be viewed greatly at sunlight-viewable outdoor TVs having 2000..4000+ nits many years before the 'HDR hype' was started. Also good SDR display for medium bright room also go far above 100 nits in nominal white. Also to view full SDR of about 1000..3000 in good colours from the darkest areas it is required 1000+nits for nominal white because eye colours sensitivity start degrade below 10 nits and already not great at 1 nit and colours fades out in saturation at about 0.01 nit and below. So the good part of HDR physically mapped PQ range is black and white only for viewer.

[qyot27]

AviSynth+ 3.7.2 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.2)

32-bit MSVC builds were crashing if FFmpeg tried to access frame properties (32-bit GCC builds were unaffected, and so were non-Windows builds). This got fixed, which warranted making a release so users would have a real, working build.

C interface Win32 access: fix issue by adding V8 interface function…
… names to avisynth.def

or else names are decorated (Issue #276)
e.g. DLL published _avs_get_frame_props_ro@8 instead of avs_get_frame_props_ro
ShowRed/Green/Blue/Alpha/Y/U/V: addition to earlier fixes:
When clips are planar and both source and destination format have alpha plane,
then it will be copied instead of filled with 255d.
Additional checking is done for alpha plane size when ShowU/V, because when
source is subsampled the original alpha plane cannot be copied (larger).
ConvertBits:
Does not get frame 0 in constructor for frame properties if 'fulls' is directly specified. (magiblot)
May make script initialization much quicker (Issue #275)
#275
Trim, AudioTrim: bool 'cache' (default true) parameter.
Workaround for Issue #274, lower memory consumption but may be slower.
Benefits heavily depend on how trimmed clips are used later.
Expr: scale_inputs to case insensitive and add floatUV to error message as an allowed value.
propCopy: able to specify that the property list is negative.
bool "exclude" = false # default: "props" is positive list

propCopy(org,true,props=["_Matrix", "_ColorRange"], exclude=false) # merge only two properties
propCopy(org,true,props=["_Matrix", "_ColorRange"], exclude=true) # merge all, except listed ones
propCopy(org,props=["_Matrix", "_ColorRange"]) # erase all then copy only selected
propCopy(org,props=["_Matrix", "_ColorRange"], exclude = true) # erase all, then copy all, except listed ones

Version()
New optional parameters

int length, int width, int height, string pixel_type, clip c

Version clip defaults:
length=240, width = -1, height = -1 (-1: automatically sized to fit for font size 24)
pixel_type = "RGB24"

When 'clip' (a format template) is specified then pixel_type, length,
fps data, width and height are defined from it.
If any additional 'length', 'width', 'height', 'pixel_type' parameter is given, it overrides defaults.
When width and height is given and is <= 0 then it is treated as 'automatic'

Covers feature request Issue #261

BlankClip: allow 'colors' with array size more than the number of actual planes.
If an array is larger, further values are simply ignored.
BlankClip, AddBorders, LetterBox: no A=0 check for non-YUVA
Fade filter family new parameters
int 'color_yuv'
array of float 'colors'
similar to BlankClip
MergeRGB, MergeARGB
add MergeARGB parameter "pixel_type", similar to MergeRGB
accept pixel_type other than packed RGB formats, plus a special one is "rgb"
output format is planar rgb(a) (MergeRGB/MergeARGB) when
pixel_type = "rgb" or
pixel_type is empty and
either input is planar RGB
either input is different from 8 or 16 bits (no packed RGB formats there)
pixel_type is explicitely set to a valid planar rgb constant e.g. "RGBP10"
Accept planar RGB clip in place of input clips and the appropriate color plane is copied from them
Fill alpha channel with zero when MergeRGB output pixel_type format is specified to have an alpha plane
frame property source is the R clip; _Matrix and _ChromaLocation are removed if R is not an RGB clip
PropDelete: accept a non-empty array string as list of property names to remove
Parameter is not optional, and has no name. It can be either a string (as before) or an array of strings
propDelete("_Matrix") # old syntax, still accepted
propDelete(["_Matrix", "_ColorRange"])
PropCopy: new string parameter "props" as list of property names to remove
"props": a non-empty array of strings

old syntax, still accepted:
propCopy(org,true) # merge from all org's properties
propCopy(org,false) # erase all then copy all org's properties (exact copy)
new syntax
propCopy(org,true,props=["_Matrix", "_ColorRange"]) # merge
propCopy(org,props=["_Matrix", "_ColorRange"]) # erase all then copy only selected
Histogram Levels: stop using shades of grey on top of bars.
Histogram Levels: use bar color 255 for RGB instead of Y's 235. (and scaled eqivivalents)
Fix: Histogram "Levels": prevent crash when factor=0.0
Fix: Histogram "Levels": fix regression incorrect "factor" applied for U/V part drawing when format was subsampled (non-444)
Regression since 20160916 r2666 (commit 986e275)
Histogram "Audiolevels" and StereoOverlay to deny planar RGB
Histogram "Luma": support 10-16 and 32 bits
Histogram: give parameter name "factor" and type 'float' for Histogram's unnamed optional parameter used in "Level" mode.
Other modes just ignore this parameter if given.
Fix: Histogram "color" may crash on certain dimensions for subsampled formats.
Regression since 20180301 r2632.
Fix: Histogram "color" and "color2" mode check and give error on Planar RGB
Fix: missing Histogram "color2" CCIR rectangle top and bottom line (black on black)
Regression since 3.6.2-test1 (commit 1fc82f0)
Fix: Compare to support 10-14 bits
was: factor was always using 65535 (2^16-1) instead of (2^bit depth 1)
was: 16 bit luma/rgb color values were used for drawing graph
Fix: Compare
'channels' parameter default to "Y" when input is greyscale;
instead of "YUV" which was giving error because of U and V does not exist for this format.
ShowRed/Green/Blue/Alpha/Y/U/V
support YUY2 input
support YV411 output
(not changed: ShowU/ShowV may give error for 420, 422 or 411 format outputs when clip dimensions are
not eligible for a given output subsampling (check for appropriate mod2 or mod4 width or height)
Copy alpha from source when target is alpha-capable
Fill alpha with maximum pixel value when target is alpha-capable but source ha no alpha component
Delete _Matrix and _ChromaLocation frame properties when needed.
More consistent behaviour for YUV and planar RGB sources.

Default pixel_type is adaptive. If none or empty ("") is given for pixel_type then target format is
YUV444 when source is Y, YUV or YUVA
RGB32/64 (packed RGB) when source is RGB24/32/48/64
RGBP (planar RGB) when source is RGBP or RGBAP

When 'rgb' is given for pixel_type then then target format is

RGB32/64 (packed) when source is RGB24/32/48/64 old, compatible way
RGB planar when source is planar RGB(A) or YUV(A) or Y changed from rgb32/64 because all bit depth must be supported

When 'yuv' is given (new option!) for pixel_type then then target format is

YUV444 for all sources

Also there is a new option when pixel_type is still not exact, and is given w/o bit depth.
pixel_type which describes the format without bit depth is automatically extended to a valid video string constant:

y, yuv420, yuv422, yuv444, yuva420, yuva422, yuva444, rgbp, rgbap

Examples:

32 bit video and pixel_type 'y' will result in "Y32"
16 bit video and pixel_type 'yuv444' will result in "YUV444P16"
8 bit video and pixel_type 'rgbap' will result in "RGBAP8"

Fix #263. Escaping double-quotes results in error
Allow top_left (2) and bottom_left (4) chroma placements for 422 in colorspace conversions, they act as "left" (0, "mpeg2")
in order not to give error with video sources which have _ChromaLocation set to other than "mpeg2"
See https://trac.ffmpeg.org/ticket/9598#comment:5
Fix: Expr LUT operation Access Violation on x86 + AVX2 due to an unaligned internal buffer (<32 bytes)
Fix: Chroma full scale as ITU Rec H.273 (e.g +/-127.5 and not +/-127) in internal converters, ColorYUV and Histogram
Fix #257: regression in 3.7.1: GreyScale to not convert to limited range when input is RGB. Regression in 3.7.1
Accepts only matrix names of limited range as it is put in the documentation.
Fix #256: ColorYUV(analyse=true) to not set _ColorRange property to "full" if input has no such
property and range cannot be 100% sure established. In general: when no _ColorRange for input and
no parameter which would rely on a supposed default (such as full range for gamma), then an
output frame property is not added.
When no _ColorRange for input and no other parameters to hint color range then
gamma<>0 sets full range
opt="coring" sets limited range
otherwise no _ColorRange for output would be set
Overlay (#255): "blend": using accurate formula using float calculation. 8 bit basic case is slower now when opacity=1.0.
Higher bit depths and opacity<1.0 cases are quicker.
Mask processing suffered from inaccuracy. For speed reasons mask value 0 to 255 were handled
as mask/256 instead of mask/255. Since with such calculation maximum value was not the expected 1.0 but rather 255/256 (0.996)
this case was specially treated as 1.0 to give Overlay proper results at least the the two extremes.
But for example applying mask=129 to pixel=255 resulted in result_pixel=128 instead of 129. This was valid on higher bit depths as well.
Note 3.7.2 Test2 has a regression of broken maskless mode for 0<opacity<1 which was fixed in 3.7.2 test 3
Fix: Attempt to resolve deadlock when an Eval'd (Prefetch inside) Clip result is
used in Invoke which calls a filter with GetFrame in its constructor.
(AvsPMod use case which Invokes frame prop read / ConvertToRGB32 after having the AVS script evaluated)
Remark: problem emerged in 3.7.1test22 which is trying to read frame properties of the 0th frame in its constructor.
A similar deadlock situation was already fixed earlier in Neo branch and had been backported but it did not cover this use case.
Note: Prefetch(1) case was fixed in 3.7.2 Test3

[FranceBB]

Nice one, Stephen. I'm gonna update as soon as I get to work ;)

[qyot27]

...and in addition to the builds that went up yesterday, we now have both an installer and a filesonly package for macOS 11 or higher on ARM64/Apple Silicon. I'm still unsure of exactly whether we should refer to it by architecture (ARM64), marketing name (Apple Silicon), or the name of the chip (M1, which the packages for 3.7.2 do use just for brevity, but it won't make much sense once M2, M3, etc. show up).

[Ceppo]

I have a simple request, if it is hard to make no reason to worry about it.

Is possible to have avisynth+ detect 1(...) and 0 as true and false as c++ does? I'm lazy, and I find it more readable.

[wonkey_monkey]

You can use "!=0" to convert a number to boolean in a way that agrees with C++ with only three extra characters (plus possibly a space) ;)

If you're really lazy, I might be able to alter my script modification plugin to do this automatically for you. You'll have to use my Avisynth+ DLL though, and your scripts won't be compatible for other people unless they're also using it.

[Ceppo]

I didn't think about it :eek:, thanks! :cool:

[Ceppo]

If you're really lazy, I might be able to alter my script modification plugin to do this automatically for you. You'll have to use my Avisynth+ DLL though, and your scripts won't be compatible for other people unless they're also using it.
My original intent was to pass a boolean parameter writing 1 or 0 instead of true/false, I don't need it for writing scripts, just to test different parameters... so I'll gladly accept your proposal :D

[wonkey_monkey]

Not quite sure what you're trying to do then, but in any case I was thinking only of tertiary conditionals, so what I had in mind wouldn't work after all.

[Ceppo]

I was in multi tasking mode, so maybe my idea didn't make sense, probably it doesn't.

What I wanted to do was for example,
CTelecine(sse=true) -> CTelecine(sse=1)
Doing this would make my semantic bug hunting less painful. But to do that avisynth would need to convert int to bool if the parameter is bool... so well I don't know if this is legit.

[Selur]

Using latest AviSynth+ 3.7.2

When I use:
ClearAutoloadDirs()
LoadPlugin("I:\INNOIN~1\64bit\Avisynth\AVISYN~1\LSMASHSource.dll")
LoadPlugin("I:\INNOIN~1\64bit\Avisynth\AVISYN~1\MosquitoNR.dll")
LWLibavVideoSource("G:\TESTCL~1\test.avi",cache=false,dr=true,format="YUV420P8", prefer_hw=0)
MosquitoNR()
ConvertToRGB32(matrix="Rec601")
return last
my code crashes when loading the the file:
AVS_linkage = m_env->GetAVSLinkage();
const char* infile = m_currentInput.toLocal8Bit(); //convert input name to char*
std::cout << "Importing " << infile << std::endl;
AVSValue arg(infile);
m_res = m_env->Invoke("Import", AVSValue(&arg, 1)); // <- here it dies
see: https://github.com/Selur/avsViewer/blob/441500fe4f46ece0e48542a61daec95eb019ff3b/avsViewer.cpp#L142
When i use
ClearAutoloadDirs()
LoadPlugin("I:\INNOIN~1\64bit\Avisynth\AVISYN~1\LSMASHSource.dll")
LoadPlugin("I:\INNOIN~1\64bit\Avisynth\AVISYN~1\MosquitoNR.dll")
LWLibavVideoSource("G:\TESTCL~1\test.avi",cache=false,dr=true,format="YUV420P8", prefer_hw=0)
MosquitoNR()
#ConvertToRGB32(matrix="Rec601")
return last
the script is loaded, but when I later invoke ConvertToRGB32 it crashes, there.
see: https://github.com/Selur/avsViewer/blob/441500fe4f46ece0e48542a61daec95eb019ff3b/avsViewer.cpp#L875

Same happens when using just 'version()' as script.

With previous AviSynth+ versions I had the issue the other way around.
32bit failed, 64bit worked (see: https://forum.doom9.org/showthread.php?t=183787)

-> any idea?

Cu Selur