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 > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th March 2017, 16:37   #221  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,098
Quote:
Originally Posted by WolframRhodium View Post
However, as an example, some people has been widely using gauss for years, and this phenomenon will continue. How can you come down to your conclusion?
The Gauss resizer isn't even a resampler at all, mathematically speaking. As far as I can recall I don't think people really use it all that much for actually resizing things; they use it to blur things. Use something else for that.

Blackman is a bad windowed sinc; use lanczos instead.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 16:44   #222  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Providence, RI
Posts: 2,416
Quote:
Originally Posted by TheFluff View Post
It's handled automatically, yes, assuming that the _Field or _FieldBased frame props are set correctly. Unlike Avisynth, VS (and zimg) understands that an interlaced clip that you call separatefields() on does not magically become progressive, so if you feed a field-separated clip to the internal resizer, resize it horizontally and then weave it again it'll still be handled correctly (there won't be any jumping up and down).


No. None of the extra ones are all that useful anyway.
gaussresize is more useful than you think, it could be used as a non-ringing convolution filter, and it's far more powerful than std.convolution, cuz:
a. it works with any radius (using the "taps" parameter)
b. it does not require you to manually calculate the coefficient matrix, you could simply control the filtering strength using the "p" parameter.
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

Last edited by feisty2; 18th March 2017 at 16:47.
feisty2 is offline   Reply With Quote
Old 18th March 2017, 16:49   #223  |  Link
WolframRhodium
Registered User
 
Join Date: Jan 2016
Posts: 111
Quote:
Originally Posted by TheFluff View Post
The Gauss resizer isn't even a resampler at all, mathematically speaking. As far as I can recall I don't think people really use it all that much for actually resizing things; they use it to blur things. Use something else for that.

Blackman is a bad windowed sinc; use lanczos instead.
The combination of lanczos and gauss in upsampling is popular. But zimg doesn't have gauss, that's a problem.

Another example is feisty2's Vine/Plum.

Last edited by WolframRhodium; 18th March 2017 at 16:52.
WolframRhodium is offline   Reply With Quote
Old 18th March 2017, 16:58   #224  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,098
Quote:
Originally Posted by feisty2 View Post
gaussresize is more useful than you think, it could be used as a non-ringing convolution filter, and it's far more powerful than std.convolution, cuz:
a. it works with any radius (using the "taps" parameter)
b. it does not require you to manually calculate the coefficient matrix, you could simply control the filtering strength using the "p" parameter.
Isn't that exactly what I said? Write an actual Gaussian convolution filter if that's what you want, instead of shoehorning it into a resampler-that-isn't.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 17:07   #225  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Providence, RI
Posts: 2,416
Quote:
Originally Posted by TheFluff View Post
Isn't that exactly what I said? Write an actual Gaussian convolution filter if that's what you want, instead of shoehorning it into a resampler-that-isn't.
gaussresize is already highly optimized as a part of the resample function in fmtc, I could write a Gaussian filter any day of the week but I'm NOT a professional programmer, so that's gonna be a lot worse (performance-wise) than the existing gaussresize approach anyways, and I'm definitely not wasting my time just to mess with stupid things like that.
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated
feisty2 is offline   Reply With Quote
Old 18th March 2017, 17:31   #226  |  Link
WolframRhodium
Registered User
 
Join Date: Jan 2016
Posts: 111
Quote:
Originally Posted by TheFluff View Post
Isn't that exactly what I said? Write an actual Gaussian convolution filter if that's what you want, instead of shoehorning it into a resampler-that-isn't.
What's more, fmtconv contains various dithering mode and custom resample kernel, but what about zimg?
WolframRhodium is offline   Reply With Quote
Old 18th March 2017, 17:45   #227  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,098
Quote:
Originally Posted by WolframRhodium View Post
What's more, fmtconv contains various dithering mode and custom resample kernel, but what about zimg?
Dithering: Bayer pattern, random noise (magnitude 0.5) and Floyd-Steinberg are supported. Do you have any particularly convincing arguments as to why anything else is vastly superior? Having more options just for the sake of having more options is Avisynth mentality.

Custom convolution kernels: what is the actual practical use case for this? Is there any reason you can't just use a separate convolution filter?

I mean, yeah you can do a ton of interesting shit with a highly customizeable general-purpose FIR filter, but customization and flexibility is kinda hard to combine with ease of use, optimization and maintainability. If you want a filter that can do anything, it probably won't be very well suited to being a fast and reliable image resizer for real world inputs. The reason I'm trying to convince people to switch to zimg is that for 95% of the most common use cases it does what fmtconv does but is faster and easier to use. I know I told you to submit feature requests, but please keep them within the scope of what is reasonable to have in standard image resizer. For exotic stuff, write exotic filters.

Last edited by TheFluff; 18th March 2017 at 18:01.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 17:56   #228  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: Providence, RI
Posts: 2,416
Having more (not significantly worse, like x86 is worse than x64, xp is wore than win10, so I never compiled x86 binaries or obsolete xp binaries for my plugins) options is always better, simply because people could ignore opinions they don't need, and anyone gets to choose what's useful to him/her (which is also why I love c++ and dislike java )
__________________
If I got new ideas, will post here: https://github.com/IFeelBloated

Last edited by feisty2; 18th March 2017 at 18:04.
feisty2 is offline   Reply With Quote
Old 18th March 2017, 17:56   #229  |  Link
WolframRhodium
Registered User
 
Join Date: Jan 2016
Posts: 111
Quote:
Originally Posted by TheFluff View Post
Dithering: Bayer pattern, random noise (magnitude 0.5) and Floyd-Steinberg are supported. Do you have any particularly convincing arguments as to why anything else is vastly superior? Having more options just for the sake of having more options is Avisynth mentality.

Custom convolution kernels: what is the actual practical use case for this? Is there any reason you can't just use a separate convolution filter?
dithering: “Filter Lite”. See madvr's thread for why someone love it

kernel: https://forum.doom9.org/showthread.php?t=166080
WolframRhodium is offline   Reply With Quote
Old 18th March 2017, 18:11   #230  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,098
Quote:
Originally Posted by feisty2 View Post
Having more (not significantly worse, like x86 is worse than x64, xp is wore than win10, so I never compiled x86 binaries or obsolete xp binaries for my plugins) options is always better, simply because people could ignore opinions they don't need, and anyone gets to choose what's useful to him/her (which is also why I love c++ and dislike java )
You're wrong, and very predictably so. You will probably understand this when you have more experience, and I'm probably telling you this completely in vain because I think it's hard to actually internalize this before you've actually experienced it. I was wrong in exactly the same way when I was younger and I don't think anyone could have convinced me to understand that, back then.

More code (and hence more combinations of possible code paths) isn't free, it's bought with the most expensive resource of all - developer attention. More code paths means more tests and more maintenance. More complex code with more paths through it becomes harder to reason about, understand and predict. With more code, it becomes harder to change your mind, refactor and redesign.

You and I - and all other programmers - are much dumber than we'd like to think we are. Things need to be kept simple in order for us to be able to reasonably keep working with them.
TheFluff is offline   Reply With Quote
Old 18th March 2017, 18:40   #231  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,098
Quote:
Originally Posted by WolframRhodium View Post
dithering: “Filter Lite”. See madvr's thread for why someone love it

kernel: https://forum.doom9.org/showthread.php?t=166080
I'm sure a lot of madvr users love a lot of things but I care exceedingly little about them. Adding more dithering options is a pain in the butt and has basically no visible effect on output bitdepths >= 8. I myself sure as heck can't see any meaningful difference between madvr's different error diffusion modes with 8-bit output, and I definitely can't say which one looks better. If you want dithering because you want things to look nice on your shitty 6-bit monitor, then perhaps you should in fact dither on playback instead of trying to encode it into your (probably lossily compressed) video? Especially when dither pattern preferences are so subjective. Filter lite is also supposed to be faster but zimg's Floyd-Steinberg implementation is already really optimized so who cares.

Custom kernels is in a similar spot. Yes you can get marginally improved results in some ways on certain (mostly small) images, but almost nobody uses it and there are tradeoffs with every kernel. If you care about this kind of custom tweaking a standard resizer probably isn't right for you.

If you want fmtconv for its customizeability, you can keep using it! It's fine! It's just that for the vast majority of common use cases (like most of the ones posted in this thread) zimg does the same thing faster and with a bit less effort. That's all I'm saying.
TheFluff is offline   Reply With Quote
Old 19th March 2017, 03:39   #232  |  Link
junh1024
Registered User
 
Join Date: Mar 2011
Posts: 16
I'll just leave this here:

Functionality is an ASSET.
Code is a LIABILITY.

(tldr so having the LEAST code that does the MOST stuff is desireable)
junh1024 is offline   Reply With Quote
Old 16th June 2017, 20:14   #233  |  Link
juhok
Registered User
 
juhok's Avatar
 
Join Date: Dec 2005
Posts: 110
Now on FreeBSD Ports! https://www.freshports.org/graphics/...synth-fmtconv/
juhok is offline   Reply With Quote
Old 14th November 2017, 20:42   #234  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 185
What is the correct way to downscale in linear light (gamma corrected) an HDR stream?
I tried to come up with a script, but i'm not so confident it is correct as i already screwed up multiple times in this regards
MonoS is offline   Reply With Quote
Old 17th January 2018, 15:40   #235  |  Link
fadedmaple
Registered User
 
fadedmaple's Avatar
 
Join Date: Dec 2017
Posts: 7
strange

Hi,I find a problem.When i use fmtc like this ,it will tell me "transfer: unsupported color family."

Quote:
src16 = core.fmtc.bitdepth(src,bits=16)
UV = core.fmtc.resample(src16,1920, 1080, kernel="Spline36")
gray = core.std.ShufflePlanes(src16, 0, colorfamily=vs.YUV)
gray = core.fmtc.transfer(gray, transs="2020", transd="linear")
gray = core.fmtc.resample(gray, 1920, 1080, kernel="Spline36")
gray = core.fmtc.transfer(gray, transs="linear",transd="2020")
src = core.std.ShufflePlanes([gray,UV], [0,1,2],vs.YUV)

It works only when the colorfamily specified it with GARY 。
I am a noob in this , can explain why?THX

Quote:
gray = core.std.ShufflePlanes(src16, 0, colorfamily=vs.GRAY)
fadedmaple is offline   Reply With Quote
Old 17th January 2018, 15:53   #236  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,563
See fmtconv doc.
Quote:
As input, the function accepts only RGB and grayscale colorspaces.
sneaker_ger is offline   Reply With Quote
Old 17th January 2018, 16:35   #237  |  Link
fadedmaple
Registered User
 
fadedmaple's Avatar
 
Join Date: Dec 2017
Posts: 7
thanks

Quote:
Originally Posted by sneaker_ger View Post
See fmtconv doc.
Thanks for you repley.
Maybe my expression is wrong,What is the difference between Y plane and GRAY?
fadedmaple is offline   Reply With Quote
Old 8th December 2018, 05:49   #238  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Speaking of resizing, if I want to downsize an UHD Blu-ray, would this be the best way to go about it?

Code:
core.std.LoadPlugin("DGDecodeNV.dll")
video = core.dgdecodenv.DGSource("i:/jobs/test.dgi", fulldepth=False)
vid = core.fmtc.resample (clip=vid, w=1920, h=1080)
Or does core.fmtc.resample need a special parameter, optimized for reduction?
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 8th December 2018, 06:39   #239  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
The default kernel of fmtconv is bicubic with b=c=1/3 a.k.a. "Mitchell-Netravali" which should be enough for normal use.

If you are using the dll from the official release, I will recommend to use the one from ChaosKing's FATPACK or the one in my signature as it is compiled with a newer compiler and might save you from random crashes.

Try muvsfunc's SSIM_downsample if you are not satisfied with the results of plain bicubic.
__________________
Monochrome Anomaly
Wolfberry is offline   Reply With Quote
Old 8th December 2018, 07:00   #240  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,372
Quote:
Originally Posted by Wolfberry View Post
The default kernel of fmtconv is bicubic with b=c=1/3 a.k.a. "Mitchell-Netravali" which should be enough for normal use.

If you are using the dll from the official release, I will recommend to use the one from ChaosKing's FATPACK or the one in my signature as it is compiled with a newer compiler and might save you from random crashes.

Try muvsfunc's SSIM_downsample if you are not satisfied with the results of plain bicubic.

Cool. Thx.
__________________
Gorgeous, delicious, deculture!
asarian 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 12:07.


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