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. |
18th January 2017, 20:12 | #81 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
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. |
|
23rd January 2017, 08:55 | #82 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
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. |
23rd January 2017, 10:17 | #83 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
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. |
23rd January 2017, 10:39 | #84 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
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.
|
23rd January 2017, 12:48 | #85 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
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) 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. |
23rd January 2017, 13:27 | #86 | Link |
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 |
23rd January 2017, 15:14 | #88 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
No, I don`t know current set of rules, just speculating.
__________________
VirtualDub2 |
23rd January 2017, 15:44 | #89 | Link |
Retried Guesser
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) |
23rd January 2017, 16:02 | #90 | Link | |
Registered User
Join Date: Jun 2009
Location: UK
Posts: 263
|
Quote:
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. |
|
23rd January 2017, 19:21 | #91 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Last edited by Wilbert; 23rd January 2017 at 19:24. |
|
23rd January 2017, 19:42 | #92 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
For x264, the parameter is :
Code:
--input-range <string> Specify input color range ["auto"] - auto, tv, pc 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. |
23rd January 2017, 20:03 | #93 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
23rd January 2017, 21:55 | #96 | Link | |
Registered User
Join Date: Jun 2009
Location: UK
Posts: 263
|
Just seen this, after posting my addendum:
Quote:
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] |
|
23rd January 2017, 22:33 | #97 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
"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... |
21st April 2017, 02:36 | #100 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
@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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|