Avisynth+

[StainlessS]

Dont know if below is bugged, or misleading error message, or both.


# OK
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").PointResize(256,256)

# Resize: source image too small for this resize method. Width=1, Support=1.
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").BilinearResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV12").BicubicResize(256,256) # NOTE, YV12, Presumably error for chroma

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").BicubicResize(256,256) # NOTE, YV24

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").Lanczos4Resize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").GaussResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").BlackmanResize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").LanczosResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").sincResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").Spline16Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

Return Last

For eg YV24, width=2, height=2, Says width = 2, Support=2 (when it clearly produces an error message, ie seems not to support 2).

Think its been like this 4E4 (believe it exists as above in avs standard).

EDIT: Presume similar on height, untried.

[raffriff42]

>Dont know if below is bugged, or misleading error message, or both.
misleading I'd say
avs_core\filters\resample_functions.cpp(247)
if (source_size <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method. Width=%d, Support=%d", source_size, int(ceil(filter_support)));
}
EDIT one quick fix if (source_size <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method. Width=%d, Minimum=%d", source_size, int(ceil(filter_support))+1 );
}
So instead ofsource image too small for this resize method. Width=1, Support=1.

you would seesource image too small for this resize method. Width=1, Minimum=2.

[qyot27]

Maybe it's because I'm tired, but if a filter is supposed to support value X (as per filter_support in the code there), it shouldn't be erroring out when equal to the value of filter_support. It only should in the less than case. Unless filter_support is not actually the minimum supported value, but the maximum unsupported value (in which case it being named 'filter_support' in the code is also misleading or incorrect).

In other words, either the operator in the code is wrong (it should be just <, not <=) or the naming of both 'filter_support' and the 'Support' field in the error message are wrong.

[raffriff42]

I'm getting access violations when downsizing inside an Animate call. Maybe it's just my system.
It does not happen in AVS 2.6.1, and it does not happen when "z_" avsresize (https://forum.doom9.org/showthread.php?t=173986) filters are substituted.ColorbarsHD(width=640, height=400)

## optional - these do not change the test result
KillAudio
ConvertToYV12
Trim(0, length=150)

Animate(0, 120, "_MyBlur", 0.0, 60.0)

## optional - make the clip longer so AvsMeter can chew on it
R=Reverse
Last+Reverse
Loop(100)

return Last

function _MyBlur(clip C, float rad)
{
##
## HEART OF THE TEST:
## BilinearResize causes intermittent...
## | Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
## | Module: C:\Windows\system32\KERNELBASE.dll
## | Address: 0x00007FFF071D92FC
## (64-bit)
## or...
## | Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
## | Module: C:\Windows\SysWOW64\avisynth.DLL
## | Address: 0x618064ED
## (32-bit)
## but avsresize "z_BilinearResize" is OK
##
return (rad<0.1) ? C
\ : C.BilinearResize(
\ m4(Float(C.Width)/(rad+1.0)),
\ m4(FLoat(C.Height)/(rad+1.0)))
\ .GaussResize(
\ C.Width, C.Height, p=19)
}

### MOD-4-and-at-least-16 helper function
## @ Didée
function m4(float f)
{
(f<16) ? 16 : Int(Round(f/4.0)*4)
}

[StainlessS]

Did not try z_lib resizers, but your script (as supplied, running for 3 mins) does OK on XP32 bit.

EDIT: OK after redo at 6 mins.

Why this, (Round produces an Int already, you can answer for Didee if you like [did it change in more recent version of Avs])

(f<16) ? 16 : Int(Round(f/4.0)*4)


EDIT: Only relevant mention of round I could find,
Changes from 2.06
Fixed ceil, floor and round functions.


Avs+ thread 1 Million and 25 thousand views since Sept 2013, WOW ! [cookies seem to track if user viewed already].

[pinterf]

I'm getting access violations when downsizing inside an Animate call. Maybe it's just my system.
It does not happen in AVS 2.6.1, and it does not happen when "z_" avsresize (https://forum.doom9.org/showthread.php?t=173986) filters are substituted.
Thanks, reproduced.
EDIT: and fixed on git.

[`Orum]

I'm curious, is it still best practice not to cache frames ever, for any purpose, as this post (https://forum.doom9.org/showthread.php?p=1649886#post1649886) suggests? I'm still running into a few performance issues and I think they may be, at least in part, due to hammering the PCIe bus constantly when moving frames between the CPU and GPU.

[Motenai Yoda]

merge seems broken with 10 12 14 bit clip

[StainlessS]

Yoda, give some example for Pintef, please.

[Motenai Yoda]

Yoda, give some example for Pintef, please.

convertbits(10) #12 or 14
merge(last,0.33)
convertbits(8)

I also notice some memory leak since few releases, with avspmod, it will eat a lot of ram even with few previews after script modifications, but not sure is an avs+ bug or avspmod or other filter. It usually thrown an out of memory error like "can't access frame at this position" and then I get even some windows stuff not working well.

[`Orum]

I also notice some memory leak since few releases, with avspmod
I noticed something similar with ThrowError() and a lot of text, where AvsPmod (and not AviSynth+ I think--I'll have to test in another app when I have time) would essentially turn into this:
for(;;)
malloc(1000000);
In any case I would never assume leaks or bugs are in AviSynth+ by testing with only AvsPmod, considering how insanely buggy AvsPmod alone is.

[TheFluff]

I noticed something similar with ThrowError() and a lot of text, where AvsPmod (and not AviSynth+ I think--I'll have to test in another app when I have time) would essentially turn into this:
for(;;)
malloc(1000000);
In any case I would never assume leaks or bugs are in AviSynth+ by testing with only AvsPmod, considering how insanely buggy AvsPmod alone is.

If AvsPmod attempts to catch an exception thrown from inside Avisynth (for example, if a plugin raises an error using Avisynth's ThrowError), then yes, it'll most likely leak the exception object (if the catch actually works at all, which isn't certain either). Attempting to catch an exception from across a DLL boundary should in general never be done. It is only safe if both sides are built with the exact same compiler and linked with exactly the same runtime, but even then, just don't. Avisynth API calls should never be wrapped in try/catch blocks. See this (http://avisynth.nl/index.php/Avisynthplus/Developers) article on the wiki.

[`Orum]

it'll most likely leak the exception object
That still doesn't explain why it would endlessly allocate memory until it couldn't any more.

Anyway, the point was that at the very least AvsP[mod] shouldn't be a test for memory leaks from AviSynth+. It should be tested with something a lot more stable, e.g. VirtualDub, avs2yuv, AVSmeter, etc. And even then, to make sure the leak is within AviSynth+ itself one should avoid external filters.

[pinterf]

New build with important fixes and some minor tweaks. Thanks for the reports.
Download Avisynth+ r2664-MT
(https://github.com/pinterf/AviSynthPlus/releases/tag/r2664-MT)

In this changelog I left there intentionally some lines about a finally postponed modification. Read it as a preliminary info (32 bit float YUV chroma format). We could start a discussion about it.

20180328 r2664
--------------
- Fix: YUY2 Sharpen overflow artifacts - e.g. Sharpen(0.6)
- Fix: Levels: 32 bit float shift in luma
- Fix: Merge sse2 for 10-14bits (regression)
- Fix: AVX2 resizer possible access violation in extreme resizes (e.g. 600->20)
- Fix: 32bit float PlanarRGB<->YUV conversion matrix
- Fix: VfW: fix b64a output for OPT_Enable_b64a=true
- Enhanced: VfW output P010 and P016 conversion to SSE2 (VfW output is used by VirtualDub for example)
- Enhanced: ColorYUV: recalculate 8-16 bit LUT in GetFrame only when changed frame-by-frame (e.g. in autowhite)
- Enhanced: ConvertBits 32->8 sse2/avx2 and 32->10..16 sse41/avx2 (8-15x speed)

Not included, preliminary for the near future:
- Big change: 32 bit float YUV formats, U and V are now zero based.
Internally YUV 32 bit float chroma center became 0.0 (the neutral value which is 128 in the 8-bit world)
Like in VapourSynth or in avsresizer using z.lib image library.
'Expr' changes are affecting built-in constants/operators when used in chroma plane of a 32bit clip.
- 'cmin', 'cmax' return the zero-based shifted versions of the 16 and 240 (8 bit) values
- For U and V planes, constant 'range_half' results in 0.0 instead of the old 0.5
- 'scaleb' will also give zero-based result when found in an expression for chroma plane
(e.g. for a 32 bit float clip the '128 scaleb' will result in 0.0 instead of 128/255 for U and V planes)
But 'scalef' when the target or source of the constant conversion is 32bits, remains independent from the plane type.
- 'range_max' is 0.5 for 32 bit float chroma
- new constant 'range_min', which is -0.5 for 32 bit float chroma, (0 otherwise)

Additional warning: when you move 32bit float U or V plane to Y using CombinePlane, you have to be sure
that your filters do not rely on this new Y plane being in 0..1 range. Or else convert it by using Expr("x 0.5 +") to the 0..1 range
Similarly: ExtractU and ExtractV will simply return the unaltered chroma planes, which are now zero-centered

[GMJCZP]

Thanks for the update.
I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

[`Orum]

Are variables not cached along with frames? For example (forgive the obvious assumptions made, it's just to illustrate the problem):
#define MAX_DELTA 1

for(int f = 0; f < 100; f++) {
PVideoFrame vf = clip->GetFrame(f, env);

strstream dbg;
dbg << env->GetVarDef("FFPICT_TYPE", AVSValue('?')).AsInt() << ends;
OutputDebugStringA(dbg.str());
dbg.freeze(false);

for(int n = 1, n <= MAX_DELTA; n++)
foo(vf, clip->GetFrame(f + n, env)); // What foo() does isn't really relevant here, just know that it doesn't request any frames
}
If you raise MAX_DELTA, you suddenly get different output for your FFPICT_TYPE vars! This could also be a bug in FFVideoSource() but it seems more likely (to me, anyway) that the variables set when a frame is retrieved are not cached and restored when that frame is requested again and returned from AviSynth+'s cache later on. So, is that the case?

Edit: I can write my own filter in order to rule out (or in) FFVideoSource() as the problem if you'd like.

[pinterf]

Avisynth has no frame properties like Vapoursynth has. The method of filling the variable is a workaround hack which probably works only when the variable is constant.
You can define a filter to NonCachedGenericVideoFilter, like Reverse or Loop (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/edit.h#L220) works internally.

[`Orum]

The method of filling the variable is a workaround hack which probably works only when the variable is constant.
Ah, that's unfortunate. I don't suppose there's any chance this will change in the future?
You can define a filter to NonCachedGenericVideoFilter
Correct me if I'm wrong but this won't fix the issue if, for example, you have a script like this:
FFVideoSource("foo.mkv")
bar()
myfilter()
If bar() is someone else's filter that's cached and does frame requests outside of the current frame, my filter would still have issues getting the correct FFPICT_TYPE, right?

Edit: Now that I think about it, even if AviSynth+ cached these it would still require the earlier filter to do the request for any non-offset frames last. For instance, if you think about a filter that does a temporal blend of frame 'f' with radius 'x' (forward and backward), it would still have to request frame 'f' last and not frame 'f + x' to get the variable correct. It seems like a better solution is to either parse the the FFVideoSource() cache (if that even contains the picture types), or the source file itself, but neither is friendly if there's a simple Trim() in the script before it hits myfilter(). :( In any case, there's no general solution, as even the idea of a picture type disappears with any temporal filtering.

[GMJCZP]

I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

Someone?

[poisondeathray]

Thanks for the update.
I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

Someone?

No problems here.

[LigH]

Nope. Via Deutsche Telekom, immediate appearance of avisynth.nl and github.com; possibly your provider?

[GMJCZP]

And how are you doing with the download speed by GitHub, LigH?

[LigH]

70 KB (MABS) go quickly ... do you know any with a large package?

OK, MPC-HC (14 MB): faster than I can confirm the target directory.

[GMJCZP]

It must be my provider, thanks.

[tormento]

@pinterf

Would you please add to ConvertBits the same dithering modes Ditherpost has? At least the most significative ones, i.e. 0 (ordered+noise),6,7,8.

[magiblot]

Thanks for the update.
I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

I can't enter AviSynth.nl from Spain. Server does not reply. I have to use Google's cached version or a free proxy. There are periods of time where it works again for me, but not currently.

[Motenai Yoda]

@pinterf

Would you please add to ConvertBits the same dithering modes Ditherpost has? At least the most significative ones, i.e. 0 (ordered+noise),6,7,8.

actually:
dither=-1 (default) -> mode=-1 aka round to int (or truncate?)
dither=0 -> mode=0 aka ordered dithering
dither=1 -> mode=6 aka Floyd-Steinberg

[StainlessS]

Magiblot,

Test DNS servers and settings for a domain name

http://dnscheck.pingdom.com/?domain=avisynth.nl

Test finished successfully, no errors or warnings.

Must be something wrong between you and Avisynth.nl (works just fine for me).

EDIT: IsItDownRightNow (OK)
https://www.isitdownrightnow.com/avisynth.nl.html

[tormento]

actually:

dither=-1 (default) -> mode=-1 aka round to int (or truncate?)

dither=0 -> mode=0 aka ordered dithering

dither=1 -> mode=6 aka Floyd-Steinberg

From Wiki:
int dither
If 0, add ordered dither; if -1 (default), do not add dither

Is it outdated?

[raffriff42]

From Wiki: [...] Is it outdated?Yes, it was outdated... thx, fixed now.
https://www.dropbox.com/s/xl6nzwst0ioso65/dither-2018-03-01.png?raw=1

https://www.dropbox.com/s/s3ameoyc8dytt8e/dither-2018-03-02.png?raw=1

https://www.dropbox.com/s/zcx7twt1bea78t8/dither-2018-03-03.png?raw=1

ColorBarsHD(pixel_type="YUV444P16")
Crop(300, 440, 816, 80)
ColorYUV(cont_y=0.1, cont_u=0.1, cont_v=0.1, f2c=true)
Interleave(
\ ConvertBits(8, dither=-1).Subtitle("dither=-1") [* no dither *]
\ , ConvertBits(8, dither=0).Subtitle("dither=0") [* ordered dither *]
\ , ConvertBits(8, dither=1).Subtitle("dither=1") [* Floyd-S *]
\ )
ColorYUV(cont_y=10.0, cont_u=10.0, cont_v=10.0, f2c=true)
return Last

[Motenai Yoda]

maybe pinterf account it still as experimental as IIRC floyd returns 2^N +1 shades, 0 + 2^N shades up to range_max

[magiblot]

Magiblot,

Test DNS servers and settings for a domain name

http://dnscheck.pingdom.com/?domain=avisynth.nl



Must be something wrong between you and Avisynth.nl (works just fine for me).

EDIT: IsItDownRightNow (OK)
https://www.isitdownrightnow.com/avisynth.nl.html

Here's my traceroute to avisynth.nl (tracert command on Windows):
traceroute to avisynth.nl (82.150.137.175), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.607 ms 5.277 ms 5.131 ms
2 168.red-81-46-38.customer.static.ccgg.telefonica.net (81.46.38.168) 5.098 ms 5.079 ms 5.031 ms
3 221.red-81-46-34.customer.static.ccgg.telefonica.net (81.46.34.221) 5.005 ms 225.red-81-46-34.customer.static.ccgg.telefonica.net (81.46.34.225) 4.997 ms 221.red-81-46-34.customer.static.ccgg.telefonica.net (81.46.34.221) 26.302 ms
4 * * *
5 50.red-80-58-81.staticip.rima-tde.net (80.58.81.50) 26.251 ms 26.179 ms 26.173 ms
6 et-4-0-0-400-grtbcnes1.net.telefonicaglobalsolutions.com (213.140.50.244) 4.795 ms 21.423 ms 3.039 ms
7 176.52.251.237 (176.52.251.237) 12.692 ms 12.694 ms 12.526 ms
8 176.52.251.213 (176.52.251.213) 12.623 ms 213.140.33.252 (213.140.33.252) 14.049 ms 213.140.33.249 (213.140.33.249) 13.141 ms
9 94.142.107.37 (94.142.107.37) 13.955 ms 11.986 ms 5.53.5.74 (5.53.5.74) 12.586 ms
10 94.142.97.138 (94.142.97.138) 11.507 ms xe-9-3-3.cr2-ams1.ip4.gtt.net (89.149.180.117) 51.350 ms 94.142.97.138 (94.142.97.138) 12.498 ms
11 atom86-gw.ip4.gtt.net (77.67.72.67) 43.810 ms 40.651 ms 94.142.107.37 (94.142.107.37) 12.848 ms
12 xe-9-3-3.cr2-ams1.ip4.gtt.net (89.149.180.117) 46.916 ms a572.datact.atom86.net (95.142.96.179) 42.362 ms 41.976 ms
13 atom86-gw.ip4.gtt.net (77.67.72.67) 40.117 ms * 39.640 ms
14 a572.datact.atom86.net (95.142.96.179) 41.511 ms * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

The IP packets die at a572.datact.atom86.net (95.142.96.179). I obtained the same result by using online traceroute tools (http://www.monitis.com/traceroute/, https://www.ultratools.com/tools/traceRoute). We should open a separate thread for this or contact the webmaster of avisynth.nl (I don't know who they are).

[StainlessS]

Tracing route to avisynth.nl [82.150.137.175]
over a maximum of 30 hops:

1 1 ms 1 ms 6 ms 192.168.100.1
2 * * * Request timed out.
3 60 ms 66 ms 76 ms 172.23.192.145
4 75 ms 40 ms 58 ms 172.30.146.163
5 48 ms 59 ms 59 ms 188.31.255.42.threembb.co.uk [188.31.255.42]
6 47 ms 56 ms 61 ms 188.31.255.85.threembb.co.uk [188.31.255.85]
7 57 ms 59 ms 59 ms 188.31.255.117.threembb.co.uk [188.31.255.117]
8 57 ms 61 ms 59 ms 188.31.255.154.threembb.co.uk [188.31.255.154]
9 66 ms 65 ms 57 ms 188.31.255.170.threembb.co.uk [188.31.255.170]
10 55 ms 61 ms 54 ms ae26-65.cr0-lon1.ip4.gtt.net [46.33.78.5]
11 59 ms 66 ms 80 ms et-2-1-0.cr2-ams1.ip4.gtt.net [141.136.105.89]
12 80 ms 79 ms 79 ms atom86-gw.ip4.gtt.net [77.67.72.67]
13 51 ms 39 ms 71 ms a572.datact.atom86.net [95.142.96.179]
14 74 ms 77 ms 79 ms mysmt175.mysmt.net [82.150.137.175]

Trace complete.


Tracert on mine is pretty slow, but I get straight to site via browser (even after IpConfig/flushdns).

EDIT: Above using OpenDNS resolver.

EDIT: Depending upon how your Firewall is set up, you may need to provide filewall access to multiple DNS servers (I allow about
6), and I use Nirsoft QuickDNS to switch DNS via hotkey (easy peasy):- https://www.nirsoft.net/utils/quick_set_dns.html

[raffriff42]

This browser stuff is way off topic, but I had a similar problem which I solved by manually adding a new DNS server (https://iihelp.iinet.net.au/Manually_Setting_DNS_Server). There is a selection of free DNS servers here (https://www.lifewire.com/free-and-public-dns-servers-2626062).

[`Orum]

I'm curious, what's the rationale behind fulls=false as the default for YUV when using ConvertBits()?

Edit: I ask mainly for up-converting, as e.g. white in 8 bit (255) is no longer truly white when in 10+ bit without fulls=true, it's just very close to true white (i.e. UCHAR_MAX << (BitsPerComponent() - 8)).

[poisondeathray]

I'm curious, what's the rationale behind fulls=false as the default for YUV when using ConvertBits()?

Edit: I ask mainly for up-converting, as e.g. white in 8 bit (255) is no longer truly white when in 10+ bit without fulls=true, it's just very close to true white (i.e. UCHAR_MAX << (BitsPerComponent() - 8)).


"Video white" or legal range white, no longer becomes legal range white if you use fulls=true. In 10bit video, legal Y should be 64 to 940 . ie. the 8bit "235" should "map" to 10bit "940" . You could argue that "legal range" video usage case is more common

[foxyshadis]

I'm curious, what's the rationale behind fulls=false as the default for YUV when using ConvertBits()?

Edit: I ask mainly for up-converting, as e.g. white in 8 bit (255) is no longer truly white when in 10+ bit without fulls=true, it's just very close to true white (i.e. UCHAR_MAX << (BitsPerComponent() - 8)).

The lower bound of the upsampled white point is always white in video standards. For 10-bit full range, that means 1020 and 1023 are the same full white, as are 940+ in limited range. BT.2020 defines the hard peak as 940. Engineers worried about that exact problem and decided that a simple bitshift would always be correct.

This isn't true for HDR, but that's an entirely different ballgame.

[`Orum]

The lower bound of the upsampled white point is always white in video standards.
Interesting. It seems a bit counter-intuitive that different values would have the same output, outside of limited-range clips
This isn't true for HDR, but that's an entirely different ballgame.
...but how can a decoder possibly differentiate between a 10-bit HDR clip and a 10-bit clip from the video standards? I seems to me like the standards conflict; e.g. a HDR clip would assume 1023 != 1020 but if decoded as a "standards compliant" clip the white point would be clippped to 1020.

Edit: Granted, none of this matters if you're only using 10-bit to reduce quant error, but it's interesting nonetheless.

[foxyshadis]

...but how can a decoder possibly differentiate between a 10-bit HDR clip and a 10-bit clip from the video standards? I seems to me like the standards conflict; e.g. a HDR clip would assume 1023 != 1020 but if decoded as a "standards compliant" clip the white point would be clippped to 1020.

Edit: Granted, none of this matters if you're only using 10-bit to reduce quant error, but it's interesting nonetheless.

The decoder is only producing those 941 or 1023 values, it has no input on what's done afterward. The metadata tells the YUV->RGB converter what formula to use and where to saturate. If the converter sees YUV 990,512,512 (assuming BT.709), it'll still output 255,255,255 or 1023,1023,1023. We call that a blown-out highlight.

HDR is different because now 990,512,512 can actually mean something useful; it's often converted to a floating point value that's scaled against the display's actual white point before being converted into raw RGB to display. 900 may convert to only 600 if a display can produce blinding enough whites. That's why it has to be signaled, there's no way to infer what white point was meant out of raw pixel values other than assuming. Some HDR schemes still saturate at limited range, and simply rescale everything within it; some place the rec.709 white point at the end of the TV range and everything outside of it is special. The former is more common.

[`Orum]

The metadata tells the YUV->RGB converter what formula to use and where to saturate.
Ah, I didn't realize there was a flag in the format to indicate it had been upsampled instead of a native/HDR clip.
:thanks:

[bxyhxyh]

I found a bug, when I was trying to minimize rounding errors of resize.blur.blur.blur.resize.sharpen.sharpen.sharpen.sharpen kind of script.

source
https://i.imgur.com/3ZWGafM.png

source.Spline16Resize(512,384)
https://i.imgur.com/cMSAK4G.png

source.ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()
https://i.imgur.com/7ZUX4ee.png

All resizers and all target resolutions are the same.

[poisondeathray]

source.ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()



I get different results than you. They are the same (or very similar) for me. What version of avisynth+?

[bxyhxyh]

Avisynth+ 0.1 r2636.
Ok I checked the release page. It was 2664.
I'm gonna see that.

[poisondeathray]

Try updating?
I'm using r2664 x64

[bxyhxyh]

Ok. Checked it, it was the same for r2664 x86. Maybe something might be wrong with my end.
I'll try full installer.

[poisondeathray]

The other difference is x86 vs x64 ?

[bxyhxyh]

Switched to x64 version, still same.
Updated all in one microsoft redistributable, no change.

[poisondeathray]

Switched to x64 version, still same.
Updated all in one microsoft redistributable, no change.

can you confirm with version() ?

[Groucho2004]

I can reproduce it. Adding a simple "ConvertToYV12()" (or YV16/YV24) after the source filter (I used "ImageSource()") fixes it.

[poisondeathray]

I can reproduce it. Adding a simple "ConvertToYV12()" (or YV16/YV24) after the source filter (I used "ImageSource()") fixes it.

But that's a problem...

I used ImageSource() too , and it returns RGB24 on the source PNG (as expected)

And I can't reproduce it in RGB24, or YV12, or YV16, or YV24