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 > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th February 2024, 22:02   #321  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by StvG View Post
Fixed in r24.
Thank you.

Another one....
AVSResize is changing the ColorRange frame property from full to limited for 32 bit YUV. Would it be correct to assume it shouldn't?

ColorBars.KillAudio().ConvertToYV24().ConvertBits(32)
propset("_ColorRange", 0)
z_ConvertFormat(960,720)
# propGetAny("_ColorRange") = 1

The same thing happens when you use colorspace_op without specifying a coior range
z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")

And when using two instances of z_ConvertFormat to convert to RGB and back.
z_ConvertFormat(colorspace_op="170m:601:170m=>rgb:linear:170m", pixel_type="RGBPS")
z_ConvertFormat(colorspace_op="rgb:linear:170m=>470bg:601:470bg", pixel_type="YUV420PS")

Cheers.

Last edited by hello_hello; 28th February 2024 at 22:18.
hello_hello is offline   Reply With Quote
Old 29th February 2024, 05:07   #322  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
avsresize r25:
- Fixed exported _ColorRange properties.
- zimg a0fac0f.

Quote:
Originally Posted by hello_hello View Post
Thank you.

Another one....
AVSResize is changing the ColorRange frame property from full to limited for 32 bit YUV. Would it be correct to assume it shouldn't?

ColorBars.KillAudio().ConvertToYV24().ConvertBits(32)
propset("_ColorRange", 0)
z_ConvertFormat(960,720)
# propGetAny("_ColorRange") = 1

The same thing happens when you use colorspace_op without specifying a coior range
z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")

And when using two instances of z_ConvertFormat to convert to RGB and back.
z_ConvertFormat(colorspace_op="170m:601:170m=>rgb:linear:170m", pixel_type="RGBPS")
z_ConvertFormat(colorspace_op="rgb:linear:170m=>470bg:601:470bg", pixel_type="YUV420PS")

Cheers.
The first case (z_ConvertFormat(960,720)) is fixed in r25.

The last two cases always should give full color range property. It's fixed in r25.
StvG is offline   Reply With Quote
Old 1st March 2024, 01:23   #323  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Thanks again!
hello_hello is offline   Reply With Quote
Old 5th March 2024, 01:29   #324  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 210
Unrelated to the current new versions, is there something off for 2020->709?

Taking this red ramp as an input:


And applying:
Code:
z_ConvertFormat(colorspace_op="rgb:2020:2020:full=>rgb:709:709:full")
results in:


Comparing to my expectation and with the calibrated display modes BT.2020 and BT.709 on my display, the position marked (look at the full image) appears too abrupt and too magenta. Could there be something off somewhere in the matrices?

my expectation would have been this:

Last edited by ErazorTT; 5th March 2024 at 01:39.
ErazorTT is offline   Reply With Quote
Old 5th March 2024, 03:39   #325  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,340
Quote:
Originally Posted by ErazorTT View Post
Unrelated to the current new versions, is there something off for 2020->709?

Taking this red ramp as an input...
It seems off . There are large jumps at lower values in the green channel .

Compare the result to FMTC, which is smooth and the increments are even

Code:
fmtc_transfer(transs="2020", transd="linear")
fmtc_primaries(prims="2020", primd="709")
fmtc_transfer(transs="linear", transd="709")
For avsresize - I tried linearizing first, also maxcpu setting. Also same result in vapoursynth
poisondeathray is offline   Reply With Quote
Old 5th March 2024, 04:52   #326  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 447
Yes, it's zimg bug.
The github repo is abandoned and the new bitbucket repo doesn't have enabled the "Issues" sections. If someone has contact with the author (irc, discord) can report this. Also it can be reported on the VS repo/forum (I guess the VS people can reach him since zimg is the default VS resize/colorspace function).
StvG is offline   Reply With Quote
Old 16th March 2024, 21:33   #327  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 538
"Comparing to my expectation and with the calibrated display modes BT.2020 and BT.709 on my display, the position marked (look at the full image) appears too abrupt and too magenta. Could there be something off somewhere in the matrices?"

Mmmm... "Note that "z" is not a color management system and should not be used to perform drastic contrast or gamut reduction, such as BT.2020 to BT.709."


Same command ffmpeg -i red-ramp-inputbt2020.png -vf zscale=rin=full:r=full:tin=2020_12:t=2020_12in=2020=709:d=none dwedstrange1.png

Last edited by Balling; 16th March 2024 at 22:17.
Balling is offline   Reply With Quote
Old 16th March 2024, 21:42   #328  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 538
" Taking this red ramp as an input:"

That ramp is sRGB, rendering intent Perceptual. This is lossless data (-f md5 - prints c9910d9f1c4dcf3698ba025a268facf4), but tagged as 2020 primaries, 2.4 gamma. Here you go (I must say windows is closer to what zimg does in sdr mode, in HDR not even close):

Last edited by Balling; 16th March 2024 at 22:06.
Balling is offline   Reply With Quote
Old 16th March 2024, 22:14   #329  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,036
Quote:
Originally Posted by ErazorTT View Post
Unrelated to the current new versions, is there something off for 2020->709?

Taking this red ramp as an input:


And applying:
Code:
z_ConvertFormat(colorspace_op="rgb:2020:2020:full=>rgb:709:709:full")
Any 'simple' shrink-conversion of wider domain to narrower is unlikely possible with significant clipping or other issues. Maybe original designer of wide->narrow valid convert path assume user prepare valid colour gamut and levels range first (in 2020 primaries and 2020 transfer) and only as next step apply conversion. Maybe avsresize do not doing any 'shrinking' at all at attempt to to 'downconversion'. It looks not covered in the documentation ? HDR to SDR and WCG to SCG conversions may be performed at least in 3 different ways:
1. Range crop (extract SDR and SCG from HDR and WCG). Any out of range values are clipped to max valid values.
2. Full range map (compress full HDR and WCG into SDR and SCG).
3. Some unlimited ways of 'tonemap'.

So it possibly only low-distorted way: rgb:709:709:full=>rgb:2020:2020:full=>rgb:709:709:full (using 32bit float samples to escape of quantization noise as best as possible).

If feed out-of-range 2020 primaries and transfer to conversion to 709 - the result maybe undefined.

Also freeware HDR<->SDR conversion libraries may have some set of 'magic variables' to tweak the conversion like float "nominal_luminance", bool "approximate_gamma", bool "use_props", bool "scene_referred".

Last edited by DTL; 16th March 2024 at 22:24.
DTL 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 10:09.


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