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. |
1st October 2024, 16:20 | #221 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
I was actually wrong. I forgot a 'c' in the function name.
They are eventually equal in image output but jpsdr's SinPowResizeMT is faster, with threads=1 in a Prefetch (2,6) script. I have tried DeSinPowResizeMT to downsize an image but the results is awful.
__________________
@turment on Telegram |
1st October 2024, 17:39 | #222 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,069
|
Quote:
In other words, only if an image was upscaled with SinPowerResize, then you can reverse it using the "De" variant. A few catches, though: 1) SinPower is only really used to downscale, so it's very unlikely to ever find a source that has been upscaled with such a kernel 2) Inverting a kernel isn't a normal downscale, you have to not only be sure that a content was upscaled with that resizing kernel, but also that the resolution you're bringing it back to was the one you started with. For your use-case which is downscaling, you can go with SinPowerResize and call it a day. |
|
6th October 2024, 10:44 | #223 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
@jpsdr
Can your resampling functions deal with fractional resolutions? If positive, have I to converto to floating before your resizing filter or the output is floating already?
__________________
@turment on Telegram |
7th October 2024, 18:04 | #224 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,369
|
They are exactly the same as the core functions. Parameters target are interger, src are float.
I don't realy understand the question about the ouput. The data depth is the same as the input, if picture data input is float, picture data output is float.
__________________
My github. |
7th October 2024, 20:46 | #225 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,069
|
Quote:
For instance: Code:
ColorBars(848, 480, pixel_type="yv12") Spline64Resize(848, 478) Code:
ColorBars(848, 480, pixel_type="yv16") Spline64Resize(848, 479) Code:
ColorBars(848, 480, pixel_type="yv24") Spline64Resize(848, 479) Code:
ColorBars(848, 480, pixel_type="RGB24") Spline64Resize(848, 479) Anyway, encoding files with an odd resolution is a very bad behavior and I know a person or two who would try to find you and scold you if they were to get in touch with a similarly encoded file hahahahahahha Quote:
TL;DR just resize to even pixels and encode it. |
||
8th October 2024, 18:05 | #226 | Link | |
Registered User
Join Date: Jul 2018
Posts: 1,207
|
Quote:
1. Frame/canvas size 2. Image size 3. Resolution 1. Frame or digital canvas size always integer (simply number of samples) 2. Image size can be any real number in size (also the position too) and in the beast case Image size < Frame size. For example at ADC of Analog TV line (ITU Rec.601 and later) it takes 702 samples of 720 frame size. Outer samples help to encode transients from edge of line to the 'known level' and it is black level. With your fractional V image size it is better to add some padding to digital frame size to keep these transients (also you need to shape/prepare/condition these transients in a good way so any upscale resizer at display will create nice image borders without Gibbs ringing). The 'pure digital' standards like DV and many more others with 'all-samples active image') are not completely defined at the image edges and require some hacking at the image processing to handle image edges of 'special case' (typically as some extension of last sample to half kernel size or other ways to fix edge issues). 3. Resolution is property of image data and can be from zero to max (soft of Nyquist and Gibbs limited). Here is some simple drawing how Image can be positioned inside Frame https://ibb.co/d23F04C After you prepare an Image inside Frame (Digital) you can perform a non-integer scale (and shift) to fine tune your image in digital form on digital canvas. If resizer filters do not support real number direct scale - you can use upsize to N and downsize to M integers so output will have N/M real numbered size. Any avisynth resizer should support integer-sized resize (also see chroma subsampling limitations if used). So with AVS resizers you operate with Frame/canvas integer sized objects all the time but your Image inside this Frame can be real numbered in size and position (relative to sampling grid). Similar to any real object in the image. You can treat Image as largest possible object in the digital Frame. If you set Image size = Frame size you lost about half samples to proper encode Image size and position in real numbers space. And force display scaling to work in harder way to make some more or less nice scaling at the edges if image. For N.x Image size you anyway need to use Frame size at least of N+1 or more integer. For less scaling aftifacts it is recommended to pad source frame enough before scaling and make scaling to output Frame size and try to Crop as many Frame samples around Image as you decide (also test with your display scalers how they will handle such prepared Image edges - simple scalers can make more halo or even ringing at poorly conditioned Image edges). In a 'perfect digital world' we need to have some 'safe area' around Image in the Frame and auto-overscan in the display device to cut-off this transient area to show only Image area limited by hardware frame of display device. Like emulating physical overscan at CRT display device. If user set zero overscan at display device it will cause some issues like black border at white areas near frame edge (or any other level of Frame edge defined). If display device also black frame over Image area it may be minor issue. Last edited by DTL; 8th October 2024 at 18:35. |
|
20th October 2024, 19:50 | #228 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
I am going thru a very strange bug with SinPowResizeMT and lineart.
It produces really jagged lines with halo "sparks" (please, zoom the image). Here you can find a sample of the video. SinPowResizeMT script: SetMemoryMax() SetCacheMode(0) SetFilterMTMode("DEFAULT_MT_MODE", 2) LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll") DGSource("M:\Out\Shangri-La 01 11151-11228.dgi") SinPowResizeMT(1656,932,threads=1) Prefetch(2,6) Frame 33: Spline64ResizeMT script: SetMemoryMax() SetCacheMode(0) SetFilterMTMode("DEFAULT_MT_MODE", 2) LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll") DGSource("M:\Out\Shangri-La 01 11151-11228.dgi") Spline64ResizeMT(1656,932,threads=1) Prefetch(2,6) Frame 33: Any idea?
__________________
@turment on Telegram Last edited by tormento; 20th October 2024 at 19:53. |
20th October 2024, 22:37 | #229 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,207
|
Some downsizers are not 'universal' with default control params. Try to set a higher p-param value if your source is too sharp. Like p=2.6 or even 2.7 or higher. With p > 3.0..3.2 it will be close to gauss and may be too soft. Default p may be about 2.5 and it may be too 'sharp' for very sharp sources (and low downscale ratio).
Also SinPow resize is not completely perfect and only more simple to control by the average user with simply 1 control param. If it does not work nice with your source it is recommended to try more 'linear' and somehow more complex to control UserDefined2Resize(MT) . The b and c initial params you can see at table https://forum.doom9.org/showthread.p...50#post1951250 and s-param may be about 2.0..2.2 for better 'sharp/crisp' result but if your source already too sharp you may set s to 3.0 or more to allow filter to be more 'linear'. Downsizing is a complex task and requires user control to get better results. Also required 'look/makeup' about balance between flat/sharp/ringing or other distortions. Last edited by DTL; 21st October 2024 at 13:08. |
21st October 2024, 11:07 | #230 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
I hoped that SinPower could be a general purpose filter and I expected haloing but not line distortion, that's why I reported.
Is it normal that a resize filter deforms lines so much? Please notice that your link to the table is broken. If you have some values to start with this kind of scenario, you are welcome.
__________________
@turment on Telegram |
21st October 2024, 13:07 | #231 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,207
|
The link is to post #179 in this thread. Will try to fix it.
The image hosting looks still working - It may be enough good for 'natural' sources like broadcast cameras and film scans. But some sources may cause issues. If it do not work for you with your sources and default params - you can either tweak params or try different resizer. I still not able to download your source - will try later from different provider and at different machine. My home machine is currently bugged with some issues with browser updates and I do not have time to fix it. Last edited by DTL; 21st October 2024 at 13:13. |
21st October 2024, 14:30 | #232 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
Nice!
Are the c,d,e values the result of a formula or determined by some kind of trials and errors? It would be nice to have a .avsi capable, given b, to ask for how much sharpness/softness we want and give the correct parameters to the other values.
__________________
@turment on Telegram |
21st October 2024, 15:37 | #233 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,207
|
They are adjusted manually via sinc-summing web-scripting application. They are recommended values but only expected to be mostly valid with infinity downscaling ratio (or at least > 10:1). With a low downscaling ratio best b and c (or c for some given b value) may be somehow different.
Possible adjusting workflow: set b value for some expected sharpness/peaking and adjust c for lowest possible ringing. Currently only the b and c 2 members version is implemented (so name is UserDefined2). If 2 members are not enough for some precise adjustment - the d and e (and any more) may be easily added. In general form it may be UserDefinedN if someone will program any number of input arguments (like string with , separated or any other separation of float numbers). But easy enough was to program 2 members as separated b and c params. "It would be nice to have a .avsi capable, given b, to ask for how much sharpness/softness we want and give the correct parameters to the other values." I had the same idea. But for any given source the best c (d,e,..) combination with any given b-member may be different (depending on both source and downscale ratio). Some way to adjust c (and possible other members) - feed output to waveform monitor and find some sharp enough transient and adjust c (and other members if present) to get lowest possible ringing (or some balance between sharpness and ringing). Where first b-member mostly control overall shape of transient (soft/flat/peaked). Addition: I got your source and made tests - the Spline64Resize works about very good with this footage. About close to this is UserDefined2Resize(1656,932,b=80, c=-20, s=2.0). Differences with SincLin2Resize(width*2, height*2) testing: 1. Spline64Resize on most lines sharper (thinner lines), very few places with some ringing. 2. UserDefined2Resize - on most lines softer (thicker lines and some peaking), looks about no ringing, still some jagginess on lines present. More softer version with less residual distortions is UserDefined2Resize(1656,932,b=90, c=-12, s=3.0) (larger support and longer peaking/halo around transients). More simple and hacky short support SinPowResize is completely looser at this specially peaked anime source - with default p=2.5 too many distortions and with p=3.2 it going into too soft. I think users like to use more simple and sharper Spline64Resize and may be very few can see some ringing (at some places at some displays with long sinc kernel scaler). Though the real viewing experience may significantly depends also on display size and viewing distance - too thin 'peaking/halo' may going out of viewer's resolution and image with some more thicker peaking/halo may look visibly sharper (typical 'video' look/makeup). So you can test different production scalers with your own displays (and its sharpen settings) and your typical viewing distance. Last edited by DTL; 21st October 2024 at 20:55. |
21st October 2024, 21:24 | #234 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,207
|
As you see at some real use cases the more simple and short kernel of SinPowerResize may be not any good. So for broadcast purposes it may be recommended to switch from SinPowerResize to UserDefined2Resize in FFASTrans application. The UserDefined2Resize may be more 'fail safe' in such possible use cases as this anime sample. The best defaults values for b,c,s params are subject of big testing with many real footages (including such anime cases) may be with some weighting to different footages classes (real broadcast/ENG/EFP cameras, film scans, such anime if possible and may be others). As some small enough testing shows typical values may be around b=80 c=-20 s=3.0 (may be tested range of 2.0..3.0 with initial close to 2.5..3.0).
Last edited by DTL; 21st October 2024 at 21:27. |
21st October 2024, 23:34 | #235 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,069
|
I think that line art as those in anime are a very edge case. Before putting SinPowerResize() in production via FFAStrans I've been testing it on a lot of footages and I manually checked several different real life footage without ever finding any issues, from penguins in ice to otters chilling on a stone on the side of a river to urban areas with buildings to trees and grass in a park to people and their faces etc. I was looking for ringing and aliasing and it never created anything as weird as the images posted above. I think that with natural footage we're fine and that's the predominant use case, but yeah, now that I know that for things like anime it doesn't work, I'll go back to using LanczosResize() or BlackmanResize() when I'll come across that kind of content. After all, they're windowed Sinc so they should be fine. I'm not gonna go with things like GaussResize() unless it's a last resort as it's far too soft. At the same time, I'll never gonna use Spline based resizers to downscale as they're known to be introducing ringing and I've seen it with my eyes back in 2013 in my first job at Crunchyroll. Anyway, I've been working for Sky for almost 9 years now, so I haven't really been encoding anime for a really long time. It's almost exclusively natural footage. As for FFAStrans, you have now given me a bit of an headache, but I guess I'm gonna have to revert to either Lanczos or Blackman by default 'cause if something like that comes up without anyone checking it and it's performing the downscale automatically in production bad things are gonna happen and there won't be anyone QCing it given that most stuff nowadays are all handled automatically.
|
22nd October 2024, 04:58 | #236 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,207
|
For downscaling single windowed sinc is not enough (too narrow). So UserDefined2 is a weighted sum of several (standard sampling interval 1 sample shifted) sincs. And it is enough self-windowed with that set of weighting coefficients from table.
The kernels of Gauss, SinPow and UserDefined2 are of special 'family' of 'wide kernels' with some low-pass filtering effect required for supress Gibbs ringing. Also with adjustable width of the main lobe. Many others of single windowed sincs (Lanczos or Blackman or many many other window-named) are not so only good for upscale. About Spline I not sure but if the graph of http://avisynth.nl/index.php/File:Spline.jpg is correct - it also have first zero at x=1 (+-1) as standard sinc so too narrow for downsize. "it never created anything as weird as the images posted above." The distortions may be increased in case of 1. Too sharp/peaked source + 2. Too small downscale ratio (below 2:1) + 3. Non-integer scale ratio (about 1.159:1). If you test something like UHD to FHD downscale or lower it may perform with less distortions. You may add some more auto-logic into FFASTrans like special case of downsizing with very small ratio range like from 1.001:1 to about 1.4:1 (subject to test) and recommend some other downsize engine instead of SinPow with default p-param (also depends on input source sharpness). Or at least note (warning) to user to check output in this case. Last edited by DTL; 22nd October 2024 at 06:44. |
22nd October 2024, 12:10 | #237 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
I can't understand the sensitivity of p parameter in SinPow: p=1-2 are the sharpest but with lot of artefacts.
In the 1-100 range of p parameter, even 4 makes the picture softer than Spline.
__________________
@turment on Telegram Last edited by tormento; 22nd October 2024 at 13:49. |
22nd October 2024, 13:53 | #238 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,797
|
Every day I understand how much I ignore.
Such as in 420 chroma is half the resolution of luma, isn't better to downscale like Y = ConvertToY(matrix="Rec709").Spline64ResizeMT(resX,res,threads=1) U = UToY().Spline64ResizeMT(resX*2, resY*2 ,threads=1) V = VToY().Spline64ResizeMT(resX*2, resY*2 ,threads=1) YToUV(U, V, Y) And if positive, how much should I move chroma in the ConvertY line? Another option could be AiUpscale(Factor=1, CResample="KrigBilateral", Mode="LineArt", OutDepth=16) but I'd like to keep things as simple and fast as possible.
__________________
@turment on Telegram Last edited by tormento; 22nd October 2024 at 14:26. |
22nd October 2024, 15:46 | #240 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,069
|
Quote:
Quote:
Yep, I will definitely write something under the "?" button and in the documentation, that's for sure. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|