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. |
28th February 2024, 22:02 | #321 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
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. |
29th February 2024, 05:07 | #322 | Link | |
Registered User
Join Date: Jul 2018
Posts: 450
|
avsresize r25:
- Fixed exported _ColorRange properties. - zimg a0fac0f. Quote:
The last two cases always should give full color range property. It's fixed in r25. |
|
5th March 2024, 01:29 | #324 | Link |
Registered User
Join Date: Mar 2003
Location: Germany
Posts: 215
|
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") 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. |
5th March 2024, 03:39 | #325 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
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") |
|
5th March 2024, 04:52 | #326 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
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). |
16th March 2024, 21:33 | #327 | Link |
Registered User
Join Date: Feb 2020
Posts: 541
|
"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. |
16th March 2024, 21:42 | #328 | Link |
Registered User
Join Date: Feb 2020
Posts: 541
|
" 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. |
16th March 2024, 22:14 | #329 | Link | |
Registered User
Join Date: Jul 2018
Posts: 1,067
|
Quote:
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. |
|
20th March 2024, 02:12 | #330 | Link | ||
Registered User
Join Date: Mar 2003
Location: Germany
Posts: 215
|
Quote:
Quote:
For the discussed case, the conversion from (linear) 2020 RGB to XYZ is given by: X = 0.636958048 * rl + 0.144616904 * gl + 0.168880975 * bl; Y = 0.262700212 * rl + 0.677998072 * gl + 0.059301716 * bl; Z = 0.000000000 * rl + 0.028072693 * gl + 1.060985058 * bl; And the conversion from XYZ to (linear) 709 RGB is given by: rl = 3.240969944 * X - 1.537383176 * Y - 0.4986107602 * Z; gl = -0.9692436371 * X + 1.875967501 * Y + 0.04155505794 * Z; bl = 0.05563007901 * X - 0.2039769588 * Y + 1.056971515 * Z; The clipping than happens by clamping: rl = min(max(rl,0),1); gl = min(max(gl,0),1); bl = min(max(bl,0),1); This will produce my "expectation image" from the "input image". z_ConvertFormat reproduces this for all colored ramps apart from the red ramp, thus there is something wrong. (PS: that is exactly what Rep. ITU-R BT.2407-0 describes in section 2, on pages 1 and 2. And of course what I haven’t shown here is going back and forth from gamma to linear, but thats also streightforward.) Last edited by ErazorTT; 20th March 2024 at 08:29. |
||
20th March 2024, 02:52 | #331 | Link | |
Registered User
Join Date: Mar 2003
Location: Germany
Posts: 215
|
Quote:
My actual input was not that image but a script creating the ramp which I then fed to z_ConvertFormat. |
|
20th March 2024, 10:49 | #332 | Link |
Registered User
Join Date: Mar 2003
Location: Germany
Posts: 215
|
Ok I think found the issue. Actually I looked further into it because of Balling's and DTL's comments.
The point is that the conversion by z_ConvertFormat is done display-referred, while I did it scene-referred. Display-referred is probably the "more correct". So the conversion by z_ConvertFormat is actually fine! This obviously means that fmtc_transfer converts scene-referred. Scene-referred means that the transfer function used is that shown in item 1.2 from the tabel on page 3 of Rec. ITU-R BT.709-6. Display-referred means that the transfer function used is the one from Rec. ITU-R BT.1886 page 3. Last edited by ErazorTT; 20th March 2024 at 12:19. |
20th March 2024, 14:20 | #333 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,067
|
Documentation http://avisynth.nl/index.php/Avsresize says
bool scene_referred = false Whether to use scene-referred transfer function (default false). Is setting to true produce expected result ? "Display-referred is probably the "more correct"." Linear scene light expected to be close to reality and fixed for source (image data). And displays may be different. If you make a chain of conversions and some uses display linear and some scene linear - the result will be more distorted. It may be same idea as about spatial spectrum shaping - it is better to do in scene linear light. Last edited by DTL; 20th March 2024 at 14:29. |
20th March 2024, 16:34 | #334 | Link |
Registered User
Join Date: Mar 2003
Location: Germany
Posts: 215
|
Ah, it's good to know that it can do both. Yes, so this reproduces what I initially expected. I am now not sure which conversion to prefere but it seems that display-referred is the one I need.
Last edited by ErazorTT; 20th March 2024 at 16:46. |
4th April 2024, 21:22 | #335 | Link | |
Registered User
Join Date: Feb 2020
Posts: 541
|
Quote:
Last edited by Balling; 4th April 2024 at 21:25. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|