A frame properties question

[hello_hello]

What's the logic is behind the Vapoursynth Resize function behaving the following way in respect to frame properties (or some of them).

matrix_in, transfer_in, primaries_in, range_in, chromaloc_in:
If the corresponding frame property is set to a value other than unspecified, the frame property is used instead of this parameter.

I ask, because a function I was checking yesterday didn't always convert the colors as expected (or sometimes they were obviously wrong) but only when converting them with Vapoursynth. FMTConv was okay.
I spent an hour or more searching for a mistake in the function before the penny finally dropped, because it hadn't occurred to me I could be telling Vapoursynth to do one thing while it was silently ignoring me and doing something else.

An easy solution for the function would be to always delete any existing frame properties before the color conversion, but I'm not sure that's the best idea. Is there a way to change the behavior I've missed? If I remember correctly AVSResize has a "use_props" argument for that sort of thing.

Cheers.

[_Al_]

I think, it is like that, it is in the manual now, I was confused too, we have to go with that logic - dealing with props first. Maybe the idea is, what source plugin loads, should be godly, do not touch it :-)

You might perhaps use it already, but I put it here nevertheless, ... using python get function for dictionary and have a back up zimg in value ready if props do not provide it.
matrix_prop = f.props.get("_Matrix", None) # None might be default, but anyway
if matrix_prop in [0,2,3]: matrix_prop=None
matrix_backup = .....
matrix_in = matrix_prop or matrix_backup #if first value is None other is used
But basically only back up value could be passed alone, which would confuse anyone for sure, why things do not work if reading the code. So better to write it like that.

To override clip's in _Matrix, _Transfer, _Primaries and become a sinner or perhaps redeem other sinners :-), they can be set to 2, or using RemoveFrameProps("_ColorRange") (which would not take multiple props).
Then using custom zimg resize values.

Be careful, prop _ColorRange and zimg resize range values are inverted. If _ColorRange is 1, then it is range zero value and vice versa. It just had me confusedfor a long time.
But to keep that vapoursynth logic, that even does not even matter, because you have to delete prop if setting it in zimg resize anyway. Or confusion comes when setting out range value, if the same zimg out value is used as clip's prop value, it is wrong.

There were a cuts/changes in vapoursynth, things that were there for 10years. Also there used to be boolean "prefer_props" argument in resizing, but that was deprecated.

edit: I forgot to write actual "get" in that function, I added it there

[Myrsloik]

What's the logic is behind the Vapoursynth Resize function behaving the following way in respect to frame properties (or some of them).

matrix_in, transfer_in, primaries_in, range_in, chromaloc_in:
If the corresponding frame property is set to a value other than unspecified, the frame property is used instead of this parameter.

I ask, because a function I was checking yesterday didn't always convert the colors as expected (or sometimes they were obviously wrong) but only when converting them with Vapoursynth. FMTConv was okay.
I spent an hour or more searching for a mistake in the function before the penny finally dropped, because it hadn't occurred to me I could be telling Vapoursynth to do one thing while it was silently ignoring me and doing something else.

An easy solution for the function would be to always delete any existing frame properties before the color conversion, but I'm not sure that's the best idea. Is there a way to change the behavior I've missed? If I remember correctly AVSResize has a "use_props" argument for that sort of thing.

Cheers.

If material has its properties set it's assumed they're correct. And if you assume that you end up with this solution. If you make a table of all cases you realize there's no ideal method and everything becomes iffy in some cases.

What did you convert that's incorrectly flagged anyway?

[hello_hello]

Sorry about the late reply.

I wasn't trying to convert anything as such, only test a function that includes optional color conversion, so I was specifying various conversions, even if most of them would technically be incorrect, and comparing the result with FMTConv (the function can also use it for color conversion). The source contained frame properties specifying the matrix as rec.709, so when I specified a conversion from 709 to 2020 (for example,) Vapoursynth and FMTconv produced the same output. For a conversion from 2020 to 709 though, FMTConv changed the colors while Vapoursynth did nothing. Eventually I realized what the problem was, and deleting the frame properties before the function allowed Vapoursynth and FMTConv to produce the same result.

Edit. Frame properties in general can be a double edged sword at times. A friend PM'd me a while back to see if I could work out why his source (using Avisynth) was being encoded as interlaced by ffmpeg when he hadn't told it to encode that way. If I remember correctly the source was an interlaced or telecined DVD and the de-interlacing filter he was using wasn't changing the frame property set by the source filter, and ffmpeg had recently been updated to pay attention to frame properties.

[_Al_]

Can be assigned a value for any name, custom property in avisynth?
It is a good way to carry an information thru-out a script/code. In avisynth you can avoid defining lots of globals maybe. But in vapoursynth it is even more handy because a script could be a large code dealing with other things.

In vapoursynth alpha clip can be carried as a prop.
Also vapoursynth can store data as bytes, so basically a json file could be stored there. Anything json can store, can be stored there as well. Which is any dictionary with a string keys and value could be int, float, bool, strings or lists with those values.

import json
value = {'clip_name':'Kittens', 'litter_of':3, 'names': {'fluffy':'Anna','ginger':'Bob','mottled':'Jen'}}
clip = clip.std.SetFrameProps(my_prop_name=json.dumps(value))
.
.
.
v = f.props["my_prop_name"]
if isinstance(v, bytes):
try:
data = json.loads(v)
except json.decoder.JSONDecodeError:
data = v.decode()
else:
data =v
print(data)