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 18th January 2017, 20:12   #81  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by jpsdr View Post
You just have now to specify that range is not anymore the standard range for the actual format, and it will not break anything.
Of course, if a metadata tag existed, it would have been perfect...
for nnedi3, I don't have time for edit like 10 scripts just for that, and some of them still has 2.5 support (with 2.6 and plus) and that will make edit things way annoying, so I will pass

but if you kindly make range = 1 then I will taking the range into account for some scripts in future
__________________
See My Avisynth Stuff

Last edited by real.finder; 18th January 2017 at 20:15.
real.finder is offline   Reply With Quote
Old 23rd January 2017, 08:55   #82  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,314
I don't think either that defaulting to 16-240 is a good idea, neither on YUV, especially nor for greyscale. There are many scripts out there that rely on the old behaviour and use clip converted at the beginning to PC range. Or use Y as an extracted channel from an RGB clip, these scripts (or plugins that invoke nnedi3_rpow2) may break now.
Many camcorders and video capable cameras now are using 16-255 that contain extra highlight information (superwhites) to be retreived later on processing. You can even display this range on a capable device (there are such projectors).
Now this extra highlight information is lost by the new defaults.
I think it is not the resizers task to police over the range. People just blindly download and use latest version and see that something went wrong.
pinterf is offline   Reply With Quote
Old 23rd January 2017, 10:17   #83  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
Quote:
Originally Posted by pinterf View Post
I think it is not the resizers task to police over the range.
Personnaly, i think, not specificaly resizers, that any filter has to produce "in specs" output levels.
YUV "alone", without more indications or informations is by default/standard TV limited range, this is the proper behavior.
So, any filter processing YUV has to produce a proper "in spec" output.
You can have of course full range YUV, but it's not a standard behavior, so you have to specify that you're oustide the default behavior. Not the oposite, it's not when you're within the default/normal behavior that you have to specify it.
As there is not such information as the range in the avs "clip" (otherwise it could have been used), the standard prevail, and the standard for YUV for example, is that YUV is limited range.

Thanks for the 16-255 range, i didn't know about it, i'll add it in a future version.
jpsdr is offline   Reply With Quote
Old 23rd January 2017, 10:39   #84  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,314
Just imagine what would happen if we had to provide every plugin and avisynth filter an extra parameter not to screw up the processing, removegrains, mvtools functions, any. I maintain that until the range cannot be extracted with 99.99% confidence from a clip or frame property, this auto-clamp feature is dangerous. Unless nnedi3 is a brand new filter that is not used widespreadly and behaves as such from the beginning.
pinterf is offline   Reply With Quote
Old 23rd January 2017, 12:48   #85  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
I understand this point of view, i've thought about it before doing this.

But the only fact that with the actual behavior, something like this :
Code:
AVISource("My SD YV12 file",false,"YV12")
Spline36Resize(1280,720)
can produce out of spec/range output...
No... i don't like it.

And having a parameter to have to specify that your file is in the standard spec, and you want your output stay in standard spec...
Not again, i don't like it either.

I personnaly think that the actual behavior is wrong (and so my filters were wrong), i even didn't realise it until now, i'm a little pissed over myself of not noticing sooner something finaly so obvious, and i personnaly don't want to continue/keep this way.

I want that with my filters, a simple script like described before work properly when everything is within the standard specs, without having to tell when everything is "normal".
This is the behavior i'll stick with now.
jpsdr is offline   Reply With Quote
Old 23rd January 2017, 13:27   #86  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Another possible convention is that all intermediate results are allowed to be out of range, this may simplify things (values must be clamped on output and before colorspace change, but not anywhere else).
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 23rd January 2017, 14:48   #87  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
Do you mean avisynth will automaticaly clamp values before outputing datas according the format of the video ? (Full range for RGB, limited for Y/YUV) ?
jpsdr is offline   Reply With Quote
Old 23rd January 2017, 15:14   #88  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
No, I don`t know current set of rules, just speculating.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 23rd January 2017, 15:44   #89  |  Link
raffriff42
Retried Guesser
 
raffriff42's Avatar
 
Join Date: Jun 2012
Posts: 1,373
Resampling/resizing is not affected by "range" at all, except in the case of overshoot. It should not affect a resizer AT ALL.

Handling overshoot without clipping is the whole point of so-called "limited range."
("so-called" because it actually stores a WIDER range of colors, unless it is misguidedly restricted to 16-235)
raffriff42 is offline   Reply With Quote
Old 23rd January 2017, 16:02   #90  |  Link
pbristow
Registered User
 
pbristow's Avatar
 
Join Date: Jun 2009
Location: UK
Posts: 263
Quote:
Originally Posted by shekh View Post
Another possible convention is that all intermediate results are allowed to be out of range, this may simplify things (values must be clamped on output and before colorspace change, but not anywhere else).
Yes, this, please! It is crazy to place the burden of range-checking on every single filter in the chain, and crazy to expect novices have to figure out for each and every filter what option they should be choosing if they suspect the default might not be right. You're just adding needless complexity to the debugging chain.

Levels/ranges should only ever be policed explicitly, and at a place in the chain chosen by the user to suit their needs. They shouldn't have to work their way through the whole chain of filters trying to work out which one is messing up the range, and whether its because they've chosen the wrong option or because the filter itself has a bug!

What I'd much rather see is for someone to create a nice, user friendly "levels advisor" plugin. Something that looks at the incoming clip, checks the ranges of values, and says:
"This clip is using Y/U/V values above/below the standard YUV minimum/maximum. If you wish to store this data in a standard YUV format, consider using the Levels filter to either (a) re-scale the data to fit within range; (b) clip or "hard limit" the range. If you do not think the data should be exceeding the standard range at this point in your script, trying using LevelsAdvisor earlier in your script to trace where things are going wrong."

It should of course also display the actual maximum and minimum values found in each channel, and what the standard limits are. If the actual values are only ever one LSB out of range, that suggests trivial rounding errors are at fault, and hard limiting the range is the appropriate option. If the overshoot is bigger, that suggests re-scaling (or filter chain debugging) is needed.

Last edited by pbristow; 23rd January 2017 at 16:09.
pbristow is offline   Reply With Quote
Old 23rd January 2017, 19:21   #91  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
Originally Posted by jpsdr View Post
Personnaly, i think, not specificaly resizers, that any filter has to produce "in specs" output levels.
YUV "alone", without more indications or informations is by default/standard TV limited range, this is the proper behavior.
So, any filter processing YUV has to produce a proper "in spec" output.
You can have of course full range YUV, but it's not a standard behavior, so you have to specify that you're oustide the default behavior. Not the oposite, it's not when you're within the default/normal behavior that you have to specify it.
As there is not such information as the range in the avs "clip" (otherwise it could have been used), the standard prevail, and the standard for YUV for example, is that YUV is limited range.

Thanks for the 16-255 range, i didn't know about it, i'll add it in a future version.
Like other people say it's a bad idea. Not only because you break backwards-compatibility, but also because there is no proper "in spec" output. Both are allowed in the h.264/h.265 specs for example and that's even within the same standard. Although one is more common than the other obviously.

Last edited by Wilbert; 23rd January 2017 at 19:24.
Wilbert is offline   Reply With Quote
Old 23rd January 2017, 19:42   #92  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
For x264, the parameter is :
Code:
      --input-range <string>  Specify input color range ["auto"]
                                  - auto, tv, pc
Unable to find what "auto" is doing. Maybe it changes the range "on the fly" during the encode process if it founds a value outside the TV range...?
All docs on the net are obsolete, they talk of a "fullrange" parameter with "off" by default , but this parameter doesn't exist anymore.
I never said that full range is not possible, i said that standard/default range of YUV, without more information than just only saying "it's YUV", is limited range.

Edit : More likely, the "auto" probably choose tv/pc according the input data format, and/or the encoded data format, and probably behave according the standard (YUV -> TV, RGB->PC).
Well, exactly what i'm doing.

Last edited by jpsdr; 23rd January 2017 at 19:52.
jpsdr is offline   Reply With Quote
Old 23rd January 2017, 20:03   #93  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by jpsdr View Post
For x264, the parameter is :
Code:
      --input-range <string>  Specify input color range ["auto"]
                                  - auto, tv, pc
Unable to find what "auto" is doing. Maybe it changes the range "on the fly" during the encode process if it founds a value outside the TV range...?
All docs on the net are obsolete, they talk of a "fullrange" parameter with "off" by default , but this parameter doesn't exist anymore.
I never said that full range is not possible, i said that standard/default range of YUV, without more information than just only saying "it's YUV", is limited range.

Edit : More likely, the "auto" probably choose tv/pc according the input data format, and/or the encoded data format, and probably behave according the standard (YUV -> TV, RGB->PC).
Well, exactly what i'm doing.
it's see the max and the min, with auto I encode full range anime EP (Trickster) from Japanese TV and it was fine with no clamp in auto
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 23rd January 2017, 21:34   #94  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
Well... Even if i realy don't like it, i'll set back the default range on 1 on next releases, as everyone seems to want to have improper behavior, i'll put the range in my scripts...
jpsdr is offline   Reply With Quote
Old 23rd January 2017, 21:50   #95  |  Link
pbristow
Registered User
 
pbristow's Avatar
 
Join Date: Jun 2009
Location: UK
Posts: 263
Quote:
Originally Posted by pbristow View Post
If the actual values are only ever one LSB out of range, that suggests trivial rounding errors are at fault, and hard limiting the range is the appropriate option. If the overshoot is bigger, that suggests re-scaling (or filter chain debugging) is needed.
... *OR* that in fact neither is needed, because *at this particular point in the script or filter chain*, out-of-standard-range values are entirely to be expected, and nothing to worry about!
pbristow is offline   Reply With Quote
Old 23rd January 2017, 21:55   #96  |  Link
pbristow
Registered User
 
pbristow's Avatar
 
Join Date: Jun 2009
Location: UK
Posts: 263
Just seen this, after posting my addendum:

Quote:
Originally Posted by jpsdr View Post
Well... Even if i realy don't like it, i'll set back the default range on 1 on next releases, as everyone seems to want to have improper behavior, i'll put the range in my scripts...
Thankyou.

Side-note: It's not "improper behaviour" we want (who in the world wants that?). It's "behaviour that we think is proper, and you don't". =;o}

[SALUTES YOU FOR TACKLING THE MULTI-THREADING OPPORTUNITIES IN THE BEST, MOST LOGICAL AND EFFECTIVE PLACE]
pbristow is offline   Reply With Quote
Old 23rd January 2017, 22:33   #97  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
"Improper behavior" means thinking default YUV is full range when it's limited. You want Out of range value ? No problem, but you have to tell that you don't want normal output, that's all.
Why when you want "not out or range value", you have to specify it ? Proper behavior should be the oposite !
Well, as i said, it will be like this back again in next releases...
jpsdr is offline   Reply With Quote
Old 24th January 2017, 20:58   #98  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
New version, see first post.
jpsdr is offline   Reply With Quote
Old 23rd March 2017, 09:27   #99  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,316
New version, see first post.
jpsdr is offline   Reply With Quote
Old 21st April 2017, 02:36   #100  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
@jpsdr

ResampleMT 1.5.3 x86 XP SSE4.2 doesn't work on Windows XP x86, although the normal XP executable works fine (the one without assembly optimizations).
My CPU is an Intel i7 6700HQ, which supports SSE4.2, in fact your NNEDI3 XP SSE4.2 build works fine.

Oh, and by the way, thank you for your work and for supporting XP

Last edited by FranceBB; 21st April 2017 at 02:38.
FranceBB 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 19:41.


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