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. |
21st October 2020, 16:51 | #141 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
maybe it's better to post a simple script with colorbars that show the problem
__________________
See My Avisynth Stuff |
21st October 2020, 22:57 | #142 | Link | |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Quote:
Code:
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") |
|
22nd October 2020, 04:08 | #143 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
avsresize_r4: - 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. Last edited by StvG; 22nd October 2020 at 04:43. Reason: typo |
22nd October 2020, 07:47 | #144 | Link | |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
Quote:
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: Code:
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) |
|
22nd October 2020, 14:43 | #145 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
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: Code:
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) |
26th October 2020, 11:30 | #146 | Link |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
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? |
26th October 2020, 15:45 | #147 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
27th October 2020, 09:04 | #148 | Link | |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
Quote:
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? |
|
27th October 2020, 14:05 | #149 | Link | ||
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
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) Quote:
__________________
See My Avisynth Stuff |
||
28th October 2020, 14:56 | #150 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
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.
|
29th October 2020, 06:09 | #151 | Link | |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
Quote:
I'm still curious: what happens to superblack and superwhite values from a limited Y integer range when it's converted to float? Do they end up mapping to <0 and >1? |
|
29th October 2020, 09:10 | #152 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
At the time I was developing the high bit depth additions I was not aware of any conventions. I suppose this convention was not even a strong one. And it had two phases, even putting the float UV chroma range to zero center was an extra project for me years ago, mainly because I wanted it to be compatible with zimg (and VS). And because it is a reasonable convention. Now it needs a third step: handle 32 bit float format uniformly across avs+ core and plugins. With additions attention to the implemented auto-conversions in Expr and masktools lut. |
|
29th October 2020, 14:17 | #153 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
To clarify....
z_ConvertFormat(720,480,colorspace_op="709:709:709:limited=>170m:601:170m:limited") If the source is some flavour of YUV and the input to z_ConvertFormat is 32 bit float, should "limited" be changed to "full", or is the specified range ignored for float? |
29th October 2020, 21:04 | #154 | Link | ||
Registered User
Join Date: Jul 2018
Posts: 450
|
Quote:
If input is int and output is float - color_range source set to full keeps the values same and returns x/255 (8-bit) within 0..1 range; color_range source set to limited expands the range limited to full; color_range destination doesn't have effect. If input is float (full range) and output is int - color_range source doesn't have effect; color_range destination set to limited does full to limited; color_range destination set to full keeps the full range. Quote:
Last edited by StvG; 29th October 2020 at 21:12. Reason: reply to hello_hello |
||
30th October 2020, 11:12 | #155 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
avsresize_r5: use chromaloc frame property (when available) for the legacy resizers.
|
15th May 2021, 14:42 | #156 | Link |
Registered User
Join Date: Jan 2018
Posts: 2,156
|
I seen zimg have new ver
https://github.com/sekrit-twc/zimg/b...ster/ChangeLog |
30th May 2021, 15:09 | #157 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
avsresize_r6: - registered as MT_NICE_FILTER;
- read frame properties from every frame (previously only from the first frame); - zimg@8d0b839. |
31st May 2021, 09:46 | #160 | Link | |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,574
|
Quote:
Code:
Il server non č stato in grado di completare la tua richiesta. Se ciņ si verifca nuovamente, invia i seguenti dettagli tecnici all'amministratore del server. Ulteriori dettagli sono disponibili nel log del server. Dettagli tecnici Indirizzo remoto: 84.221.196.138 ID richiesta: WXU1VipibSaEEFhe3TpD
__________________
@turment on Telegram |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|