Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th July 2024, 15:58   #1  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,897
R68 color range issues (or I'm losing my mind)

I'm confused. I recall someone telling me the Vapoursynth color range values are the opposite of those used for Avisynth, so Limited=0 and Full=1. Is that correct?

Code:
clip = core.std.BlankClip(format=vs.YUV420P8).resize.Spline36(600,304)
clip = core.text.Text(clip, 'ColorRange ' + str(clip.get_frame(0).props.get("_ColorRange", None)))
clip.set_output()


Aside from not being sure if the value is correct, why does the resize function always write a color range to frame properties? It'd be fair enough after a conversion between YUV and RGB etc as assumptions are required, but when only resizing?

Although what seems to be happening is the value going in isn't the one coming out.

Code:
clip = core.std.BlankClip(format=vs.YUV420P8).resize.Spline36(600,304, range=1, range_in=1)
clip = core.text.Text(clip, 'ColorRange ' + str(clip.get_frame(0).props.get("_ColorRange", None)))
clip.set_output()


And either because there's something wrong with the color range assumption or I'm losing the plot, AddBorders appears to be adding full range borders when they should be limited. They're okay if I specify the border color via this function though (histogram showing the black level on the right side of the screenshots).

Code:
BClip = core.std.BlankClip(format=vs.YUV420P8)
Color = rgb.RGBColor(BClip, "green")
clip = core.std.BlankClip(BClip, format=vs.YUV420P8, color=Color).std.AddBorders(40,40,40,40)
clip = core.text.Text(clip, 'ColorRange ' + str(clip.get_frame(0).props.get("_ColorRange", None)))
clip = core.hist.Classic(clip)
clip.set_output()


Code:
BClip = core.std.BlankClip(format=vs.YUV420P8)
ColorA = rgb.RGBColor(BClip, "green")
ColorB = rgb.RGBColor(BClip, "black")
clip = core.std.BlankClip(BClip, color=ColorA, format=vs.YUV420P8).std.AddBorders(40,40,40,40, color=ColorB)
clip = core.hist.Classic(clip)
clip = core.text.Text(clip, 'ColorRange ' + str(clip.get_frame(0).props.get("_ColorRange", None)))
clip.set_output()

Last edited by hello_hello; 26th July 2024 at 00:52.
hello_hello is offline   Reply With Quote
Old 26th July 2024, 04:06   #2  |  Link
_Al_
Registered User
 
Join Date: May 2011
Posts: 336
Quote:
the opposite of those used for Avisynth, Limited=0 and Full=1. Is that correct?
It is the opposite to zimg library syntax, where range arguments are the opposite to vapoursynth prop flag.

vapoursynth props:
https://www.vapoursynth.com/doc/apir...ame-properties

When you set in vapoursynth resizer (zimg library) argument range=1, it is going to be _ColorRange 0 in props.

kwarg that sets a string rather than integer could be used instead to avoid this issue, to make a mistake, like range_s = "full" or range_s = "limited"

Quote:
AddBorders appears to be adding full range borders when they should be limited
It looks color needs to be specified with color argument, even for default black.
If using RGBColor function it ends up with limited black. Maybe if clip props do not have a range in RGBColor function and YUV format is created from that BlankRGBClip, limited is used as a default to get luma 16 for 8bit.

It just looks like a color for AddBorders should be always specified.
_Al_ is offline   Reply With Quote
Old 26th July 2024, 17:00   #3  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,897
Thanks for the info.

I couldn't find anything in the VapourSynth docs that mentioned specifying 0 and 1 for the resizer function wouldn't produce the expected result. It seems like something that should be made clear. As you said though, specifying color range as a string causes the expected value to be written to frame properties, and yes it appears AddBorders will always add full range borders unless you tell it what color black should be, which is probably something else that might be worth a mention in the docs. At least I understand what's happening now, although I wonder if it'd be possible for VapourSynth to convert 0 to 1 and 1 to 0 for the resizer function so there's no ambiguity.

Cheers.
hello_hello is offline   Reply With Quote
Old 30th July 2024, 18:31   #4  |  Link
Tiramisu
Registered User
 
Tiramisu's Avatar
 
Join Date: Feb 2024
Posts: 3
I personally just use vs enums whenever I can

For example:
Code:
vs.ColorRange.RANGE_FULL, vs.MATRIX_BT709, vs.PRIMARIES_BT709, vs.TRANSFER_LINEAR
Tiramisu is offline   Reply With Quote
Old 1st August 2024, 17:39   #5  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,424
didn't even know these existed *gig*
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 3rd August 2024, 10:10   #6  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,897
Quote:
Originally Posted by _Al_ View Post
If using RGBColor function it ends up with limited black. Maybe if clip props do not have a range in RGBColor function and YUV format is created from that BlankRGBClip, limited is used as a default to get luma 16 for 8bit.
For the record, BlankClip(format=vs.YUV420P8) also creates a blank clip with a black value of 0 rather than 16.
But yes. the reason for the RGBColor function outputting a value of 16 for black is due to the conversion from an RGB blank clip to YUV near the end of the function (for a YUV source), which by default is full to limited range, and the YUV clip is the one the function takes the color values from.

Mind you I realized that because I was using the color range frame properties for the resize function's range argument, and because the values are the opposite for the resize function, the wrong color range was being specified when there was a value in frame properties, so I'll have to fix that.

Last edited by hello_hello; 3rd August 2024 at 10:25.
hello_hello is offline   Reply With Quote
Old 4th August 2024, 06:09   #7  |  Link
_Al_
Registered User
 
Join Date: May 2011
Posts: 336
Basically rangeProp_kwarg function came up with {} for outgoing range kwarg, because no range was in clip's props, so vapoursynth defaulted in resize function.
I would not expect that also. Though a regular user might appreciate it, that his default YUV420P8 black is like that :-), hard to say. Or user would just set black YUV with color (16,128,128), as I was doing lots of times to specify 16 black, knowing black should never be below that in video for fade-in or fade-out for YUV limited.

So if wanting YUV with zero black for tat RGBcolor function, range_s="full" would need to be passed and be involved as well. To the contrary I perhaps said somewhere before, that it is not needed.
But for clip with YUV444PS format, float, it sets zero black, that you probably know, I just tested that.

Last edited by _Al_; 4th August 2024 at 06:17.
_Al_ is offline   Reply With Quote
Old 14th August 2024, 16:29   #8  |  Link
_Al_
Registered User
 
Join Date: May 2011
Posts: 336
I got to this by a chance to see value_zimg was added to vapoursynth on the top of regular prop value:
print(vs.RANGE_FULL.value) # or print(vs.RANGE_FULL)
print(vs.RANGE_LIMITED.value) # print(vs.RANGE_LIMITED)
this could be used also:
print(vs.RANGE_FULL.value_zimg)
print(vs.RANGE_LIMITEDL.value_zimg)

So that value_zimg could be used in resize function as an argument.
It was updated around December 2023, so it might be available since R66 version or so.
_Al_ is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.