Алгоритмы масштабирования изображений для AviSynth (ресайзеры)

Страницы:  1

Ответить
Автор
Сообщение

Lenchik

Стаж: 12 лет 4 месяца

Сообщений: 855


Lenchik · 27-Мар-12 20:03 (6 лет 7 месяцев назад, ред. 01-Май-15 13:56)

[Цитировать] 

Обобщаю информацию ресайзерам и их качеству1 Ресайзеры, не входящие в комплект Avisynth
SplineResize plugin - SplineResize_v02.zip (Spline100Resize, Spline144Resize, SplineResize)
Информация от автора на английском
This plugin contrains two kinds of spline based resizers:
The first ones are the (cubic) spline based resizers from Panorama tools that fit a spline through the sample points and then derives the filter kernel from the resulting blending polynomials. See this thread for the details. Spline100Resize (using 10 sample points) and Spline144Resize (using 12 sample points) are added here. Other ones are available in AviSynth itself.
The second ones are natural cubic splines that use the kernel itself as a spline. The theory can be found here.
Dither_resize16 16-битный (или даже 32-битный на внутреннем уровне) ресайзер из плагина Dither.
Resizers Functions Pack основанный на плагине Dither. Предоставляет LinearResize(), RatioResize() и SpliceResize().
Описание от автора набора функций
Here is a pack containing useful functions for resizing.
LinearResize()
It revolves around the resizing functions in the Dither Tools but made as easy as a one-liner.
-It resizes in 32 bit, with lsb_in/lsb_out options.
-It automatically changes matrix when switching from SD to HD or viceversa. (You could skip resizing and use it only for matrix change in 32bit as well)
-Allows to resize in a linear fashion.
-Automatically detects colorspace (RGB or YV12)
Yes, you can easily call it the best resizer out there. Thanks cretindesalpes!
RatioResize()
OK, I already know the Pixel Aspect Ratio of my source, how can I preview it quickly? with RatoResize() of course : P
RatioResize(0.911,"PAR")
Ratio Resize is a simple preview purpose resizer based only on single figures, like PAR, DAR, % of original size, and 2 interesting modes for snapping a source width (or height) to a certain value with proportional overall scaling.
Some other options and insights in the script, check them out.
SpliceResize()
Not the best of these 3 of course, but anyways is there. This one is not really mine, it's only my take on the one found in this post.
The idea is to resize in bicubic (catmull-rom) for high contrast features, and spline64 for the rest. So you get a ringing free good quality resize. Test it out!
Подборка скриптов SeparateResize
Выдержки из описаний скриптов SeparateResize
madResize.avsi
Fast SeparateResize as madVR
nrLSResize.avsi
Non-ringing Lanczos/Spline Resize
Algorithm is here: http://forum.doom9.org/showthread.php?t=145358
SoftCubicResize.avsi
SoftCubic Resize from madVR
SeparateResize_v1.4.avsi
Код:
### Resize Luma and Chroma separately
### Requires Repair if nr=true: http://home.arcor.de/kassandro/prerelease/RemoveGrain-1.0.rar
### +-------+
### | USAGE |
### +-------+
###
### SeparateResize(int target_width, int target_height, float src_left, float src_top, float src_width, float src_height, string LumaR, string ChromaR, string LumaPara, string ChromaPara, bool nr, string matrix, bool info)
###
### +-----------+
### |  GENERAL  |
### +-----------+
###
### target_width, target_height [int, default = the resolution of input clip]
### ----------------------
### Same as avisynth internal resize filters
###
### src_left, src_top, src_width, src_height [float, default = 0]
### ----------------------
### Same as avisynth internal resize filters
###
### LumaR, ChromaR [string, default = "LanczosResize"]
### ----------------------
### Resizers for Luma or Chroma
###
### LumaPara, ChromaPara [string, default = null]
### ----------------------
### Additional parameters of each resizer
###
### nr [bool, default = true]
### ----------------------
### Use repair to remove ringing introduced from Luma Resizer
###
### matrix [string, default = "Rec601" for SD resolution input / "Rec709" for HD resolution input]
### ----------------------
### Same as "matrix" of avisynth internal ConvertToYV12 filter, affects only RGB input clip
###
### info [bool, default = false]
### ----------------------
### If set to true, clip properties and resize settings will be drawn on the video frames.
###
### +---------+
### | EXAMPLE |
### +---------+
###
### Apply Crop(8, 0, -8, 0) with resizer's internal crop function and then use GaussResize(p=40) for Luma and BicubicResize(b=0.2, c=0.5) for Chroma to final resolution 704x480, with clip properties and resize settings drawn on the video frames:
###
### SeparateResize(704, 480, 8, 0, -8, 0, LumaR="GaussResize", ChromaR="BicubicResize", LumaPara="p=40", ChromaPara="b=0.2, c=0.4", matrix="Rec601", info=true)
MultiSWAR_V2-Beta4 от *.mp4 guy и модифицированный Dogway.
Описание MultiSWAR_V2-Beta4 из скрипта
Код:
# MultiSWAR - Multi Step Warping And Resizing - V2 Beta 4
#
#
#             by *.mp4 guy (07-02-2007)- http://forum.doom9.org/showthread.php?t=112526
#
# It is designed to reduce the blurring and aliasing associated with linear resizing,
# without introducing additional artifacts or being too slow for practical use.
#
#
#             Beta 4: adapted for masktools2 and awarpsharp2 (Dogway) (13-05-2011)
#
#   Dependencies:
#
#         Tbilateral   (http://web.missouri.edu/~kes25c/)
#         dctfun4b     (http://forum.doom9.org/showthread.php?t=114526)
#         frfun7       (http://forum.doom9.org/showthread.php?p=825604#post825604)
#         medianblur   (http://avisynth.org/tsp/)
#         variableblur (http://avisynth.org/tsp/)
#         warpsharp    (http://avisynth.org/warpenterprises/)
#         awarpsharp2  (http://forum.doom9.org/showthread.php?t=147285)
#         MaskTools2   (http://forum.doom9.org/showthread.php?t=98985)
#
# DestX/DestY: Default 2x input resolution. Sets the output resolution
#   (yes its really obvious)
#
#
# StepRatio:  Determines how many iterations of resizing wil be
#     needed to reach your destination resolution, the default is 4.
#     Higher values are slower but should remove more alliasing.
#     High values may result in more artifacts. The usable range is
#     1 to around 16.
#
#
# Smoothing:  When Smoothing is enabled (Which it is not by
#     default) a light noise reduction filter is used to help avoid
#     sharpening artifacts from the source image, this is most
#     usefull for animated content.
#
#
# Sthresh:  Sets the strength of the smoother, default value is 1
#     useful range is 0 to ~8.
#
#
# Sharpen:  Sets the amount of sharpening aplied by the main
#     sharpening functions, usable values are 10 to 65
#     depending upon your source, the default is 40
#  higher values run the risk of aliasing and banding.
#
#
# Sharpen2:  Sets the amount of additional sharpening to be aplied
#     to the video, used to make faint details more prominent
#      usable values are 0.33 to 1 depending upon the source.
#     The default value is 1 which doesn't usually cause any
#  problems, both this and sharpen are also affected by
#  the masking parameters, higher values run the risk of
#  excessive noise and banding.
#
#
# Warping:  The strength parameter for Warper. The default of 4
#     should work the best on film, 8 is a good value for animated
#     material. if you are getting aliasing you can raise this value
#     to get rid of it. The acceptable range is 0 to 64. Unless
#  chromawarp is specified separately this parameter has a maximum
#  value of 10.
#
#
# chromawarp: Default warping*25. Chroma warping, usefull range 100-255.
#
#
# SSm:  Default 2. Sets the supersampling used during mask creation,
#  don't change it.
#
#
# bmrad  Default 7. Sets the radius used to detect details during mask
#  creation, higher values are slower, but probably better, the
#  default is adequate in almost all situations.
#
#
# thr:  Default 0.65. Sets the threshold for detail detection, worth
#  experimenting with, higher values makes more things detected as
#  details, higher values may cause oversharpening.
#
#
# dthr  Default 245. Sets how strongly the mask protects against
#  oversharpening, higher values give more protection, 0 gives
#  none. does not need to be set in quotes anymore.
#
#
# dbias:  Default 25. Determines how detailed areas are treated, higher
#  values cause them to be treated more like lines, lower values
#  (down to 0) cause them to be treated more like texture. does
#   not need to be set in quotes anymore.
#
#
# lthr:  default 25. The same as dthr, but used to protect lines from being
#  oversharpened, oversharpening causes aliasing.
#
#
# lbias: default 225. The same as dbias, but used on lines, higher values
#  cause less overall sharpening of lines and detail that
#  would otherwise be treated as lines.
#
#
# hthr/hbias: The same parameters as d/llthr and d/lbias, used in the
#  creation of the halo prevention mask, higher values
#   offer more protection, defaults are hthr=48, hbias=-48
#
#
# srad:  Default 1. Sets the radius of the sharpening used on
#  detailed areas.
#
# mmrad: default 4. Sets the radius used in creating the median mask
#
#
# agmrad: default 1. sets the radius used in creating the halo mask, higher
#  values give more protection against halos, but will cause bluring.
#
#
# reducehalos: Default true. enables halo protection, will not reduce halos
#  in the source, only those added by multiswar.
#
#
# lanczos: Defualt true. enables use of lanczos resizing instead of
#  spline36 resizing, lanczos is sharper but more artifact
#  prone, good for film content.
#
#
#
#Misc parameters:
#DestX
#Desty
#Stepratio
#warping
#chromawarp
#SSm
#sthresh
#Sharpen
#Sharpen2
#thr
#
#Masking parameters:
#dthr
#lthr
#hthr
#dbias
#hbias
#lbias
#
#Radius parameters:
#Srad
#bmrad
#mrad
#agmrad
Jinc Resizer (пока только для увеличения, поскольку madshi в madVR ещё не воплотил (14.01.2014))
Фильтр против звона Jinc36Resize
http://forum.doom9.org/showthread.php?p=1655611#post1655611
Код:
Function nrJinc36Resize(clip input, int "target_width", int "target_height", float "src_left", float "src_top", float "src_width", float "src_height"){
  Assert( input.IsPlanar(), "nrJinc36Resize: only planar color spaces are supported!" )
  target_width  = Default( target_width,   width(input) )
  target_height = Default( target_height, height(input) )
  src_left      = Default( src_left,                  0 )
  src_top       = Default( src_top,                   0 )
  src_width     = Default( src_width,                 0 )
  src_height    = Default( src_height,                0 )
  return input.Jinc36Resize(target_width, target_height, src_left, src_top, src_width, src_height)
  \           .Repair(input.GaussResize(target_width, target_height, src_left, src_top, src_width, src_height, p=100), 1)
}
2 Имеющиеся тесты ресайзеров
AVISynth resizing filter comparison
Содержание AVISynth resizing filter comparison (на английском)
This comparison table was created using AviSynth 2.5.7. The Zone Plate test pattern was created by Ken Turkowsky. It has been processed by AVISynth. Each filter was called by his default preferences. The one-frame-video was then converted to png by IrfanView.

This Zone Plate was used.
Magnification
The square was magnified by two in eight steps 32 pixels each.

magnified using a bicubic filter (standard preferences)

magnified using the bilinear filter

magnified using the gaussian filter

magnified using the lanczos filter

magnified using the lanczos4 filter

magnified using the point filter

magnified using the spline16 filter

magnified using the spline36 filter
Minimation
The square was downsized to it's half in eight steps 16 pixels each.

downsized using a bicubic filter (standard preferences)

downsized using the bilinear filter
[img]http://hermidownloads.craqstar.de/videoresizefiltercomparasion/downsized/avs_gauss.png"[/img]
downsized using the gaussian filter

downsized using the lanczos filter

downsized using the lanczos4 filter

downsized using the point filter

downsized using the spline16 filter

downsized using the spline36 filter
Modified 2007-07-26 by Hermann Höhne hoehermann(swirly thing)gmx(small square)de
Upscaling in Avisynth – Comparison of resizers
Выводы Upscaling in Avisynth – Comparison of resizers
What we can see, looking at the numbers, is that the higher the resolution of your source (or better, the more details the source has) the better upscaling works. If your source is too blurry, upscaling won’t work as good as it could. All scalers perform quite good (except for point and sinc, but that was to be expected). Spline16 performs worse than spline36 and spline64, for upscaling spline36 performs better than spline64. Lanczos and spline are quite similar the difference is very minimal, according to the numbers, lanczos performs better than spline; overall best resizer for upscaling is nnedi3. Another thing which you can see in the visual results above is that the nnedi3 image doesn’t have the stairs-effect.
If you have to decide which resizer (in avisynth) to use for upscaling, go this route:
nnedi3 > lanczos/lanczos4 > spline36 > everything else
Тест 1 от NcryptoR
Результаты теста 1 от NcryptoR
Оригинал.
Проведён downsize 1280х1024 → 720х576.
Bicubic - Bilinear - Blackman - Lanczos4 - Lanczos - Spline36 - Spline64 - Spline100 - Spline144

Размер выходного изображения в байтах в порядке возрастания:
  • BilinearResize - 459 284 байт
  • Spline100Resize - 499 301 байт
  • BicubicResize - 532 979 байт
  • Spline144Resize - 561 401 байт
  • Spline36Resize - 603 807 байт
  • BlackmanResize - 606 463 байт
  • LanczosResize - 611 641 байт
  • Spline64Resize - 646 661 байт
  • Lanczos4Resize - 699 001 байт
    * Применение группы ресайзеров, выделенных зелёным цветом, в большинстве случаев, думаю, можно считать оптимальным с точки зрения соотношения вес/шарп. Но выбирать, естественно, вам самим.
Тест 2 от NcryptoR
Результаты теста 2 от NcryptoR
Downsize by half:
Bicubic - Bilinear - Blackman - Lanczos - Lanczos4 - Sinc - Spline36 - Spline64 - Gauss - Point

Upscale x2:
Bicubic - Bilinear - Blackman - Lanczos - Lanczos4 - Sinc - Spline36 - Spline64 - Gauss - Point

Spline100/144 изображение не прожевали.
ResampleHQ kernel visualizations
Аннотация kernel visualizations на английском
This page attempts to visualize various resampling kernels in a way that will help to you choose which one is right for you. There is no "best" kernel — they all have their uses and the right one for will depend greatly on both the source and personal preference.
Scaling artifacts and resolution
Импровизированный тест из http://www.4p8.com/eric.brasseur/gamma.html
тест
Цитата:
Прислал Jonas Berlin. Уменьшите это изображение в два раза (1:2) вашим методом...
3 Обсуждение проблем и решений по ресайзерам
Lobes vs taps, автор dmunsil, 4 декабря 2004.
Lobes vs. Taps. The short version
Any signal-processing filter has "taps" which are the discrete input values that are used to calculate each output value. In audio processing it's pretty straightforward - a 20-tap FIR resampling filter takes 20 audio samples, multiplies each by one value in a 20-element filter "kernel," adds all the results together, and spits out a single output sample. Lather, rinse, repeat. In video it's a little different, but that's the rough idea.
When a filter is based on a windowed sinc function (sinc is (sin(x)/x)), it's convenient to talk about the number of lobes of the sinc function that are being used. X=0 to X=pi is one lobe. X=pi to X=2pi is another lobe. X=2pi to X=3pi is another lobe and so forth. Because all windowed FIR sinc filters are symmetrical around 0, we only talk about the number of lobes on one side of 0. There are an equal number of lobes on the the other side.
So when people talk about Lanczos2, they mean a 2-lobe Lanczos-windowed sinc function. There are actually 4 lobes -- 2 on each side. The function, graphed in the range -2pi to 2pi looks kinda like a sombrero. I've attached a graph of Lanczos2. Catmull-Rom looks almost identical, but is not a windowed sinc filter, or in fact any kind of sinc filter. The fact that two resizing filters created using completely different mathematical principles look almost identical is not a coincidence, but understanding why it turned out that way was certainly a big ah-ha! moment for me. And way too complicated to explain here, sadly.

For upsampling (making the image larger), the filter is sized such that the entire equation falls across 4 input samples, making it a 4-tap filter. It doesn't matter how big the output image is going to be - it's still just 4 taps. For downsampling (making the image smaller), the equation is sized so it will fall across 4 *destination* samples, which obviously are spaced at wider intervals than the source samples. So for downsampling by a factor of 2 (making the image half as big), the filter covers 8 input samples, and thus 8 taps. For 3X downsampling, you need 12 taps, and so forth.
The total number of taps you need for downsampling is the downsampling ratio times the number of lobes, times 2. And practically, one needs to round that up to the next even integer. For upsampling, it's always 4 taps.
So a 2-lobe (which is really a 4-lobe) Lanczos filter could require any number of taps. To downsample a 1080p image down to 108 pixels high would require 40 taps.
All of these numbers are, of course, just in one dimension. To get the full number of taps required for an output pixel, you would theoretically calculate the number of taps required in each dimension (height & width) and then multiply them together. So upsampling would require 4x4=16 taps. By convention, though, we still call that a 4-tap filter (unless we're in marketing, and then we call it a 48-tap filter: 16 taps times 3 components R, G, and B ).
Practically speaking, for performance you would always scale the image in two passes, which is perfectly kosher (or at least it is with these filters, which are *separable*, meaning that we can apply them separately in X and Y and get the same result as applying the combined filter). Conceptually you scale just in the width dimension into a new buffer that is as wide as the target image and as high as the original. Then you scale that intermediate image just in the height dimension into a final target buffer. Thus in the upsampling case you are applying two 4-tap filters instead of a single 16-tap filter.
Again, there are a huge number of practical considerations. You end up pipelining things very differently than the "conceptual" algorithm, mainly to maximize cache coherency. In order to do any kind of arbitrary scaling, you need to calculate a large number of filter kernels, as the phase between the input and output samples changes as you work your way across the image.
Man, if that's the short version I hope I never have to write the long version. Again, the thing to do if you want to understand practical scaling algorithms is to read the Turkowski paper I referenced earlier in the thread and read the code for Paul Heckbert's "Zoom" (it's not the cleanest code in the world, but understanding why he does various things is a real education). Start there and then branch out.
And if you have questions, you can always email me. My email address is not hard to find. I can't always promise I can answer every question, as among other things some of the stuff I'm doing right now with scaling is about to be patented, but I'm happy to steer folks in the right direction.
As for the questions about the best ways to use ffdshow, I have to admit that I don't know. At home I use the scaler built into the VW10HT, which looks to me like a basic bicubic, which is perfectly fine. At work I use my own scaler. I don't really have time to evaluate ffdshow extensively.
I will say that I am adamantly against filters with more than 2 lobes when scaling images. Their advantage is extra sharpness, but they ring like crazy. In my own scaler, I adjust sharpness by combining a modified sharpening kernel with the basic scaling kernel. It makes the image just as sharp as a multi-lobe Lanczos, but without the multi-lobe ringing.
Here's Lanczos3.

Here's Lanczos10. The extra-deep first negative lobe (from 1 tp 2 and -1 to -2) gives you the extra sharpness, but all the other lobes (beyond 2 and -2) produce annoying fringes around sharp edge transitions. Bleah.
The perception of sharpness in an image scaling filter is almost entirely related to the depth of the first negative lobe. The more lobes you put on a Lanczos (or any other windowed sinc) the deeper the first negative lobe gets. But that's an incredibly pricey way to deepen the negative lobe, and has ugly side effects. There are lots of other ways.
Сообщение dmunsil от 14 декабря 2004 года насчет linear light resize.
dmunsil писал(а):
For best results, scaling should in fact be done with linear-light values, not gamma-corrected values. And of course it should be done in RGB, not Y'CbCr, since Y'CbCr values aren't even gamma-corrected values, they're a linear combination of gamma-corrected values. Mathematically, processing in Y'CbCr is a complete abomination. Practically, it works sorta OK and requires a lot less CPU, so people go ahead and do it.
The best pipeline for scaling images in a Y'CbCr space is:
Y'CbCr->R'G'B'->RGB->[scale]->RGB->R'G'B'->Y'CbCr
Obviously the downsampling and upsampling of the chroma channel for 4:2:0 or 4:2:2 has an effect on the final image, but it can't be helped (other than by not using 4:2:0 or 4:4:4).
Re: Resizing artifacts with Lanczos by adx 2010-11-14
adx писал(а):
I just had to say - one thing that can provoke a resize filter is sharp-edged text: This situation (a step from 0 to full intensity) can't occur in "ordinary" sampled image data (properly bandlimited/antialised and not clipping highlights). Filters which work really close to the Nyquist limit (like a high-lobed Lanczos) don't like it. But nor do they like high downsize ratios which have a similar effect - it's just a tradeoff between steepness of cutoff (frequency domain) and ringing.
My excitement on finding that image resizing is generally done wrong (not in linear space) was also dampened when I realised that this wrongness also hides ringing. The best I have done in situations where it is a big problem is to use a less 'ringey' filter (eg bessel) with some post-sharpening. This has the same effect of boosting / retaining high frequencies (as a sharp cutoff filter), but also boosts the aliasing which is rarely a big problem. This adds another degree of freedom to the compromise and can give excellent results. (I have been battling away at finding a good image downsizer for years!)
Another problem I have had with IM Lanczos is the square fiter kernel: It gives a kind of "diagonal noise" look to textures with a lot of sharp content (eg leaves from a distance). If I get time some day I'll experiment with round kernels of varying sizes.
Towards Better Chroma Subsampling
ImageMagick v6 Examples — Resize or Scaling — рассуждения и примеры работы ресайзеров (последнее обновление 30 марта 2011 года).
Gamma error in picture scaling
http://forum.doom9.org/showthread.php?p=1506374#post1506374
Gavino с forum.doom9.org от 7 июня 2011 года писал(а):
I'm not sure yet what the solution is, but the way the shift happens is as follows.
The resizer core is designed to preserve the position of the image centre, and it does this for both luma and chroma independently.
This works fine for vertical resizing, since in that case the centres of the luma and chroma sampling grids coincide for all formats (including YV12, where the chroma samples are vertically positioned between the luma samples).
But for horizontal resizing (except YV24), the placement is such that the luma and chroma centres do not coincide - in each case the chroma centre is to the left of the luma centre.
Eg for YV12 and YUY2:
Код:
luma centre
                       |
Luma:   L L L L ... L L L L ... L L L L
Chroma: C   C   ... C   C   ... C   C
                      |
                  chroma centre
Since the distance between the two centres is proportional to pixel spacing, it changes on a resize.
For upsizing, pixel spacing decreases, so the chroma centre moves closer to the luma centre (hence to the right), and conversely for downsizing it moves to the left. Since the output chroma is calculated based on a fixed centre, the visual result is a corresponding chroma shift, right for upsizing and left for downsizing.
We can quantify the shift as follows.
For YV12 and YUY2, the chroma centre is 0.5 luma pixels to the left of the luma centre.
When resizing from width Win to Wout, output pixel spacing in terms of input is multiplied by Win/Wout.
Hence the net (rightwards) chroma shift is a distance of 0.5*(1-Win/Wout) input luma pixels.
For a 2x upsize, this equals 0.25, for a 2x downsize it's -0.5 (ie 0.5 to the left).
Similarly, for YV411, the net shift is 1.5*(1-Win/Wout), ie 3 times as much as for YV12/YUY2.
Gavino писал(а):
Reel.Deel писал(а):
SEt писал(а):
Also do note that current resizing functions always process chroma as MPEG1, while conversions process it as MPEG2 by default.
So for example, if I load a YV12 picture with MPEG2 chroma placement and resize with Spline36Resize(width/2, height/2) it's wrong?
Yes, there is a slight (usually imperceptible, but not always) horizontal chroma shift in the MPEG2 case.
Подробнее, начиная с http://forum.doom9.org/showthread.php?p=1505936#post1505936
1080p 4:2:0 в 540p 4:4:4 без изменения размера цветоразностных каналов: http://forum.doom9.org/showthread.php?t=170029
Gavino с forum.doom9.org от 14 января 2014 года писал(а):
The correct offsets are src_left=-0.50, src_top=0.
Avisynth resizers preserve the position of the image centre (treating the pixels as point samples).
For 4:2:0 with MPEG2 placement, the horizontal chroma centre is 0.5 luma pixels to the left of the luma centre.
Код:
luma centre
                       |
Luma:   L L L L ... L L L L ... L L L L
Chroma: C   C   ... C   C   ... C   C
                      |
                  chroma centre
Therefore, to make the resized luma coincide with the original chroma, you need src_left=-0.5.
Since the vertical centre positions are the same for luma and chroma, src_top=0.
The visual difference when using the wrong offsets (or no offsets) is very small except where you have a sharp chroma transition.
http://rutracker.org/forum/viewtopic.php?p=48927580#48927580
Tempter57 от 7 ноября 2011 года писал(а):
Выбор определяется качеством самого исходника. Если исходник некачественный с блочностью и звоном, то разумеется необходимо применять, например, BicubicResize. Если вы хотите сохранить повышенную детализацию, выполнить апскейл, чуточку добавить в резкости, то вам поможет это сделать Lacsozresize с taps=4...10 (чем выше значение, тем выше резкость, но больше вероятность появления артефактов в виде звона на контурах). Нейтральными считаются ресайзеры класса SplineResize 16...36, а вот SplineResize 64,100,144 уже могут несколько увеличить детализацию и резкость за счёт увеличения количества опорных точек, применяемых в ресайзере. Обычно последние применяются в аниме и использование их для фильмов никакого практического значения не имеет.
Сейчас при создании BDRip с качественных исходников модно применять BlackmanResize(x,y,taps=4).
ResampleHQ.dll это не совсем ресайзер, автор сам его называет фильтром. Вы можете задать любой ресайзер внутри из перечня в документации. В том скрипте, я как раз и задал именно BlackmanResize(x,y,taps=4):
ResampleHQ(1280, 720, srcmatrix="PC.709", dstmatrix="PC.709", kernel="Blackman", karg1=4, dither=true). Кстати, внутри ResampleHQ можно задать параметры кропа.
Этот плагин прежде всего интересен поддержкой технологии Dither, в нём можно также выполнить конвертацию цветового пространства YV12 в YUY2 и обратно, а также применять различные матрицы коэффициентов цветопередачи, можно сужать и растягивать диапазон, регулируя level . Этот плагин немного вытягивает изображение из тени, придавая некоторую контрастность изображения и визульно это немного похоже на улучшение детализации изображения. Более подробное пояснение вы можете получить на этой ветке http://forum.doom9.org/showthread.php?t=160038&highlight=ResampleHQ, непосредственно задав вопрос автору данного плагина. Не случайно ResampleHQ вошёл в перечень Avisynth 64-bit usage FAQ.
http://rutracker.org/forum/viewtopic.php?p=48950413#48950413
Tim68 от 8 ноября 2011 года писал(а):
Известный пример рассматривает работу с монохромными тестовыми изображениями. Интерес представляет именно цветовая гамма-коррекция при выполнении ресайза с которой судя по всему никак у встроенных в AviSynth ресайзеров. Пример ресайза (уменьшения) "карты ночного освещения континентов", приведенный в документации к фильтру ResampleHQ в первую очередь наглядно показывает насколько зрительно сильны потери без цветовой гамма-коррекции. На Мой взгляд это действительно долгожданное акцентирование внимания на существующей проблемме о которой многие либо не имеют представления либо просто не хотят о ней слышать. Отсутствие в документации примера настроек фильтра при которых был достигнут приведенный результат еще больше подливает "масла в огонь".
Тема Weird chroma placement c forum.doom9.org начатая в декабре 2011 года и
несколько цитат оттуда
Gavino писал(а):
Certainly, I would expect to see chroma differences between each case. ResampleHQ uses a gamma-aware method, whereas Avisynth is strictly linear. Even the two Avisynth methods will give slightly different results because the chroma resampling is arrived at in two stages by two different routes:
Case 1
RGB Original 600x900
To YV12 300x450
Resize to 100x150
Case 2
RGB Original 600x900
Resize to 200x300
To YV12 100x150
However, I would expect the chroma positioning for the two Avisynth methods to be the same.
A possible difference with ResampleHQ is that Avisynth resizers preserve the image centre position. I don't know if ResampleHQ does the same - perhaps it is designed to preserve some other point instead (eg top left corner). If so, the resultant images will have a relative shift between them (although this should affect both luma and chroma equally).
Gavino писал(а):
In Avisynth 2.58, ConvertToYV12() for RGB input goes via YUY2 as an intermediate step, so suffers from the problem I mentioned above. However, you are using v2.60, which goes instead via YV24, so that problem does not apply.
In your case, I think the differences between the two Avisynth examples are due to the horizontal resizing bug also mentioned above. I had forgotten about this (despite being involved in the diagnosis and discussion!) when I originally replied to your questions.
This only affects YV12, so doing the resize before the conversion gives correct chroma alignment, while doing it after produces a small horizontal chroma shift.
Gavino писал(а):
I believe the first one (horizontal shift in RGB->YUY2) is fixed in 2.60a3.
The second one (mixed vertical shift in interlaced YV12->YUY2) still exists unless you explicitly use at least one of the new parameters chromaResample or chromaInPlacement.
Gavino писал(а):
A small clarification just to get the details right.
Previously, I said:
Gavino писал(а):
In your case, I think the differences between the two Avisynth examples are due to the horizontal resizing bug also mentioned above. ... This only affects YV12, so doing the resize before the conversion gives correct chroma alignment, while doing it after produces a small horizontal chroma shift.
What I meant was, it doesn't affect RGB.
It does affect all horizontally subsampled YUV formats (YUY2, YV16 and YV411, as well as YV12, but not YV24).
For more details, see this post.
TheSkiller писал(а):
Just to make sure, does this in fact mean that [I]any[/I] YV12/YUY2 (and others) based resize with horizontal resizing involded does produce a horizontal chroma shift in 2.58 as well as 2.6?! If yes I'm quite shocked.
Gavino писал(а):
Yes it does (although there are no other YUV formats in 2.58).
Also affects previous versions too (perhaps all of them, I don't know).
It's surprising no-one realised it until recently, but it is quite hard to see for most real-world images, unless you have a very large resize factor (and then other artefacts come into play anyway).
http://forum.doom9.org/showthread.php?p=1482560#post1482560
Обсуждение алгоритмов апскейлинга в надежде найти оптимальный в теме по madVR от 21 февраля 2012 года.
http://rutracker.org/forum/viewtopic.php?p=52004297#52004297
MaLLIeHbKa от 21 марта 2012 года писал(а):
alfsuind писал(а):
linear light resize
Ради интереса, а на чём наблюдается практическая польза (кроме заезженной картинки с огнями городов→), особенно с учётом того, что по-хорошему обработку надо делать в RGB?
alfsuind писал(а):
Земля - крайний случай, показывающий максимальный эффект. Эффект тем сильнее, чем выше степень уменьшения (чтоб смешивались больше пикселей), чем мельче детали и чем выше их контраст. Теряется яркость этих мелких деталей. В крайнем до нереалистичности случае смешивается белый (0) и черный (255) цвет, обычный алгоритм не подозревает о гамме и дает 128, а с учетом гаммы объективно усредненное количество света - 187.
Пример: MeGUI вылетает, сумел сравнить уменьшение 720>360 простым spline36resize и им же в линейном пространстве люмы (в 16 бит, Dither_y_gamma_to_linear().Dither_resize16(640,360).Dither_y_linear_to_gamma(), в 8 бит). И то, и то, увеличено обычным ресайзом до 540.
См. цепочку скрипача и верх колонок.
Вот вчерашнее сравнение - 1080>576, после энкода crf 19. См. сверху и слева металлические конструкции, в центре символ группы и ниже барабанную установку и чуть-чуть вокруг.
Т.е., видимо, поможет со всякой светящейся фигней в "Аватаре" :).
MaLLIeHbKa писал(а):
особенно с учётом того, что по-хорошему обработку надо делать в RGB?
Я читал, что у RGB (такой плагин или аналогичный скрипт с dither) свои проблемы, к тому же разница небольшая. Но тот плагин несовместим с 16-битными (stack16), а аналогичный скрипт сложнее.
Edit:На своем скриншоте заметил проблему, из-за которой советуют перейти с spline36 на spline16.
MaLLIeHbKa писал(а):
alfsuind писал(а):
Я читал, что у RGB (такой плагин или аналогичный скрипт с dither) свои проблемы
Да, у RGB cвои проблемы (и с производительностью, и с совместимостью с фильтрами, и с апсемплингом хромы), но линеаризацию правильно делать именно в RGB:
http://www.avsforum.com/forum/26-home-theater-computers/460922-lanczos-vs-bicubic...html#post4811927
(dmunsil — один из авторов патента на linear light scaling, которым сейчас владеет Microsoft)
Madshi (автор madVR) уже давно и до сих пор думает, что с этим делать:
http://forum.doom9.org/showthread.php?p=1279308#post1279308
http://forum.doom9.org/showthread.php?p=1532185#post1532185
alfsuind писал(а):
Edit:На своем скриншоте заметил проблему, из-за которой советуют перейти с spline36 на spline16.
А поподробнее? (:
alfsuind писал(а):
Первый пример у меня до кодирования, второй после. Звон из-за ресайза :(. К ссылке с Madshi еще:
http://forum.doom9.org/showpost.php?p=1536162&postcount=146
http://forum.doom9.org/showpost.php?p=1536392&postcount=157
http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=17136#p65507
Т.е. нужно меньше negative lobe. В будущем попробую другой kernel в Y или RGB. Только вот какой? (Spline16? Blackman 2/3? Lanczos 2? Какой-нибудь bicubic?)
Edit: Посмотрел там их характеристики. Будем считать, что нам не нужно blurring и нужно максимальное sharpness (с ringing они вместе варьируют...) при самой слабой negative lobe. По четкости/звону:
1) Lanczos4. Слишком.
2) Lanczos3, чуть меньше - Spline36, Blackman4.
3) Spline16, Lanczos2, Blackman3, Catmull-Rom bicubic.
4) Blackman2.
Везде у Blackman на 1 lobe больше, чем у других, при той же negative lobe и sharpness/ringing по оценке. Это ему помогает? Еще затесался bicubic (b=0.0, c=0.5), м.б. его? Заинтриговал еще слабее других звенящий blackman2.
alfsuind писал(а):
MaLLIeHbKa писал(а):
alfsuind писал(а):
Какой-нибудь bicubic?
Ага, там есть из чего выбрать→ (: Как я поняла из постов madshi, ощутимые проблемы есть у всех, включая его незвенящий lanczos→. Если будете экспериментировать с оптимальными в linear light ресайзерами, отпишитесь здесь потом о результатах, пожалуйста.
Поэкспериментировал с lanczos (2-3), blackman (2-4), blackmanminlobe, spline (16-36 = 2-3). В общем, не врут схемы.
Принципиальных различий нет, больше taps - больше как четкость, так и звон (у blackman те же результаты при n+1 lobes). Т.е. spline36~lanczos3~blackman4. При тех же lobes lanczos чуть почетче/позвонче spline. Видимо, прав Madshi, что своего предела обычные алгоритмы достигли.
Линейный свет (из-за того, что в темных местах между соседними значениями больше различий) усиливает черный звон. Если сравнивать с обычным spline36resize, аналогично звенит только blackman2, но он и менее четкий, чем остальные.
Придется пока линейно не ресайзить?.. Посмотрим, что придумают.
Для обычного, нелинейного использования каков Blackman? Например, Spline36 vs Blackman4, который "пошире", что это дает?
Пример того, как делать при 16-битной обработке:
http://forum.doom9.org/showthread.php?p=1545110#post1545110
Цитата с примером
cretindesalpes писал(а):
You can also do the linear<->gamma conversion in the RGB colorspace:
Код:
Dither_convert_yuv_to_rgb (output="rgb48y")
Dither_y_gamma_to_linear (tv_range_in=false, tv_range_out=false, u=1, v=1)
Dither_resize16 (w, h, u=1, v=1)
Dither_y_linear_to_gamma (tv_range_in=false, tv_range_out=false, u=1, v=1)
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ lsb=false)
http://forum.doom9.org/showthread.php?p=1569936#post1569936
Gavino писал(а):
GaussResize(P=100) does provide a true nearest neighbour.
http://forum.doom9.org/showthread.php?p=1579385#post1579385
Didée писал(а):
for downsizing I'm often in favour of "bicubic with negative 'b' ", like e.g. bicubicresize(1280,720,-.5,.25). Neagtive b is hideous for upscaling, but comes very nice for downsizing. New rule: "b + 2c = 1 // for upsizing", and "b + 2c = 0 // for downsizing"
По поводу Jinc ресайзера из madVR:
degifly писал(а):
55632814
madshi писал(а):
(2) The "Jinc" (3 or 4 taps) image upscaling algorithm is totally new. It's somewhat similar to Lanczos, but Jinc is slower and has slightly higher quality. You can think of Lanczos as a rectangular resampling filter. In comparison Jinc is a circular resampling filter. Jinc is slightly softer than Lanczos, but it has very low aliasing artifacts (lowest of all algorithms) and ringing is less strong compared to Lanczos. Furthermore the madVR anti-ringing filter works especially well together with Jinc, so with the anti-ringing filter Jinc is pretty much ringing-free without any negative side effects that I could see. In certain situations Lanczos might look better (because it's slightly sharper than Jinc), but overall I believe Jinc beats Lanczos in quality, thanks to a more natural look with less ringing and aliasing artifacts. Jinc comes at a quite big performance cost, though. At low scaling factors, Jinc is comparable in performance to Lanczos8. However, with bigger scaling factors, Jinc3 can be twice as slow as Lanczos8 and Jinc4 twice as slow as Jinc3. Ouch...
А с 8 тапами это отличная пузомерка - даже при небольшом скейлинге просаживает даже мощные видяхи)
А, да, еще небольшое сравнение http://forum.doom9.org/showpost.php?p=1594557&postcount=14405
По поводу NNEDI3 http://forum.doom9.org/showthread.php?p=1663611#post1663611
madVR linear light scaling, NNEDI3, etc.
Новый виток обсуждений способов наподобие linear light resize в теме AviSynth 2.6.0 RC3 [Apr 15th, 2015] http://forum.doom9.org/showthread.php?p=1719505#post1719505
Примеры результатов и кода оттуда (степень адекватности обсуждается в оригинальной теме)
feisty2 писал(а):
how about even better, YCbCr→RGB→Linear RGB→CIE 1931→CIE Lab→Resize
http://www.imagemagick.org/Usage/resize/#resize_lab
DarkSpace писал(а):
CIELAB isn't linear, it's perceptual (which means perceived color differences, rather than actual ones, are linear), so I believe it is unsuited for resizing (where you want to compute an actual rather than a perceived weighting of colors.
[url="http://en.wikipedia.org/wiki/Lab_color_space#Perceptual_differences"]Just saying[/url], you know, for the record...
feisty2 писал(а):
source

regular
Код:
dither_convert_rgb_to_yuv (matrix="709",lsb=true,output="yv24",tv_range=False)
dither_resize16 (600,300)
dither_convert_yuv_to_rgb (matrix="709",lsb_in=true,output="rgb24",mode=6,tv_range=False)

new method
Код:
r=showred ("y8").convert8to16 (false).Dither_y_gamma_to_linear (tv_range_in=False, tv_range_out=False, curve="srgb")
g=showgreen ("y8").convert8to16 (false).Dither_y_gamma_to_linear (tv_range_in=False, tv_range_out=False, curve="srgb")
b=showblue ("y8").convert8to16 (false).Dither_y_gamma_to_linear (tv_range_in=False, tv_range_out=False, curve="srgb")
dither_convert_rgb_to_yuv (r,g,b,matrix="709",lsb=true,output="yv24",tv_range=False)
dither_resize16 (600,300)
dither_convert_yuv_to_rgb (matrix="709",lsb_in=true,output="rgb48y",tv_range=False)
Dither_y_linear_to_gamma (tv_range_in=False, tv_range_out=False, curve="srgb")
round8 (false)
mergergb (selectevery (3,0),selectevery (3,1),selectevery (3,2))
Function Convert8To16 (clip input, bool "tv_range")
{
    tv_range  = Default (tv_range, True)
    iCceil    = (255-128) / (255.5-128) * (65535.5-32768) + 32768
    Yexpr     = "0-0  ;                  255-65535             ;65535-65535          "
    Cexpr     = "0-0.5;0.5-0.5;128-32768;255-"+String(iCceil)+";65535-"+String(iCceil)
    fullrange = StackVertical (input.Dither_gen_null_lsb (), input).
    \           SmoothCurve16 (Ycurve=Yexpr, Ucurve=Cexpr, Vcurve=Cexpr, mode=0, interp=0, HQ=True,
    \                          dither=-1, limiter=False, TVrange=0)
    output    = tv_range ? input.Dither_convert_8_to_16 ()
                \        : fullrange
    return output
}
Function Round8 (clip input, bool "tv_range")
{
    tv_range  = Default (tv_range, True)
    iCceil    = (255-128) / (255.5-128) * (65535.5-32768) + 32768
    Yexpr     = "0-0;                                           65535-255"
    Cexpr     = "0-0.5;0.5-0.5;32768-128;"+String(iCceil)+"-255;65535-255"
    fullrange = input.SmoothCurve16 (Ycurve=Yexpr, Ucurve=Cexpr, Vcurve=Cexpr, mode=0, interp=0, HQ=True,
    \                                dither=-1, limiter=False, TVrange=0)
    output    = tv_range ? input.ditherpost (mode=-1, y=3, u=3, v=3)
                \        : fullrange.Dither_get_lsb ()
    return output
}
colours писал(а):
feisty2 писал(а):
you will need ycbcr to separate intensity and colors to avoid clipping artifacts under linear light, I was thinking about CIE Lab, but Motenai Yoda came up with YCbCr, easier and should do the trick also
False. This produces an effectively identical result. (The lut16 for range conversion is necessary because in Dither_y_gamma_to_linear/Dither_y_linear_to_gamma, "full range" is 0 to 256×256, while in Dither_convert_yuv_to_rgb, the output range is 0 to 255×256.)
Код:
jpegsource("O:\earthlights_big.jpg")
dither_convert_yuv_to_rgb(tv_range=false,cplace="MPEG1",matrix="601",output="rgb48y")
dither_lut16("x 255 / 219 * 4096 +")
dither_y_gamma_to_linear()
dither_resize16(600,300)
dither_y_linear_to_gamma()
dither_lut16("x 4096 - 219 / 255 *")
ditherpost(mode=-1)
mergergb(selectevery(3,0),selectevery(3,1),selectevery(3,2))
What Motenai Yoda suggested would be more like using different resampling kernels for luma and chroma, in which case a conversion to linear-light YCbCr would indeed be pretty much unavoidable, but that's not what your script does.
feisty2 писал(а):
anyways, I made a new sort of gamma aware resizer tryna overcome dark ringings caused by linear light resizing
so, "rose image"
source

gamma ignorant resizing
Код:
r=showred ("y8")
g=showgreen ("y8")
b=showblue ("y8")
gamma=interleave (r,g,b).convert8to16 (false)
gamma.dither_resize16 (210,138)
round8 (false)
mergergb (selectevery (3,0),selectevery (3,1),selectevery (3,2))

gamma aware resizing
Код:
r=showred ("y8")
g=showgreen ("y8")
b=showblue ("y8")
gamma=interleave (r,g,b).convert8to16 (false)
linear=gamma.Dither_y_gamma_to_linear (tv_range_in=False, tv_range_out=False, curve="srgb")
linear.dither_resize16 (210,138)
Dither_y_linear_to_gamma (tv_range_in=False, tv_range_out=False, curve="srgb")
round8 (false)
mergergb (selectevery (3,0),selectevery (3,1),selectevery (3,2))

new fake gamma aware resizing
Код:
r=showred ("y8")
g=showgreen ("y8")
b=showblue ("y8")
gamma=interleave (r,g,b).convert8to16 (false)
linear=gamma.Dither_y_gamma_to_linear (tv_range_in=False, tv_range_out=False, curve="srgb")
gresize=gamma.dither_resize16nr (210,138).Dither_y_gamma_to_linear (tv_range_in=False, tv_range_out=False, curve="srgb")
#resizing under gamma compressed space gets highlight areas into trouble, highlight ringings and lack of brightness, pick dither_resize16NR to get rid of highlight ringings
lresize=linear.dither_resize16 (210,138)
#real gamma aware resizing, works better on highlight areas, less highlight ringings and better brightness, but makes dark halos
brightdif=dither_sub16 (lresize,gresize,dif=true).dither_lut16 ("x 32768 < 32768 x ?")
#find the differences between pixels, keep brighter difs and discard darker difs (halos)
gresize.dither_add16 (brightdif,dif=true)
Dither_y_linear_to_gamma (tv_range_in=False, tv_range_out=False, curve="srgb")
round8 (false)
mergergb (selectevery (3,0),selectevery (3,1),selectevery (3,2))

edit: typo in the code
feisty2 писал(а):
"map image"
source

gamma ignorant

gamma aware

new fake gamma aware

edit: replaced an image due to the code change at #27
[Профиль]  [ЛС] 

Гость


Гость · 30-Мар-14 08:10 (спустя 2 года)

[Цитировать] 

При сравнениях видео разного разрешения по правилам раздела зарубежного кино:
Цитата:
Масштабирование до целевого разрешения должно быть сделано с помощью алгоритма bicubic
...
4.3 Далее, в новой строке консоли пишем:
Код:
bicubicResize(%width%, %height%, 0, 0.6)
Вопрос: почему именно BicubicResize и 0.6 дописываем, а не 0.3 или 0 ? Как повлияет на сранение то, если будем использовать LanczosResize или что-то другое ? Причём , как я понимаю, проверить какой алготитм был использован невозможно.
 

Lenchik

Стаж: 12 лет 4 месяца

Сообщений: 855


Lenchik · 30-Мар-14 09:45 (спустя 1 час 34 мин.)

[Цитировать] 

http://rutracker.org/forum/viewtopic.php?p=62976517#62976517
[Профиль]  [ЛС] 

Гость


Гость · 19-Апр-14 20:02 (спустя 20 дней)

[Цитировать] 

Lenchik
bicubic для имитации декодера плеера, это ладно, но почему параметры 0, 0.6 ? Откуда взяты эти цифры, почему не оставить 0, 0 ?
 

Ювелир

VIP (Заслуженный)

Стаж: 7 лет 11 месяцев

Сообщений: 6510

Ювелир · 20-Апр-14 00:54 (спустя 4 часа)

[Цитировать] 

cl1sc1ple писал(а):
63659175но почему параметры 0, 0.6 ? Откуда взяты эти цифры, почему не оставить 0, 0 ?
Высчитаны путём проб и сравнений. Меньше 0.6 уже мылит, больше - уже шарп.
[Профиль]  [ЛС] 

torg

Стаж: 12 лет 2 месяца

Сообщений: 719


torg · 08-Июн-14 12:58 (спустя 1 месяц 18 дней, ред. 17-Июн-14 01:46)

[Цитировать] 

В xvid4psp 5
Фильтрация - Изменить скрипт фильтрации:
Код:
BicubicResize(704, 400, 0, 0.75)
Всё-таки что лучше 0,6 или 0,75 ? в чём разница между ними ?
[Профиль]  [ЛС] 

Frost O.S

RG Mobile

Стаж: 8 лет 10 месяцев

Сообщений: 2350

Frost O.S · 26-Июл-14 17:05 (спустя 1 месяц 18 дней)

[Цитировать] 

А на руссском про ресайзы где почитать?
[Профиль]  [ЛС] 

Lenchik

Стаж: 12 лет 4 месяца

Сообщений: 855


Lenchik · 26-Июл-14 17:31 (спустя 25 мин.)

[Цитировать] 

Здесь. Искать в разных темах осколки обсуждений. Найдёте что-то интересное - постите сюда ссылки, чтобы не зря время на поиск тратить, а на пользу окружающим.
[Профиль]  [ЛС] 

Frost O.S

RG Mobile

Стаж: 8 лет 10 месяцев

Сообщений: 2350

Frost O.S · 26-Июл-14 18:22 (спустя 50 мин.)

[Цитировать] 

Lenchik
Понятно.
[Профиль]  [ЛС] 

DaVinci.

Стаж: 6 лет 8 месяцев

Сообщений: 412

DaVinci. · 20-Ноя-14 15:34 (спустя 3 месяца 24 дня)

[Цитировать] 

Lenchik писал(а):
52145374Spline144Resize
Скажите пожалуйста, а этот ресайзер можно применять для кодирования в XviD для железного DVD? Спасибо.
[Профиль]  [ЛС] 

Lenchik

Стаж: 12 лет 4 месяца

Сообщений: 855


Lenchik · 20-Ноя-14 19:32 (спустя 3 часа)

[Цитировать] 

можно
С чем связаны сомнения?
[Профиль]  [ЛС] 

DaVinci.

Стаж: 6 лет 8 месяцев

Сообщений: 412

DaVinci. · 20-Ноя-14 21:43 (спустя 2 часа 11 мин., ред. 20-Ноя-14 22:43)

[Цитировать] 

Lenchik писал(а):
65903905С чем связаны сомнения?
Да вот просто на этом форуме говорил Tempter57 что его нет в списке рекомендованных ресайзеров для XviD, и он только для кодирования с кодеком х264, и потому я и спрашивал в этой теме правда ли это, то есть будут ли воспроизводится видео на простом железном DVD!
[Профиль]  [ЛС] 

Lenchik

Стаж: 12 лет 4 месяца

Сообщений: 855


Lenchik · 20-Ноя-14 22:47 (спустя 1 час 3 мин., ред. 20-Ноя-14 22:47)

[Цитировать] 

Если уж так цитировать, то лучше ссылкой на конкретный пост - http://rutracker.org/forum/viewtopic.php?p=65850060#65850060 (берётся из ссылки-даты написания конкретного сообщения)
«Рекомендованные» и «дозволенные» для вас одно и то же?
Рискну предположить, что использование Spline144Resize на большинстве исходников неэффективно в случае дальнейшего кодирования XviD, но использовать можно. Там рядом с тем постом и тесты ещё есть с цифрами квантов.
оффтопик для этой темы
Обычно алгоритм ресайза исходника не сказывается на проигрываниями проигрывателями. Но мне любопытно, откуда такие у вас идеи. Подозреваю кашу в голове. Но вот как сформировались такие комочки и подгорелости?
[Профиль]  [ЛС] 

DaVinci.

Стаж: 6 лет 8 месяцев

Сообщений: 412

DaVinci. · 20-Ноя-14 22:49 (спустя 2 мин.)

[Цитировать] 

Lenchik
Тогда что, лучше вместо него использовать этот Bicubicresize(W, H, 0, 0.5), или этот LanczosResize, или какой в среднем порекомендуете?
[Профиль]  [ЛС] 

xfiles

RG Мультфильмы

Стаж: 11 лет

Сообщений: 43160

xfiles · 20-Ноя-14 22:51 (спустя 2 мин.)

[Цитировать] 

Andrew_26
Всё зависит от личного предпочтения, целей и задач. Алгоритмы описаны, а каким пользоваться каждый выбирает сам.
[Профиль]  [ЛС] 

SuperBayanBabayan

Стаж: 6 лет 7 месяцев

Сообщений: 669

SuperBayanBabayan · 04-Янв-15 01:53 (спустя 1 месяц 13 дней)

[Цитировать] 

Здравствуйте.
У меня возникла такая задача.
Надо сжать двухчасовой полнометражный аниме-мультфильм "Ходячий замок" из блюрей-ремукса на однослойный DVD.
Как посоветуете это осуществить, чтобы качество видео было наилучшее?
[Профиль]  [ЛС] 

Юpист

RG All Films

Стаж: 9 лет 10 месяцев

Сообщений: 2773

Юpист · 29-Апр-16 22:55 (спустя 1 год 3 месяца, ред. 29-Апр-16 22:59)

[Цитировать] 

Lenchik писал(а):
52145374Результаты теста 1 от NcryptoR
Хм, и чё я раньше не постил? Делал подобный тест ещё лет пару пар назад, только на живом видео. Результаты тогда ещё конкретно отличались от теста №1 NcryptoR'a, вот опять решил повторить.
Взял скрин с первого попавшегося 1080p http://rutracker.org/forum/tracker.php?f=313 - http://rutracker.org/forum/viewtopic.php?t=5216340 - http://1.1.1.4/bmi/s018.radikal.ru/i507/1604/88/38ea412e8a70.png - 1024х576
и со второго 1080p http://rutracker.org/forum/viewtopic.php?t=5216118 - http://i78.fastpic.ru/big/2016/0427/15/72b3277d0d6a3c8c02beaadcd5a0b815.png - 1024х576
И вот результат
Цитата:
Размер выходного изображения в байтах в порядке возрастания:
№1 NcryptoR
Spline36Resize
BlackmanResize
LanczosResize -
Spline64Resize
Lanczos4Resize
my1
Spline36Resize
BlackmanResize
Spline64Resize
LanczosResize
Lanczos4Resize
my2
BlackmanResize
Spline36Resize
Spline64Resize
LanczosResize
Lanczos4Resize
my1
my2

зы писал(а):
49926215
[Профиль]  [ЛС] 

Tracker35

Стаж: 10 лет

Сообщений: 741

Tracker35 · 29-Апр-16 23:10 (спустя 15 мин., ред. 29-Апр-16 23:10)

[Цитировать] 

Сравнивать по конечному размеру png - вообще бред тот еще.
Держите два способа
1. Создать цветовую маску из сорса и сравнивать её с конечной после ресайза, на предмет добавления лишних цветов + узнать какие цвета пропали (и их процентное количество используемых пикселей в сорсе - т.е. насколько они были важны)
2. В MSU Video Quality Measurement Tool есть Blurring тест, который умеет определять шарпность/блюрность картинки в цифровом эквиваленте, и если ресайз будет правильным, то эти значения не должны отличаться между собой.
Если есть желание, попробуйте
[Профиль]  [ЛС] 

Юpист

RG All Films

Стаж: 9 лет 10 месяцев

Сообщений: 2773

Юpист · 29-Апр-16 23:54 (спустя 44 мин.)

[Цитировать] 

Tracker35, вес png определяет сжимаемость видеоряда, вот начало пьянки (стр.29), а тест это её следствие (стр.31). Речь о том, что положение меняется.
Цитата:
MSU
Давно у них не был, статью видел, но так дальше заголовка и не дошёл. Спасибо за наВОДКУ! Случайно не в курсе, где можно коммерческие фильтры ... ?
[Профиль]  [ЛС] 

Frost O.S

RG Mobile

Стаж: 8 лет 10 месяцев

Сообщений: 2350

Frost O.S · 13-Авг-16 08:03 (спустя 3 месяца 13 дней, ред. 13-Авг-16 08:03)

[Цитировать] 

Доброе утро! Прочитал следующее .
Цитата:
Tempter57 от 7 ноября 2011 года писал(а):
Выбор определяется качеством самого исходника. Если исходник некачественный с блочностью и звоном, то разумеется необходимо применять, например, BicubicResize. Если вы хотите сохранить повышенную детализацию, выполнить апскейл, чуточку добавить в резкости, то вам поможет это сделать Lacsozresize с taps=4...10 (чем выше значение, тем выше резкость, но больше вероятность появления артефактов в виде звона на контурах). Нейтральными считаются ресайзеры класса SplineResize 16...36, а вот SplineResize 64,100,144 уже могут несколько увеличить детализацию и резкость за счёт увеличения количества опорных точек, применяемых в ресайзере. Обычно последние применяются в аниме и использование их для фильмов никакого практического значения не имеет.
Сейчас при создании BDRip с качественных исходников модно применять BlackmanResize(x,y,taps=4).
ResampleHQ.dll это не совсем ресайзер, автор сам его называет фильтром. Вы можете задать любой ресайзер внутри из перечня в документации. В том скрипте, я как раз и задал именно BlackmanResize(x,y,taps=4):
ResampleHQ(1280, 720, srcmatrix="PC.709", dstmatrix="PC.709", kernel="Blackman", karg1=4, dither=true). Кстати, внутри ResampleHQ можно задать параметры кропа.
Этот плагин прежде всего интересен поддержкой технологии Dither, в нём можно также выполнить конвертацию цветового пространства YV12 в YUY2 и обратно, а также применять различные матрицы коэффициентов цветопередачи, можно сужать и растягивать диапазон, регулируя level . Этот плагин немного вытягивает изображение из тени, придавая некоторую контрастность изображения и визульно это немного похоже на улучшение детализации изображения. Более подробное пояснение вы можете получить на этой ветке http://forum.doom9.org/showthread.php?t=160038&highlight=ResampleHQ, непосредственно задав вопрос автору данного плагина. Не случайно ResampleHQ вошёл в перечень Avisynth 64-bit usage FAQ.
При кодировнии в h264 кодек, нужно ли выставлять значения для остальный типов ресайза SplineResize 16...36 / SplineResize 64,100,144 на разных исходниках; как написано taps=4 как для ресайз-фильтра BlackmanResize? Для BDRip BlackmanResize(x,y,taps=4), а для остальных DVDRip, HDTVRip, Web-DLRip? Если да то какие?
[Профиль]  [ЛС] 

Tracker35

Стаж: 10 лет

Сообщений: 741

Tracker35 · 11-Апр-17 03:36 (спустя 7 месяцев, ред. 11-Апр-17 16:08)

[Цитировать] 

Небольшой тест двух ресайзеров-даунскейлов:
1. Исходник (1920,1080)
http://101.imagebam.com/download/ebKa3JeY46j7qFg-Y9VQjA/54280/542796192/1.png
2. Spline64Resize(1280,720)
Spline64Resize(1920,1080)
http://101.imagebam.com/download/Mun1M702b2aN1VVU3lD5Mw/54280/542796242/2.png
3. ResizeShader(1280,720,"SSim")
Spline64Resize(1920,1080)
http://101.imagebam.com/download/Ye_I-rDFiWs146WPnczCcw/54280/542796314/3.png
SSIM:
Spline64Resize - 0,82991
ResizeShader-SSim - 0,83709
MSU Blurring:
Source - 39,55876 (если больше - шарп, если меньше - блюр)
Spline64Resize - 36,06100
ResizeShader - 38,65377
Из замеченых ньюансов, если у сорса имеются сильные пиксельные шумы, то ResizeShader-SSim с обратным апскейлом сделает их, уже не пиксельными т.е. как вариант, перед ресайзом пройтись легким шумодавом.
Но в основном, на ResizeShader-SSim картинка выглядит как после качественного деинтерлейса, средняя детализация почти не измена, когда как после Spline64 она слегка размыта.
[Профиль]  [ЛС] 
 
Ответить
Loading...
Error