z.lib resizers for AviSynth+ [Archive] - Page 3

poisondeathray

30th March 2020, 23:12

I asked here https://forum.doom9.org/showpost.php?p=1905691&postcount=69

z_ConvertFormat(colorspace_op="470bg:470bg:470bg:limited=>709:709:709:limited",dither_type="ordered")

give dark output, is this normal or it bug?

Expected result

The original colormatrix() only changes the matrix, nothing else.

You are are telling avsresize to change matrix, transfer and primaries

real.finder

30th March 2020, 23:19

Expected result

The original colormatrix() only changes the matrix, nothing else.

You are are telling avsresize to change matrix, transfer and primaries

so z_ConvertFormat should be better, right?

but it's not as fast as colormatrix, is it because colormatrix only change matrix?

poisondeathray

30th March 2020, 23:26

so z_ConvertFormat should be better, right?

"better" in what way?

For HD/SD , the standard of practice is actually to only change matrix . (Not for UHD). For matrix, 470bg and 170m have the same value (SD, 601) . 709 does not

Transfer function value is the same for 601/709 .

Primaries are slightly different between 601/709 .

The list is in the h265 document . Table E4.

But you check with other programs, resolve, premiere , dozens of others, only matrix is ever adjusted. The colors will be slightly shifted in media players, other programs, hardware, displays, AV equipment if you adjust for the primaries - even though it's technically more correct

but it's not as fast as colormatrix, is it because colormatrix only change matrix?

I don't know why one is faster

Quality wise colormatrix can produce more pronounced banding artifacts under some conditions. It's more visible in cartoons and anime .

real.finder

8th April 2020, 02:13

"better" in what way?

For HD/SD , the standard of practice is actually to only change matrix . (Not for UHD). For matrix, 470bg and 170m have the same value (SD, 601) . 709 does not

Transfer function value is the same for 601/709 .

Primaries are slightly different between 601/709 .

The list is in the h265 document . Table E4.

But you check with other programs, resolve, premiere , dozens of others, only matrix is ever adjusted. The colors will be slightly shifted in media players, other programs, hardware, displays, AV equipment if you adjust for the primaries - even though it's technically more correct

I don't know why one is faster

Quality wise colormatrix can produce more pronounced banding artifacts under some conditions. It's more visible in cartoons and anime .

I mean better for HD <-> SD convert

also I know colormatrix can produce more pronounced banding artifacts since it 8bit

I did post another time there https://forum.doom9.org/showthread.php?p=1905976#post1905976

z_ConvertFormat(colorspace_op="470bg:601:170m:limited=>709:709:709:limited",dither_type="ordered")

seems fine but aside from matrix how one know for sure the color info in DVD? or if I cap from VHS

and aside from that, can we have update for avsresize? https://forum.doom9.org/showthread.php?p=1906749#post1906749

and since the documentation is kinda shortened, is avsresize has all Dither_resize16/fmtconv features like kernel inversion mode and additional Kernels?

poisondeathray

8th April 2020, 02:46

also I know colormatrix can produce more pronounced banding artifacts since it 8bit

It's not just an 8bit thing; there are some weird noise patterns enhanced by colormatrix on some anime. If you check by disable dithering and use 8bit with zimg, it's still more pronounced with colormatrix . Haven't seen the issue on live action content , it's probably hidden by natural noise and grain

z_ConvertFormat(colorspace_op="470bg:601:170m:limited=>709:709:709:limited",dither_type="ordered")

seems fine but aside from matrix how one know for sure the color info in DVD? or if I cap from VHS

No way to know for sure.

If you assume the colors are correct on the DVD in the first place, you're asking the wrong question. You should be asking what method is your viewing hardware or software using to convert back to RGB for display ? ie. is it using something like ConvertToRGB24(matrix="rec709") ? Because that accounts for matrix only . If you adjust for primaries the colors will be shifted for the HD version when viewing on that hardware or software

I would only adjust matrix, unless you knew primaries were adjusted and the SD image is wrong in the first place

I would always use full=>full . I thought it was a no-op limited=>limited, but it makes a difference on the brightest
and darkest pixels if you look closely . Detectable with metrics too

and aside from that, can we have update for avsresize? https://forum.doom9.org/showthread.php?p=1906749#post1906749

I would like update too, but I don't know how to compile it

and since the documentation is kinda shortened, is avsresize has all Dither_resize16/fmtconv features like kernel inversion mode and additional Kernels?

No ; and available kernels are only the common ones and they are listed in the readme

pinterf

8th April 2020, 07:44

zimg integration is on my roadmap but not in the very near future

StvG

8th April 2020, 08:32

Here update (https://cloud.owncube.com/s/DjHxaH7YdEieY3s) (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.

MeteorRain

8th April 2020, 09:17

seems fine but aside from matrix how one know for sure the color info in DVD? or if I cap from VHS

Some DVD mastering company can't even resize the image correctly (like SAR and over scan stuff). Some staff probably don't even have the skills that we have. God knows how they converted the colors.:sly:

pinterf

8th April 2020, 12:14

Here update (https://cloud.owncube.com/s/DjHxaH7YdEieY3s) (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.
Thanks. Do you have a github link (also for addgrain stuff), it's hard to follow the changes (and to give you the proper credits on a re-use).

poisondeathray

8th April 2020, 15:25

Reel.Deel

8th April 2020, 17:06

Here update (https://cloud.owncube.com/s/DjHxaH7YdEieY3s) (zimg@5896a26). Added few things (cpu_type, nominal_luminance, approximate_gamma, alpha plane). Check readme for more info.

Thank you for the update StvG!

Not long ago I added documentation to the wiki: http://avisynth.nl/index.php/Avsresize

I'll will update the documentation with the things that were added.
I see that compatibility aliases "gauss", "lanczos4", "blackman", "sinc" were removed. And also z_BlackmanResize(), z_GaussResize(), z_SincResize() are gone. I know these essentially did nothing since they are just aliases, will they be gone forever?

Stereodude

8th April 2020, 17:32

Thank you for the update StvG!

Not long ago I added documentation to the wiki: http://avisynth.nl/index.php/Avsresize

I'll will update the documentation with the things that were added.
I see that compatibility aliases "gauss", "lanczos4", "blackman", "sinc" were removed. And also z_BlackmanResize(), z_GaussResize(), z_SincResize() are gone. I know these essentially did nothing since they are just aliases, will they be gone forever?
It would be nice if you could list the terminology of all the allowed color formats in the wiki or if the plug-in aligned its accepted naming with Avisynth+'s terms. It will not accept some of the names used by AVIsynth+ (http://avisynth.nl/index.php/Avisynthplus_color_formats).

Like using RGBP8 gives you a bad pixel type error. It looks like it wants RGBP, not RGBP8.

StainlessS

8th April 2020, 21:45

The affected ones look to all have entries in the Remarks column. [ RGBP vs RGBP8, on wiki:- http://avisynth.nl/index.php/Avisynthplus_color_formats ]
Oops, wrong link, FIXED.

StvG

9th April 2020, 08:29

Thanks. Do you have a github link (also for addgrain stuff), it's hard to follow the changes (and to give you the proper credits on a re-use).

Sorry, I don't have any github links.

Thank you for the update StvG!

Not long ago I added documentation to the wiki: http://avisynth.nl/index.php/Avsresize

I'll will update the documentation with the things that were added.
I see that compatibility aliases "gauss", "lanczos4", "blackman", "sinc" were removed. And also z_BlackmanResize(), z_GaussResize(), z_SincResize() are gone. I know these essentially did nothing since they are just aliases, will they be gone forever?
IMO, yes, they are gone "forever" unless zimg adds support for them. For example I had a version compiled without spline64 too (spline64 was spline32 alias) but when zimg added spline64 (https://github.com/sekrit-twc/zimg/commit/6ffe4b162f7e71dbd13428bc3e9542ac17646e44), I added back spline64.

Btw on the wiki page chromaloc_op "top_left" is missing.

FranceBB

9th April 2020, 10:22

Some staff probably don't even have the skills that we have. God knows how they converted the colors.:sly:

You mean morons who don't know how to do these things?
They do it via hardware, mostly.
The reason? They have little to no clue about what they're doing as they're just operators that someone put there and they don't know how to code or use pseudo-scripting softwares like Avisynth, BUT they strictly follow a procedure that someone not too incompetent put in place several years ago back when there was no software at all.
It generally involves a play port (like the Omneon ones), a resizing hardware converter (Evertz and similar), a Softel/Cavena for subtitles and either a DVD itself or a Rec Port.
They generally put the colorbars, then the file, then black at the end, then they route the signal from the playback port to the converter and from the converter to the Softel or Cavena which "plays" the subtitles according to the timecode read from the SDI port and it places it in the inactive lines of the stream while playing and from there to either the DVD itself or to a Rec Port which records the file that is going to be mastered to the DVD.

Stone age at its best as it could be easily done in a fraction of the time with Avisynth or literally anything that isn't from decades ago, but I've seen it with my eyes and years ago I was one of the people who had to do it this way (i.e I was forced to do it this way) because of "sacred procedures"... -.-

Reel.Deel

9th April 2020, 15:47

IMO, yes, they are gone "forever" unless zimg adds support for them. For example I had a version compiled without spline64 too (spline64 was spline32 alias) but when zimg added spline64 (https://github.com/sekrit-twc/zimg/commit/6ffe4b162f7e71dbd13428bc3e9542ac17646e44), I added back spline64.

Btw on the wiki page chromaloc_op "top_left" is missing.

I've updated the wiki to match these changes and added chromaloc_op "top_left" :thanks:

Reel.Deel

22nd April 2020, 18:46

It would be nice if you could list the terminology of all the allowed color formats in the wiki or if the plug-in aligned its accepted naming with Avisynth+'s terms. It will not accept some of the names used by AVIsynth+ (http://avisynth.nl/index.php/Avisynthplus_color_formats).

Like using RGBP8 gives you a bad pixel type error. It looks like it wants RGBP, not RGBP8.

Done: http://avisynth.nl/index.php/Avsresize#z_ConvertFormat

-----

@StvG

Any thoughts on adding YUV420P8, YUVA420P8, YUV422P8, YUVA42AP8, YUV444P8, YUVA444P8, RGBP8, RGBAP8 aliases?

StvG

23rd April 2020, 21:45

Here r1e (https://cloud.owncube.com/s/a2Jg7j4ojEKkYoD):
- zimg@8815111;
- added pixel type RGBP8, RGBAP8, YUV444, YUV444P8, YUVA444P8, YUV422, YUV422P8, YUVA422P8, YUV420, YUV420P8 , YUVA420P8, YUV411, YUV411P8;
- added version.

Reel.Deel

27th April 2020, 08:11

:thanks: StvG

I updated the wiki accordingly.

Losko

12th August 2020, 22:00

Added a few tiny fixes, and now I can run avsresize filer as a dynamic library libavsresize.so with avs+ 3.6.1-git natively on my debian box.
I checked resize and color space conversion, everything seems to be fine.

how to build:
g++ -Wall -Wextra -O2 -std=c++17 -fPIC -c -o avsresize.o avsresize.cpp
g++ -s -shared -o libavsresize.so avsresize.o -lzimg

===============================================================================
--- avsresize.orig.cpp 2020-04-23 19:48:21.000000000 +0200
+++ avsresize.cpp 2020-08-11 21:22:33.716137465 +0200
@@ -9,7 +9,22 @@
#include <regex>
#include <string>
#include <malloc.h>
+#ifdef _WIN32
#include "avisynth.h"
+#else
+#include <avisynth/avisynth.h>
+#define _aligned_free free
+#define __int64 int64_t
+/* gnu libc offers the equivalent 'aligned_alloc' BUT requested 'size'
+ has to be a multiple of 'alignment' - in case it isn't, I'll set
+ a different size, rounding up the value */
+#define _aligned_malloc(s,a) ( \
+ (s%a)? \
+ aligned_alloc(a,(s/a+1)*a) \
+ : \
+ aligned_alloc(a,s) \
+ )
+#endif
#include "zimg++.hpp"

namespace {

StvG

26th August 2020, 15:59

avsresize_r1f (https://cloud.owncube.com/s/XCLyRtnysGXY92c) - added @Losko patch, zimg v3.0.1, added support for frame properties.

hello_hello

26th August 2020, 17:05

Thank you!

kedautinh12

26th August 2020, 18:17

Thanks

real.finder

2nd October 2020, 18:44

avsresize_r1f (https://cloud.owncube.com/s/XCLyRtnysGXY92c) - added @Losko patch, zimg v3.0.1, added support for frame properties.

pinterf said that frame properties are just copyied not really used https://github.com/AviSynth/AviSynthPlus/issues/189#issuecomment-701993847

StvG

3rd October 2020, 07:49

pinterf said that frame properties are just copyied not really used https://github.com/AviSynth/AviSynthPlus/issues/189#issuecomment-701993847

I didn't mention anything specific than a general support (copying of frame properties).

avsresize_r1g (https://cloud.owncube.com/s/rqiwDJT7dncATgr) - added parameter prefer_props; read and set _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries frame properties; added chromaloc_op parameters - bottom_left and bottom.
For more info check the included README.md.

real.finder

6th October 2020, 18:27

I didn't mention anything specific than a general support (copying of frame properties).

avsresize_r1g (https://cloud.owncube.com/s/rqiwDJT7dncATgr) - added parameter prefer_props; read and set _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries frame properties; added chromaloc_op parameters - bottom_left and bottom.
For more info check the included README.md.

thanks, and I think there are no source call support frame properties yet, even ffms2 (it still use old global) except https://github.com/Asd-g/RawSource_2.6x/commit/13a0fd8119bc74f92b126bda6653af08a4ccb7d3

real.finder

8th October 2020, 08:31

can we have "auto" in colorspace_op input and "same" in output?

colorspace_op="auto:auto:auto:auto=>same:same:same:f"

the "auto" see if there are frame properties first and if there are no frame properties for the parameter it will use presupposed value based on video informations like resolution and fps

and "same" will use the input value

pinterf

9th October 2020, 10:41

StvG

13th October 2020, 18:57

real.finder

14th October 2020, 01:48

but "auto" make things easier for user

StvG

14th October 2020, 18:39

real.finder

15th October 2020, 03:15

avsresize_r2 (https://cloud.owncube.com/s/jfDf8rERkxEFTqW) - added keyword 'same' for destination matrix, transfer, primaries, range, chromaloc_op.
When it's used the source value (argument or frame property) is used for destination too.

thanks, so since auto not added, I think prefer_props need to be set to true so user can set something like this

colorspace_op="709:709:709=>709:709:709", prefer_props=true

and since prefer_props=true the it will use the frame properties and ignore the input 709:709:709=>

right?

StvG

15th October 2020, 05:32

Sorry for avsresize_r2. I was negligent.

avsresize_r3 (https://cloud.owncube.com/s/f6rQEcCLA95jZMN): - removed parameter prefer_props;
- added keyword "auto" for source matrix, transfer, primaries, range. When it's used the corresponding input frame properties are used, if such frame properties don't exist either an error is raised or default matrix and color range are used;
- added keyword "auto" for source chromaloc_op. When it's used the corresponding input frame property is used, if such frame property doesn't exist default chromaloc is used.

If colorspace_op is not defined and there are frame properties, they are used for default source values.
If colorspace_op is not defined and there are no frame properties or they are not supported, default values are used as before (there are default values for matrix, range and chromaloc).
If colorspace_op is defined and you want to use the frame property for a source value, use "auto".
If colorspace_op is defined and you use "auto" without frame property, the default value for that argument will be used if exist.
If you use "auto" for argument with frame property that has value of 2 (unspec) and use anything different than "same" for destination, error will be raised.
If you use "auto=>same" for matrix/transfer/primaries with frame property 2 (unspec) and you want to make colorspace conversion, error will be raised. For example:#transfer property has value of 2
#primaries 709 (1)
#input yv12
z_convertformat(pixel_type="rgbp", colorspace_op="auto:auto:709=>rgb:same:470bg") # error raised
#z_convertformat(pixel_type="rgbp", colorspace_op="auto:709:709=>rgb:709:470bg") # ok
#z_convertformat(pixel_type="rgbp", colorspace_op="auto:709:auto=>rgb:same:470bg") # ok
#z_ConvertFormat(colorspace_op="auto:auto=>same:470bg") # error
#z_ConvertFormat(colorspace_op="auto:auto:auto:auto=>same:same:same:f") # ok

real.finder

15th October 2020, 07:18

thanks! the changes seems ok, and I will test and see

zambelli

15th October 2020, 09:06

I was thinking it would be helpful to simplify the current list of enum values for matrix/transfer/primaries by indicating in the documentation that certain standards actually use the same matrix/transfer/primaries values.

For example:

Matrix coefficients: "470bg", "170m" and "601" use identical coefficients (and "fcc" isn't too far off either)
Matrix coefficients: "2020ncl", "2020cl" and "2020" use identical coefficients
Transfer characteristics: "709", "601", "2020_10", "2020_12" and "2020" use the same transfer function
Transfer characteristics: In order to match FFmpeg Zscale values it'd be nice to add "170m" as alias for "601"
Color primaries: "170m" and "240m" use identical primaries (also, it's strange that the standard is called "240m" here but called "240" under matrix coefficients)
Color primaries: "709" and "470bg" aren't identical, but they are VERY close, which is useful to know when dealing with PAL video

The reason I mention it is because it's easy for someone to lose a lot of time sweating over the details of whether an old video capture is ST 170M or BT.601, only to realize after many hours of research that they're essentially the same thing. :)

real.finder

15th October 2020, 12:13

StvG, what about interlaced parameter and frame properties?

StvG

18th October 2020, 10:11

@zambelli, I will add comments.
@real.finder, currently video with frame property _FieldBased = 1/2 is processed but it shouldn't be. I'll change that later.

mp3dom

18th October 2020, 16:59

Just asking, but does R3 works fine for everyone? I'm converting a 1920x1080 4:2:2 10bit clip from 709 to 601 and I get a system exception (without any additional infos) on x64 while on x86 Vdub2 crash and close without any warning. The same script works with R1g.

zambelli

18th October 2020, 20:58

@zambelli, I will add comments.
Thanks!

One more documentation suggestion: I think the current definition of nominal_luminance could also benefit from some clarification. It says, "Nominal peak luminance in cd/m^2 when converting HDR content to RGB Linear". However, I don't think HDR conversion is the only scenario in which this parameter can be used. To the best of my understanding, what nominal_luminance really does is determine the scale of conversion between linear and non-linear transfer functions. It defines which luminance value (in cd/m^2) in a non-linear colorspace should be mapped to 1.0 in the floating point linear RGB colorspace, regardless of whether one is converting to or from linear RGB. For example, if I am converting from HLG ("std-b67") to linear RGB and want to capture the full BT.2100 HLG range (0-1000 nits) in 0.0-1.0 linear RGB, I'd set the nominal_luminance value to 1000. Does that sound right, or is my own understanding of the parameter incorrect?

Thank you for bringing this great plugin to AviSynth - it's much appreciated!

real.finder

21st October 2020, 16:51

mp3dom

21st October 2020, 22:57

maybe it's better to post a simple script with colorbars that show the problem

ColorBars(width=1920,height=1080,pixel_type="yuv422p10")
z_ConvertFormat(720,480,colorspace_op="709:709:709:limited=>170m:601:170m:limited",resample_filter="bicubic")

This made VDub2 crash without any warning/advice, at least here.

StvG

22nd October 2020, 04:08

zambelli

22nd October 2020, 07:47

avsresize_r4 (https://cloud.owncube.com/s/ScA6xEADaHLiAFd): - fixed crashing when avs+ doesn't support frame properties;
- set _SARNum and _SARDen properties;
- read the input frame property _ChromaLocation if available;
- do not process clips with frame property _FiledBased > 0.
Thanks for the update - the new build no longer crashes VDub.

I've run into another unrelated bug though. It looks like it's been there going back to at least version r1g.

The output of z_ConvertFormat() is different depending on whether the input is integer or floating point.

Example:

ColorBars()
v1 = ConvertToPlanarRGB().ConvertBits(32).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg:l=>rgb:709:709:f")
v2 = ConvertToPlanarRGB().ConvertBits(16).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg:l=>rgb:709:709:f")

Interleave(v1, v2)

StvG

22nd October 2020, 14:43

zimg expects full range when input is YUV float or RGB.
In your example "ColorBars().ConvertToPlanarRGB()" returns RGB in limited range so after "ConvertToYUV444(matrix="Rec601")" you have limited range but zimg expects full range.
The following give you identical output: ColorBars()
#v1 = ConvertToPlanarRGB().z_ConvertFormat(pixel_type="rgbps", colorspace_op="auto:auto:auto:l=>same:same:same:f").ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg=>rgb:709:709") # also same output
v1 = ConvertToPlanarRGB().ConvertBits(32, fulls=false, fulld=true).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg=>rgb:709:709")
v2 = ConvertToPlanarRGB().ConvertBits(16).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg=>rgb:709:709")

Interleave(v1, v2)

zambelli

26th October 2020, 11:30

zimg expects full range when input is YUV float or RGB.
Are you saying that when input to zimg is floating point YUV and the input range is indicated as "limited", zimg assumes that black is Y=0.0 and white is Y=1.0?

Shouldn't "limited" range imply that black is Y=0.06 and white is Y=0.92?

When RGBP8 0-255 is converted to RGBPS using Avisynth's internal ConvertBits(32), I am making the assumption that 0 gets mapped to 0.0 and 255 gets mapped to 1.0.
When RGBPS gets converted to YUV444PS using internal ConvertToYUV444(matrix="Rec601"), I am making the assumption that RGB 0.0 gets mapped to Y=16.0/255.0, and RGB 1.0 gets mapped to Y=235.0/255.0 since the matrix indicates RGB full --> YUV limited.

Am I making the wrong assumptions there?

real.finder

26th October 2020, 15:45

Are you saying that when input to zimg is floating point YUV and the input range is indicated as "limited", zimg assumes that black is Y=0.0 and white is Y=1.0?

Shouldn't "limited" range imply that black is Y=0.06 and white is Y=0.92?

When RGBP8 0-255 is converted to RGBPS using Avisynth's internal ConvertBits(32), I am making the assumption that 0 gets mapped to 0.0 and 255 gets mapped to 1.0.
When RGBPS gets converted to YUV444PS using internal ConvertToYUV444(matrix="Rec601"), I am making the assumption that RGB 0.0 gets mapped to Y=16.0/255.0, and RGB 1.0 gets mapped to Y=235.0/255.0 since the matrix indicates RGB full --> YUV limited.

Am I making the wrong assumptions there?

https://github.com/sekrit-twc/zimg/issues/134

zambelli

27th October 2020, 09:04

https://github.com/sekrit-twc/zimg/issues/134
Huh. Interesting. Is the last comment in that thread correct - is AVS+ converting incorrectly?

So when an 8-bit limited range signal is converted to YUV4xxPS with zimg, does that mean 16 maps to Y=-0.07 and 235 maps to Y=1.09?

real.finder

27th October 2020, 14:05

Huh. Interesting. Is the last comment in that thread correct - is AVS+ converting incorrectly?

So when an 8-bit limited range signal is converted to YUV4xxPS with zimg, does that mean 16 maps to Y=-0.07 and 235 maps to Y=1.09?

I don't think it's incorrect, float can be any thing, I don't see problem using 0.06..0.92 but it will not stay as it after using some filters since float don't clamp anyway

anyway, pinterf seems plan about do something about this using frame properties

so for now, you can use z_ConvertFormat if you convert to float permanently, and avs one if you do it temporarily (mean int -> float -> int)

So when an 8-bit limited range signal is converted to YUV4xxPS with zimg, does that mean 16 maps to Y=-0.07 and 235 maps to Y=1.09?

don't know, but you can try it (even if it hard since avsp don't show the real value of the pixel, so you must find some work around)

TheFluff

28th October 2020, 14:56

Are you saying that when input to zimg is floating point YUV and the input range is indicated as "limited", zimg assumes that black is Y=0.0 and white is Y=1.0?

zimg always assumes that float input is in the range 0.0-1.0 regardless of whether you tell it that the input is limited range or not, and I believe likewise always converts float output into that range. This is because "limited range" makes no sense for float, or perhaps more accurately it's always limited range. Limited range means using a pair of arbitrarily chosen values to represent black and white instead of using the minimum and maximum values of the storage format (e.g. 8-bit integer, 16-bit integer, 32-bit float), but with float it makes no sense to use the minimum and maximum representable values of the storage format as black and white because then you get different numerical precision in different parts of the range, so we use the arbitrary convention 0.0-1.0 instead. There is no point in choosing a different arbitrary convention.