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

[ChaosKing]

I just tried your beta, but it still crashes with: SmoothLevels(gamma=2.22)
and now
SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=-1)
crashes too.

[LaTo]

I just tried your beta, but it still crashes with: SmoothLevels(gamma=2.22)
and now
SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=-1)
crashes too.
^I've tried the beta2, it still giving me error
(gamma=1.1,Lmode=2,protect=16,useMT=0,useOPT=2) beta2 <-- error
(gamma=1.1,Lmode=2,protect=16,useMT=4,useOPT=2) beta2 <-- crash
@ChaosKing & @ninja_racoon: Here is a new fixed version (I hope :D): > SmoothAdjust-FIX.dll < (http://latoninf.free.fr/d9/SA/SmoothAdjust-FIX.dll)
(It's a bit hard to debug without the target CPU)


One final thought, I know you are quite busy working on 2.0beta, Any chance of a
Ecurve = Ylevelss type only if it is not too time consuming in the future. :thanks:
@Ponder: YlevelsS is the same as SmoothLevels(Lmode=2,Ecurve=0)


fair enough :)

but:
[...]
=400fps

[...]
=120fps :o

that's on an o/c Q9650, XPSP3, Avisynth 2.6
@leeperry: Try the fixed version in this post, it should be much faster when smooth=0.

[Ponder]

@Lato
Yes, they are from same sine family, but parameter must be very different, since I can't get
the contrast similar to YlevelsS, I don't want to use tweak to get contrast after SMOOTHLEVELS,
it slows thing down and risk polarizing. Can we have a third Ecurve mode where one can define
their own whacky function?

[leeperry]

@leeperry: Try the fixed version in this post, it should be much faster when smooth=0.
AMAZING, I get +700fps now :eek:

now to try it w/ movies, thank you so much for the quick fix :)

PS: I've A/B'ed the old and new versions around 50 times on many samples...the new one looks noticeably clearer and sharper when doing TV>PC, you've come a long way since the first script version..major kudos to you!

[ninja_racoon]

Does it really prevents banding with smooth=50 and dither=50 settings when I encode using x264?


@ChaosKing & @ninja_racoon: Here is a new fixed version (I hope ): > SmoothAdjust-FIX.dll <
(It's a bit hard to debug without the target CPU)
it still crashes for me.

(gamma=1.1,Lmode=2,protect=16,useMT=0,useOPT=2) <-- error
(gamma=1.1,Lmode=2,protect=16,useMT=4,useOPT=2) <-- crash

[LaTo]

v2.00 beta2:
tweaked smoothing algorithm
fixed crash with mod4 clip
fixed freeze in debug view
tweaked speed when smooth=0

Todo-list:
- finish higher bitdepth support
- repair AVX code
- fix all bugs reported
Download here: > SmoothAdjust v2.00 beta2 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta2.zip)

:)

[LaTo]

@ChaosKing & @ninja_racoon: About the crash/error with AVX stuff, please check the 6 dlls in this package: > AVX_debug.zip < (http://latoninf.free.fr/d9/SA/AVX_debug.zip)

Could you test them with SmoothLevels(gamma=2.0) and with SmoothTweak(contrast=2.0)?
Then see which ones work and report here.

Thanks for all!

[ChaosKing]

Only SmoothAdjust.6.dll is working. 1-5 = big crash

[LaTo]

Only SmoothAdjust.6.dll is working. 1-5 = big crash

Great, I think I got it :devil:

[LaTo]

v2.00 beta3:
fixed misaligned clip in AVX
finished 16bits support (stacked MSB/LSB)

Todo-list:
- check avisynth 2.6.x support (any inputs?)
- fix all bugs
Download here: > SmoothAdjust v2.00 beta3 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta3.zip)

:)

[markanini]

Tell us more about the tweaked smoothing algorithm

[ninja_racoon]

Only SmoothAdjust.6.dll is working. 1-5 = big crash
Yes, no.6 is working :)

[LaTo]

Yes, no.6 is working :)
beta3 should work too, right?

[ninja_racoon]

Download here: > SmoothAdjust v2.00 beta3
Thanks! :)

[mandarinka]

The 16bit hack is a nice idea, imho, getting hig bitdepth working without core changes.
Avisynth itself moves slowly and filters would need rewriting for a new colorspace anyway.
Now if only somebody wrote an import filter for x264cli :)

[cretindesalpes]

Now if only somebody wrote an import filter for x264cli :)
# "last" is a stacked MSB/LSB 16-bit clip

Interleave (Dither_get_lsb (), Dither_get_msb ())
TurnRight ()
AssumeFieldBased ().AssumeTFF ()
Weave ()
TurnLeft ()

# Ready to be encoded with:
#
# avs2yuv -raw "script.avs" -o - | x264-10bit --demuxer raw --input-depth 16 --input-res 1280x720 --fps 24 --output "blah.mp4" -
#
# Set --input-res and --fps according to your video settings.

[LaTo]

v2.00 beta4:
fixed YV16 & YV24 support
added Y8 & YV411 support

Todo-list:
- fix all bugs
Download here: > SmoothAdjust v2.00 beta4 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta4.zip)



Now you can process YUY2 clip without quality loss in Avisynth 2.6.x:

ConvertToYV16() #Lossless
SmoothAdjust(...)
ConvertToYUY2() #Lossless

My todo list is empty, so if you have any feature request...

[cretindesalpes]

My todo list is empty, so if you have any feature request...

Previously...

Looks like a great plugin! Would you be willing to release it as open source?

Maybe I don't know, but before I need to complete my todo-list ;)

:devil:

[Dogway]

I was going to test the 16bit version, I think it could be more convenient if you could remap the values internally(?)
I also think you could add an option for when dealing with TVrange sources, specially in smoothlevels and tweak where you have no way.
more room when show=true for settings

[LaTo]

Previously...

[...]

:devil:

Good pick... Maybe with the 2.0final :p


I was going to test the 16bit version, I think it could be more convenient if you could remap the values internally(?)
You only need to multiply value by 256.
If I remap the value internally, it avoids fine adjustments.

I also think you could add an option for when dealing with TVrange sources, specially in smoothlevels and tweak where you have no way.
In SmoothLevels you only need to set output_low/output_high at 16/235 (or 4096/60160 in 16bits).
In SmoothTweak TVrange/PCrange doesn't change the processing (you can set "limiter=true" in TVrange).

more room when show=true for settings
:confused:

[Dogway]

You only need to multiply value by 256.
If I remap the value internally, it avoids fine adjustments.
I never worked with such numbers in 32bit applications, this next line is far from intuitive.
"0-4096;8704-4096;10496-8192;15616-17664;31744-31744;47872-46080;53760-53760;58880-64512;65280-60160",\
For fine adjustments we have always used decimals...
In SmoothLevels you only need to set output_low/output_high at 16/235 (or 4096/60160 in 16bits).
I see, I never use smoothlevels or smoothtweak but I thought about helping. Output_low/output_high at 16/235 is the same as clamping, and I recently read that many TVrange sources have below 16 or above 235 values which should be better leave alone.
In SmoothTweak TVrange/PCrange doesn't change the processing (you can set "limiter=true" in TVrange).
"limiter=true" readme says: Clamp the output to 16-235...
But I dont want to output/clamp TV range values,but instead work in TV range
For example, see this analogy by using smoothcurve
saturation in PC range:
"0-0;64-"+string(64-64*sat)+";128-128;192-"+string(192+64*sat)+";255-255"
saturation in TV range:
"0-16;16-16;74-"+string(74-55*sat)+";127-127;185-"+string(185+55*sat)+";240-240;255-240"
...or I am totally wrong.
:confused:
http://i212.photobucket.com/albums/cc35/Dogway/Misc/Untitled-2.png

[LaTo]

I never worked with such numbers in 32bit applications, this next line is far from intuitive.
"0-4096;8704-4096;10496-8192;15616-17664;31744-31744;47872-46080;53760-53760;58880-64512;65280-60160",\
For fine adjustments we have always used decimals...
No, 16bits values is the only way to go for precision. (SmoothAdjust works in 32bits internally, 16bits is just the input clip)

Example: "Invert" the 16 bits clip
SmoothCurve16("0-65535;65535-0") #Easy
SmoothCurve16("0.0-255,99609375;255,99609375-0.0") #Your proposition with decimals (65535/256 = 255,99609375)
SmoothCurve16("0-255;255-0") #Internal remap: the conversion is wrong (255*256->65280 != 65535)




I see, I never use smoothlevels or smoothtweak but I thought about helping. Output_low/output_high at 16/235 is the same as clamping, and I recently read that many TVrange sources have below 16 or above 235 values which should be better leave alone.
It's not the same as clamping (with limiter=0).



"limiter=true" readme says: Clamp the output to 16-235...
But I dont want to output/clamp TV range values,but instead work in TV range
For example, see this analogy by using smoothcurve
saturation in PC range:
"0-0;64-"+string(64-64*sat)+";128-128;192-"+string(192+64*sat)+";255-255"
saturation in TV range:
"0-16;16-16;74-"+string(74-55*sat)+";127-127;185-"+string(185+55*sat)+";240-240;255-240"
...or I am totally wrong.
Your 2nd script clamp output to TVrange :p (should be "0-0;16-16;...;240-240;255-255")
Also I doesn't understand why you want to leave theses parts "as-is".
If you do that, you will have strange things later.

Example: "Desaturate" a clip
SmoothCurve(UVcurve="0-128;255-128") #In "PCrange", all colors are gone
SmoothCurve(UVcurve="0-0;16-16;17-128;239-128;240-240;255-255") #In "TVrange", extreme colors are still here



http://i212.photobucket.com/albums/cc35/Dogway/Misc/Untitled-2.png
I will try to improve a bit the view ;)

[ChaosKing]

beta4 AVX test
--------------------

#smoothlevels(gamma=2.0, useOPT=0) # 159 fps
#smoothlevels(gamma=2.0, useOPT=1) # 217 fps
#smoothlevels(gamma=2.0, useOPT=2) # 92 fps

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 66 fps
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 140 fps
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 33 fps

The AVX part still does not seem to work properly :/

[Dogway]

No, 16bits values is the only way to go for precision.
I dont know how other applications deal internally with it, and I can't tell you how but Im pretty sure is possible, that's why I tried to fill a bit your empty todo list. Its unintuitive as hell, thats all.

If you do that, you will have strange things later.
In effect I was totally wrong yey!
Some tests a few months ago I remember I could desaturate with no problems, but it makes sense that out of TVrange bounds colors follow a correlation with the curve

Your 2nd script clamp output to TVrange :p (should be "0-0;16-16;...;240-240;255-255")
Then I guess this example (http://forum.doom9.org/showthread.php?p=1503323#post1503323) wasn't correct at all
What I expect is a curve behaviour inside the TVRange in the same fashion as PCrange, but leaving the out of bounds values practically untouched. That's why my confusion on whether "0-0;16-16... or "0-16;16-16... because the first seems to be more locked on the extremes by the knobs (thus modifying the curve weight) than PCrange curve. While it being at first glance the ideal approach I can't tell behaviour is the same, Im not mathematician.

It's not the same as clamping (with limiter=0).
Then maybe is contradictory. Because "Output_low/output_high at 16/235" in levels is not "0-0;16-16;...;235-235;255-255". Maybe you wanted to say "16,1.0,235,16,235" but this flats values in the range 0-16 to a value of 16. There is no way in levels to do "proper" TVrange like you said in curves "0-0;16-16;...;235-235;255-255" (assuming this is the correct way which I discussed in the previous paragraph.)

edit: I think interp=100 doesn't work, using beta4

[mandarinka]

Hmm, I don't know if I am doing something wrong, here...

I wanted to replicate the effect of tweak(hue=+5) using smoothtweak. After some confusion, I realized that smoothtweak's hue1 and hue2 in fact seem to do the same thing as coloryuv's off_u and off_v, respectively.

(Acording to my very limited understanding, the hue parameter as used by tweak kind of rotates the color spectrum around the center/white/black/grey (or something like that, excuse me please), and strangely enough, a dvd I am trying to color-adjust for some strange reason seem to respond well to this kind of shifting...)

1) Is my observation correct? if it is so, mybe the parameters could use some additional explanation in readme...
2) Is there a way to do the adjustment tweak does for hue with smoothadjust, with its superior precission?

[LaTo]

Hmm, I don't know if I am doing something wrong, here...

I wanted to replicate the effect of tweak(hue=+5) using smoothtweak. After some confusion, I realized that smoothtweak's hue1 and hue2 in fact seem to do the same thing as coloryuv's off_u and off_v, respectively.

(Acording to my very limited understanding, the hue parameter as used by tweak kind of rotates the color spectrum around the center/white/black/grey (or something like that, excuse me please), and strangely enough, a dvd I am trying to color-adjust for some strange reason seem to respond well to this kind of shifting...)

1) Is my observation correct? if it is so, mybe the parameters could use some additional explanation in readme...
2) Is there a way to do the adjustment tweak does for hue with smoothadjust, with its superior precission?
1. Correct
2. No sorry


edit: I think interp=100 doesn't work, using beta4
Yes, just a bad scaling... 50 is in fact 100, so higher than 50 produces strange result :D (fixed in the next beta)


beta4 AVX test
--------------------

#smoothlevels(gamma=2.0, useOPT=0) # 159 fps
#smoothlevels(gamma=2.0, useOPT=1) # 217 fps
#smoothlevels(gamma=2.0, useOPT=2) # 92 fps

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 66 fps
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 140 fps
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 33 fps

The AVX part still does not seem to work properly :/
Very very strange, I don't understand. The results was with the MSVC or the ICL build?

Can you try the 2 dlls in this package > SmoothAdjust.AVXtest.zip < (http://latoninf.free.fr/d9/SA/SmoothAdjust.AVXtest.zip) and report FPS here (with useMT=0)?

Thanks!

[Dogway]

@LaTo: I was doing some tests and investigations using vectorscope for accuracy. Indeed SmoothLevels can work with TVrange like this "SmoothLevels(16,1.0,235,16,235..." but by doing so you cant avoid out of 16 and 235 values to not be flatten. This procedure overrides limiter=0. I can post samples but dont want to make the post too bulky.

I also noticed that there is no way you can match smoothcurve and smoothlevels in a simple gamma tweak, I get different curves, and results. So I think you are using another valid approach Im not aware of or something is missing.
SmoothCurve(Ycurve="0-0;128-136.3;255-255",smooth=0,dither=0,interp=50,show=true)
!=
SmoothLevels(0,1.1,255,0,255,smooth=0,show=true,dither=0,limiter=0)
About the 16bit input numbers, could this be possible? Fit (0-65535)/256 range values into 0-255. I dont know how range mapping is done in programming so Im probably talking too much.
Also is it broken decimals input in beta4?

[LaTo]

@LaTo: I was doing some tests and investigations using vectorscope for accuracy. Indeed SmoothLevels can work with TVrange like this "SmoothLevels(16,1.0,235,16,235..." but by doing so you cant avoid out of 16 and 235 values to not be flatten. This procedure overrides limiter=0. I can post samples but dont want to make the post too bulky.
Sorry, clamping is a bug. Fixed in the next beta.


I also noticed that there is no way you can match smoothcurve and smoothlevels in a simple gamma tweak, I get different curves, and results. So I think you are using another valid approach Im not aware of or something is missing.
SmoothCurve(Ycurve="0-0;128-136.3;255-255",smooth=0,dither=0,interp=50,show=true)
!=
SmoothLevels(0,1.1,255,0,255,smooth=0,show=true,dither=0,limiter=0)
Yes, it's normal... You need to set more control points because the interpolation doesn't follow a power curve.


About the 16bit input numbers, could this be possible? Fit (0-65535)/256 range values into 0-255. I dont know how range mapping is done in programming so Im probably talking too much.
Also is it broken decimals input in beta4?
Not broken, input points are integer from the beginning. Decimals added in next beta.

[Dogway]

You are right, I get the same identical results as of levels with "mt_lut(yexpr="x 255 / 1 1.1 / ^ 255 * ",Y=3,U=2,V=2)" then what is the "correct" gamma for smoothcurves? Is there an interp value to conform the power curve?

[LaTo]

You are right, I get the same identical results as of levels with "mt_lut(yexpr="x 255 / 1 1.1 / ^ 255 * ",Y=3,U=2,V=2)" then what is the "correct" gamma for smoothcurves? Is there an interp value to conform the power curve?
No, the only solution is to add more control points to approximate the gamma curve.

[Ponder]

@Lato
I do get back a lot more contrast on Lmode1 when using very conservative setting on BrightSTR.
Varying DarkSTR is quite safe on the other hand.

Q1. If I use gamma=1, will smoothing be turn off. Q2.If set Smode=1, will it be on at all time?
At certain situation, I want it to be on at all time with gamma=1.

Q3. Same behavior between v1.74 and v2?

[LaTo]

v2.00 beta5:
tweaked AVX support
fixed clamping bug in SmoothLevels
fixed interp scaling in SmoothCurve
added decimals support in SmoothCurve

Todo-list:
- fix AVX performance?!?
- improve debug view
- add SmoothCustom
- fix all bugs
Download here: > SmoothAdjust v2.00 beta5 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta5.zip)

:devil:

[LaTo]

@Lato
I do get back a lot more contrast on Lmode1 when using very conservative setting on BrightSTR.
Varying DarkSTR is quite safe on the other hand.

Q1. If I use gamma=1, will smoothing be turn off. Q2.If set Smode=1, will it be on at all time?
At certain situation, I want it to be on at all time with gamma=1.

Q3. Same behavior between v1.74 and v2?

Q1: No
Q2: Smode=0 -> always OFF // Smode=1/2 -> always ON
Q3: Yes but Smode is removed ( smooth>0 -> always ON // smooth=0 -> always OFF )




Here is a fast comparison of v1.74 & v2.xx with strength/smooth=100 (very strong):

Source image (http://latoninf.free.fr/d9/SA/compare/SRC.png)
Smoothing OFF (http://latoninf.free.fr/d9/SA/compare/OFF.png)
v1.74 (Smode=2) (http://latoninf.free.fr/d9/SA/compare/OLD.png)
v2.00beta5 (http://latoninf.free.fr/d9/SA/compare/NEW.png) (More effective, more details & sharpness, no artifact...)

SmoothCurve(Ycurve="0-16;16-16;64-128;128-224;235-235;255-235",Ucurve="0-0;64-192;128-128;192-64;255-255",Vcurve="0-255;64-64;128-128;192-192;255-0")

[leeperry]

Here is a fast comparison of v1.74 & v2.xx with strength/smooth=100 (very strong):

Source image (http://latoninf.free.fr/d9/SA/compare/SRC.png)
Smoothing OFF (http://latoninf.free.fr/d9/SA/compare/OFF.png)
v1.74 (Smode=2) (http://latoninf.free.fr/d9/SA/compare/OLD.png)
v2.00beta5 (http://latoninf.free.fr/d9/SA/compare/NEW.png) (More effective, more details & sharpness, no artifact...)
very impressive. :thanks: for the new build, much appreciated http://forum.slysoft.com/images/smilies/agreed.gif

[Dogway]

LaTo, thanks a lot! This plugin feels profesional, I wonder what SmoothCustom is... : D
btw how do you get that fancy colors in the UV debug, the Cb Cr colors...

[Ponder]

@Lato, Thanks, it clears up what I suspected on Q1&2 since DarkSTR was set to some value ,even
when gamma was 1.

[ChaosKing]

beta5 AVX test
------------------


#smoothlevels(gamma=2.0) # 232.56 FPS
#smoothlevels(gamma=2.0, useOPT=0) # 173.86 FPS
#smoothlevels(gamma=2.0, useOPT=1) # 232.89 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 240.10 FPS

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 83.33 FPS
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 165.28 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 178.57 FPS

I noticed that smoothlevels(gamma=2.0) doesn't seem to use the AVX part. With useOPT=2 it's always faster!

[LaTo]

beta5 AVX test
------------------

#smoothlevels(gamma=2.0) # 232.56 FPS
#smoothlevels(gamma=2.0, useOPT=0) # 173.86 FPS
#smoothlevels(gamma=2.0, useOPT=1) # 232.89 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 240.10 FPS

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 83.33 FPS
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 165.28 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 178.57 FPS

I noticed that smoothlevels(gamma=2.0) doesn't seem to use the AVX part. With useOPT=2 it's always faster!

Thanks for testing! Can you try these 2 dlls (AVXtest.zip (http://latoninf.free.fr/d9/SA/SmoothAdjust.AVXtest.zip)) and report the speed for each?

[ChaosKing]

AVXtest (test)
----------------

##avx 1
#smoothlevels(gamma=2.0) # 233.33 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 232.56 FPS

#smoothlevels(gamma=2.0, useMT=0) # 129.03 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 128.05


##avx2
#smoothlevels(gamma=2.0) # 241.95 FPS
#smoothlevels(gamma=2.0, useOPT=0) # 105.12 FPS
#smoothlevels(gamma=2.0, useOPT=1) # 227.27 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 243.89 FPS

#smoothlevels(gamma=2.0, useMT=0) # 129.03 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 127.39 FPS

avx1 seems to be slower with useMT=-1. Each test was run with 3-5 runs.

[LaTo]

beta5 AVX test
------------------

[...]

I noticed that smoothlevels(gamma=2.0) doesn't seem to use the AVX part. With useOPT=2 it's always faster!

@ChaosKing: Please redownload beta5, now it will autoselect AVX correctly :)

[kostik]

How can I use 16bit ? what command should be put in avisynth?
I get strange colors when using :
ConvertToYv16()
SmoothCurve16("0-65535;32768-32768;65535-0")

can someone write a code to get 16bit ?
thanks

[Dogway]

hey kostik, I like your code but I think that is not going to work.
download dither (http://forum.doom9.org/showthread.php?p=1386559#post1386559) and write the next code:
Dither_convert_8_to_16()
SmoothCurve16("0-0;32768-36768;65535-65535")
ditherpost()

Play with the values but that is a good starting point.

[kostik]

thanks!

[mandarinka]

I want to try processing in 16bit. I assume the filter doesn't support working from 8bit input to 16bit output, right?
Would this be correct to get the MSB/LSB stacked clip, or do I need to use ditherXpre (even though I don't need any actual dithering at that point)?

video = last
stackvertical(video,blankclip(video,color_yuv=$000000))
# and smoothtweak...
smoothtweak16(contrast=0.84)

[cretindesalpes]

Yes, Dither_convert_8_to_16() does exactly that.

Anyway DitherXPre doesn't do any dithering. Dithering is the inverse operation (from 16 back to 8 bits).

[mandarinka]

Oh, I see. To be honest I got a bit lost in all the functions in Dither and wasn't sure what does what (or doesn't) at all...

Thanks for the tip.

[jmac698]

Interesting, I'll have to add support for your stacked kludge into my HDR tools. I use separate clips for msb/lsb because to me it didn't make sense to stack them; most filters wouldn't produce valid results if applied the same way to both bytes.
If you need to pass a highbit video in one clip, that's the only way of course.

[Yellow_]

Ok I have a bit of a problem getting SmoothAdjust to co operate with writing out 16bit image sequences via avs2yuv and imagemagik.

Basically to get SmoothAdjust 16bit functions to work it appears I need to add 'Dither_convert_8_to_16()' otherwise I get the same split frame as Kostick as posted above.

BUT adding 'Dither_convert_8_to_16()' works so far until I try to use:

Dither_convert_yuv_to_rgb(matrix="601", tv_range=false, cplace="MPEG2", chromak="bicubic", output="rgb48yv12")

And then pipe out via avs2yuv to Imagemagick I get this error:

Dither_resize16: Cannot allocate buffer memory.

And no images get written.

But if I remove the: 'Dither_convert_8_to_16()' and hash out the SmoothAdjust stuff I can write 16bit image sequences.

Is SmoothAdjust msb/lsb stack not be implemented the same as Dither 1.9?

[cretindesalpes]

Your problem comes from Dither_convert_yuv_to_rgb() running very quickly out of memory (it uses Dither_resize16() internally). I'm currently working on this issue, to make Dither_resize16 less memory hungry.

[Yellow_]

Ok, thanks for the explanation, wasn't sure if I was using the functions correctly.