SmoothAdjust [v3.20 - Update 2015/11/15]

[LaTo]

oh OK, always only heard ICL :o

did you compare all the different options in ICL? Apparently there's a dozen way to compile stuff in ICL11 and some are faster than others depending on what code it's been optimized for.

when feeding 1272*686, I get: http://www.pixelz.fr/b/6/f/44448ed24e7602dfa02e205b0d0d2.png

if I use mmod(4,4) (http://forum.doom9.org/showpost.php?p=1453641&postcount=22), then it's padded to 1272*688 and it works fine. Maybe you could add an option to do the same internally? It'd be convenient for realtime use.

indeed, it seems a lot less laggy when seeking using SetMTMode(2,4) http://forum.slysoft.com/images/smilies/agreed.gif

I will add auto-mod4 later ;)

[Dogway]

Avisynth crashes with smoothlevels and smoothtweak

PD: smoothcurve too, always when a change (smoothlevels(0,1.0,255,0,255) OK)

[leeperry]

I will add auto-mod4 later ;)
ok, cool! I get 370fps w/ the ICC11 build on 4 threads/Q9450, 350fps w/ the MSVC and 280fps w/ 1.56..nice speed boost!

it's still a bit slow to open when using SetMode(2,4) but it's a far cry from 1.56...this one was taking forever :scared:

[LaTo]

Avisynth crashes with smoothlevels and smoothtweak

PD: smoothcurve too, always when a change (smoothlevels(0,1.0,255,0,255) OK)
With which build? MSVC or ICL? x86 or x64?
Crash at startup? or later?
Is it working with useopt=false? with a older version?
What is your entire script? the clip's resolution?

Thanks!

[Dogway]

useopt=false solved it.
Why is it? I have SSE2/SSSE3.

Do you recommend me ICC over MSVC for quality?

I run 2.5.7 MT WinXP SP3 Core2Duo T9400, and I tested the plugin with plugin folder empty to discard possible incompatibilities.

[LaTo]

useopt=false solved it.
Why is it? I have SSE2/SSSE3.

Do you recommend me ICC over MSVC for quality?

I run 2.5.7 MT WinXP SP3 Core2Duo T9400, and I tested the plugin with plugin folder empty to discard possible incompatibilities.
ICC & MSVC are the same for quality, it's only a speed difference. Pick the fastest for you.

Can you provide your entire script and a video sample please?
And have you tested with the official avisynth v2.5.8?

[Dogway]

ImageReader("Boulevard_du_Temple (Paris 1838).jpg")
bicubicresize(860,620)
converttoyv12
smoothlevels(0,1.1,255,0,255)

nothing fancy, Im testing with that photo taken from wikipedia.

I mainly use 2.5.7 because it has the widest compatibility. But I just tested rapidly with 2.5.8 MT and also crashed.
I smell Im lacking some important libraries as Im also having difficulties with importuncompressedfile.dll

[LaTo]

OK I can reproduce the crash, strange... I will investigate, thanks!

edit: fixed in v1.62

[LaTo]

v1.62:
fixed crash with misaligned clip
added MOD2 support

:cool:

[leeperry]

added MOD2 support
http://forum-images.hardware.fr/images/perso/cytrouille.gif

[TheSkiller]

SmoothAdjust is great! But there's something I'm missing ever since I started using it: YUY2 support.
Do you consider adding YUY2 support anytime? :cool:

[LaTo]

SmoothAdjust is great! But there's something I'm missing ever since I started using it: YUY2 support.
Do you consider adding YUY2 support anytime? :cool:

Yes I know, this will be fixed with avisynth v2.6.0 because it supports YV16 (which is exactly the same as YUY2 but planar).

The code is ready, I am just waiting after the release of avs 2.6.0 :D

[Dogway]

@LaTo: I dont know but contrast here doesnt work as expected, like in sgradation,photoshop,etc. You know, the S curve. And thanks for the update, it works great now!

[LaTo]

@LaTo: I dont know but contrast here doesnt work as expected, like in sgradation,photoshop,etc. You know, the S curve. And thanks for the update, it works great now!

Contrast in SmoothTweak is the same as in avisynth's Tweak().

If you want to apply a "S curve" simply use SmoothCurve:

contrast=16 # [0 to 64]

SmoothCurve(Ycurve="0-0;64-"+string(64-contrast)+";128-128;192-"+string(192+contrast)+";255-255")

[Dogway]

Thats what I meant, when it comes to a simple "contrast" it renders in a complex syntax, when the very purpose of the filter is to be made easy, no? Just my opinion.

[Didée]

Well, S-curve contrast adjustment basically is "freestyle" / "arbitrary", and therefore it is not "simple". In PotoShop et.al. you have a GUI to draw controlpoints etc., whereas Avisynth filters usually don't have a GUI. So you have to specify control points by typing numbers. What do you expect - reckognition of mouse gestures? :D

(And SmoothCurve's syntax is really not difficult ... rather "as simple as it can only get".)

[Dogway]

Hi Didée : D
I just named "the S curve" to specify the type of contrast. Not the method, in fact when I refer to Photoshop's contrast I talk about the brightness/contrast slider, but the effect is the same. And SGradation is as simple as a float number : /

[Didée]

Yeah. But then, Photoshopulus pompous has about ten thousand different filters to make your life easy. The hard part is to find the right filter. :D

To me, syntax of SmoothAdjust is just fine. "in1-out1, in2-out2, in3-out3, .." - simple enough to get grip, yet versatile enough to be adopted to the actual requirements. Really, I couldn't think of a better compromise.

Of course, if you prefer Photopompous ... use it! :p

[Dogway]

no Didée I prefer SGradation, :P
I know you can do all the operations writing directly masktools functions... but for the rest of people why dont to make it easier (dumb if you want), as a matter of fact what does smoothtweak's contrast actually does? smoothlevels(x,1.0,x,0,255)?

[Didée]

"it must be like in Photoshop!"
- "no! it must be like in Gimp!"
--- "no! it must be like in CorelDraw!"
- - - "no! it must be like in Paint Shop!"
- - - - "no! it must be like in Photo Line!"

No. it must be like in SmoothAdjust/Curve. This is fine.

BTW, I didn't even mention masktools.

[Dogway]

There's a reason on why a broad number of applications agree on what contrast is, Im not complaining, Im giving my opinion (to dumb the contrast setting down), given. And asking how is working as for now (range clipping)?

[Didée]

Tweak does the equivalent of "levels(0,1.0,255, 0,x)".

We don't need to start it all over (http://forum.doom9.org/showthread.php?p=1379275#post1379275), do we? :eek:

[Dogway]

nono, just answered my question, thank you (no pun)

[LaTo]

Thats what I meant, when it comes to a simple "contrast" it renders in a complex syntax, when the very purpose of the filter is to be made easy, no? Just my opinion.

You can make a little function with an avsi stored in your plugin's folder:

function SmoothContrast(clip clip, float "contrast")
{
contrast = default(contrast, 0.0) # [-1.0 to +1.0]

return clip.SmoothCurve(Ycurve="0-0;64-"+string(64-64*contrast)+";128-128;192-"+string(192+64*contrast)+";255-255")
}


And use it like this: SmoothContrast(1.0)

[LaTo]

v1.64:
fixed cache problem with UV planes

[LaTo]

v1.68:
improved multithreading

[LaTo]

v1.70:
added curve in debug mode for SmoothLevels

http://latoninf.free.fr/d9/SA/SLshow_mini.png (http://latoninf.free.fr/d9/SA/SLshow.png)
*Click the image to enlarge*

[lych_necross]

Just out of curiosity, what settings did you use for the screenshot?

[LaTo]

Just out of curiosity, what settings did you use for the screenshot?

All the settings are on the screenshot... :confused:

[lych_necross]

omg, I can't believe I missed them... :o I feel like an idiot now

[LaTo]

omg, I can't believe I missed them... :o I feel like an idiot now

If you want this debug output, simply use SmoothCurve(show=true) / SmoothLevels(show=true)

;)

[Dogway]

@LaTo: Just wanted to say thanks because your contrast little script was useful in my last source. It was indeed "smoother" than sgradation. Its ok for a few things, but Im unsure smoothlevels + smoothcontrast preserves more data than toRGB-Gicocu-toyv12? I would need to redraw my workflow...

[LaTo]

@LaTo: Just wanted to say thanks because your contrast little script was useful in my last source. It was indeed "smoother" than sgradation. Its ok for a few things, but Im unsure smoothlevels + smoothcontrast preserves more data than toRGB-Gicocu-toyv12? I would need to redraw my workflow...

I don't know, but SmoothAdjust doesn't need/do RGB->YUV conversion.
On top of that, all calculations are made in 32bits and are dithered at the end to 8bits.
It can't be better ;)

[LaTo]

v1.74:
updated preset="tv2pc" & preset="pc2tv"
fixed a bug in smoothing algorithm

:)

[lych_necross]

Thanks for the update LaTo! :D

[leeperry]

Yep, thanks for the 1.74 update!

For those that are curious, the TV>PC and PC>TV presets now fully abide by the REC.601/709 decoding matrixes...you get the same colors as madVR. ColorYUV is slightly off in comparison :devil:

And even in realtime w/ Smode=0, the additional dithering does a great job at smoothing the gradients :cool:

[Dogway]

@LaTo: Im trying to use SmoothCurves now, is there a way to clamp values? Say I want all the values below 2 to be 0, or all the values above 250 to be 255, normally I'd do "2-0;235-255" but it throws me a syntax error. One way would be to stack smoothlevels+smoothcurves but it would overlap dithering and it's just not as beautiful. Is it something hard to implement?

[Gavino]

normally I'd do "2-0;235-255" but it throws me a syntax error.
Try "0-0;2-0;235-255;255-255"

[Dogway]

Nice one, thanky!

[seojuhyun]

what is ICC and MSVC.. :confused:

[lych_necross]

what is ICC and MSVC.. :confused:
ICC and MSVC refer to the different compilers that were used to build SmoothAdjust. ICC is the Intel Compiler while MSVC is the Microsoft Visual Studio Compiler. You can use either the ICC or the MSVC version but not both. ICC builds tend to preform a little faster than MSVC builds; however, the performance difference is minimal (about 10% or less). MSVC builds, in my experience, tend to me slightly more stable (but again your mileage will vary). When in doubt, use the MSVC builds.

[seojuhyun]

ICC and MSVC refer to the different compilers that were used to build SmoothAdjust. ICC is the Intel Compiler while MSVC is the Microsoft Visual Studio Compiler. You can use either the ICC or the MSVC version but not both. ICC builds tend to preform a little faster than MSVC builds; however, the performance difference is minimal (about 10% or less). MSVC builds, in my experience, tend to me slightly more stable (but again your mileage will vary). When in doubt, use the MSVC builds.

ahah, okay, nice guide :) :thanks:

[Alex_ander]

Thank you for the filters.
I started using SmoothTweak() but as an AVSP user, found one thing missing. Usually, all functions including those belonging to the loaded external filters, are highlighted bold in AVSP (this confirms they were found) and they show floating tips while typing parameters. For each used numerical parameter a graphic slider is automatically created. All that doesn't happen with SmoothTweak(), unlike with Tweak() etc. As I can guess, some metadata must be present in .dll. Is it possible to provide it for the described functionality? Thanks.

[Gavino]

Alex_ander, as SmoothAdjust is relatively recent, AvsP has no built-in knowledge of it. However, if the plugin is in Avisynth's plugins folder (and hence loaded automatically), AvsP will find the information it requires (parameter names and types) to give you the floating tooltips. It cannot give sliders as it does not know the parameter defaults or their possible ranges.

You can add the required information for the sliders yourself under Options->Avisynth function definition->Plugins.

[Gavino]

ICC and MSVC refer to the different compilers that were used to build SmoothAdjust. ICC is the Intel Compiler while MSVC is the Microsoft Visual Studio Compiler. You can use either the ICC or the MSVC version but not both. ICC builds tend to preform a little faster than MSVC builds; however, the performance difference is minimal (about 10% or less). MSVC builds, in my experience, tend to me slightly more stable (but again your mileage will vary). When in doubt, use the MSVC builds.
Another difference I discovered recently is that (since LaTo switched to the VC++ 2010 compiler) the MSVC build will not run on older OS versions such as Windows 2000 or XP SP1.

[Alex_ander]

Thanks, Gavino. I had suspected that there could be difference with different ways of loading plugin, but only tested this with older plugins which I usually load in script. Then I'll put this dll into 'plugins', it is definitely worth to be always loaded :) .

[Dogway]

I find myself tweaking smoothcurves u an v plane for hours... trying to match a more intuitive curved rgb version. Is there any tool where I can translate rgb curves to yuv curves? Its really very hard to get the grasp of it.

[Didée]

Is there any tool where I can translate rgb curves to yuv curves?
Nope. You can't just go ahead and translate such a curve from RGB to YUV or viceversa. It's kinda impossible, since those colorspaces are too different. (It would require that the U/V curves are made cross-dependent AND luma-dependent, per pixel. But we have only independent channel-adjustment in Avisynth.)

I find myself tweaking smoothcurves u an v plane for hours... trying to match a more intuitive curved rgb version.
Lesson learned: YUV colorspace usually is not well suited to perform "extensive" color corrections.


ConvertToRGB

R = ShowRed(pixel_type="YV12") .SmoothCurves
G = ShowGreen(pixel_type="YV12") .SmoothCurves
B = ShowBlue(pixel_type="YV12") .SmoothCurves

MergeRGB(R,G,B)
ConvertToYv12()
That's all i can think of ATM.

[Dogway]

I don't expect a 1:1 curve conversion, but something that resembles the rgb counterpart or just maybe an external tool where I can fiddle yuv curve points until I know what Im doing.
Thanks for the workaround, it can benefit still from the dither part of the filter as opposed to gicocu. You use only the ycurve then, right?

[Yellow_]

Lesson learned: YUV colorspace usually is not well suited to perform "extensive" color corrections.


Could I just pick up on this point and ask, with regard to NLE's / video processing where it's generally understood many apps 'transform' the YCC to RGB internally for effects, compositing etc, is that RGB data for all intents and purposes identical to an image written out as say a raw image file with no compression? Or are there further operations done in the chain to get the image, like interpolation for example apart from writing it out to file :-)?

It's something I not quite understand, quite a few workflows that are seen involve conversion of video to image sequences or uncompressed RGB .avis for editing and effects.

My query really relates to the open source offerings where there is no real suitable NLE / Compositing App that does everything 'right' and work arounds are made.

For example no 32bit precision ops on YCC sources whether that be native YCC or a decent internal conversion to RGB by the NLE, they generally rely on FFMPEGs SWScale functions which appear are less than ideal.

In other words in the absence of decent data handling for conversion are there any real downsides to just converting to uncompressed RGB image sequences or avi's to edit and grade with apart from playback speed ie proxy workflow needed generally. For the 'smaller' amount of ops better done in YCC space a tranformation the other way internally.

RAW image editing apps like Rawtherapee or RawStudio offer batch operations and 32bit handling you see, but only for image sources.