Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th September 2011, 14:50 | #901 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,352
|
@Fullmetal Encoder: Im not a programmer so I lack the knowledge to do what jmac698 suggests. But my best bet is if something so useful as masktools isn't already ported to 16 bit, is because it's not a so easy task (I once asked cretindesalpes to make Dither_lutxy16).
I just tweaked the script to process dfttest in 16 bit, and then right after dither down. Its not 16 bit chain, and doesn't output stacked 16 bit. Besides that I removed the inflate and deflate custom function Vit said was probably going to remove in next versions. nnedi3 is 8 bit, I also asked cretindesalpes about it, he said it wasn't easy but maybe by just doing what jmac698 said in the above post it would be feasible. Im not 100% sure but the artifacts could be from QTGMC, or Dither. Im not sure, but I use Dither on a daily basis and never had this kind of issue. Its some colored (purple/green) squares, I will post a sample and debug next time I find it, but its not very common. edit: @Vit: sorry I posted too late, I don't consider dither anything special, or something you can't scale or modify. Dither is what should be done to every single source in 16 bit or higher when going back to 8. It's not grain. There's nothing wrong in using an improved denoiser (just look how bad banding dfttest creates in 8 bit). By using 16 bit you don't smooth, you rather get more precise results (or less rounding errors), but at a cost, so it depends on the filter if its worth or not. Seeing how slow QTGMC and the probably small benefit one would get in 16 bit with it, I consider not worth it, but doing 16 bit processing of some core filters would be beneficial, like dfttest, mdegrain, and hopefully nnedi3 if it ever gets modified. About DitherPre from experience just use DitherPre1, I had some problems once with DitherPre2.
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread Last edited by Dogway; 18th September 2011 at 15:16. |
18th September 2011, 15:46 | #902 | Link | |
Registered User
Join Date: Jan 2011
Posts: 107
|
Quote:
Issues like these always leave me wishing I had hardcore programming skills so that I could create something that might solve these kinds of problems but short of obtaining a 4-year computer science degree I don't believe it's within the realm of possibility. I wonder though what the next step will be. It feels to me that with the advent of widespread availability of 10-bit encoding/decoding and the increasing interest in HD that Avisynth and it's associated tools are becoming increasingly obsolete. I also wonder if the entire video production and broadcast industry will end up moving to 10-bit before that next step comes along or vice versa. |
|
18th September 2011, 19:19 | #903 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Dogway: Maybe you missed my comment about your QTGMC edit. You have added dither to an arbitrary intermediate result in the middle of QTGMC. That dither is not getting out of there alive. It's gonna be attacked by NNEDI3, a few MDegrains and a dozen other filters. None of which will treat it properly to it as either 16-bit color or dither. Your Floyd-Steinberg will make a beautiful 8-bit error diffusion pattern, which will then be mangled by everything else that happens in there. Unless I'm missing something important I don't see why you would want to do that there. Why not just denoise/dither after QTGMC?
I do understand the potential benefits of higher bit-depth processing, especially in conjunction with 10-bit output. I guess my issue is that I don't work with sources that suffer much noise or banding, so the recent interest in dither tools has only been of peripheral interest to me. But considering higher bit-depth processing in a more general sense I suppose improved interpolation accuracy may well help during deinterlacing, albeit primarily in a vertical direction (remember a pure deinterlacer is supposed to be lossless, 50% of the output is supposed to remain untouched, regardless of bit-depth). Still the cost in terms of processing time will be hideous from a purely scripted solution. It's the plugin authors you need to be convincing... |
18th September 2011, 19:46 | #904 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
You're saying that nneedi3 is holding you back? Here's a little math. With a unknown function, you can get 16 bits anytime, as long as f(a*m,b*m)=m*f(a,b). Only the author can tell us that. So the idea is to feed f() different bits of the picture and combine them. Imagine f(a,b)=(a+b)/2, a=12.3, b=15.6. Use m=2 and take only the 8 bits part of a,b, (12*2+15*2)/2=27. Now divide down to m: high=13, low=.5. Now use the low bits: (.3+.6)/2=.5 (keeping 1 decimal place here..) Now add low1+low2=0 and msb=+1, so the final answer, msb=14, lsb=0.
Yes it's a lot of steps and slow but you can extract 16bit from *any* plugin if it meets simple criteria. Does needi3 apply? I'd have to do a simple test and can get you the answer. So in general, there's a very good chance that any 8bit plugin can be manipulated to get 16 bits. I can write a generic function to make 16bits out of any plugin, and with eval, i can be *very* easy to modify an existing plugin.. so I should give a shot at QTGMC. In fact in the best case, I can feed the original code as a string and make *everything* automatically 16 bit! Gonna take a bit of work though.. (I've already written a parser in plain avisynth, btw.. tedious as anything As far as lutxyz needing a lot of memory, you can probably break up the tables and end up being a bit slower... I think there's identities even for trig that if you're smart, you can use a few lookups. Things like the double angle identity can be used to get more bits. As for speed, it can be up to 3 times slower but remember, for something complex like QTGMC, only a few parts will be that slow so it depends what part is taking the most time, because some of the plugins are 16 bit.. and as plugins move towards 16bit, the whole thing gets faster... Last edited by jmac698; 18th September 2011 at 19:59. |
18th September 2011, 20:02 | #905 | Link |
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
Join Date: Feb 2009
Location: No support in PM
Posts: 712
|
This is basically what Dither1Pre and Dither2Pre do, but with a very limited success. And most plug-ins are clearly not linear functions.
__________________
dither 1.28.1 for AviSynth | avstp 1.0.4 for AviSynth development | fmtconv r30 for Vapoursynth & Avs+ | trimx264opt segmented encoding |
18th September 2011, 21:04 | #906 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Ok, for f(x)=x^n, f(x*m)=f(x)*m^n so any power function can be automatically compensated and accounted for. That means any polynomial function can be made 16bit. Most of the time nnedi3 is bicubic so most pixels will look good, but then your losing the advantage of nnedi3 in the first place. You could try a small interpolation, though. Actually I know how to make a special case for nnedi3...
Also, there is a 16bit masktools: SmoothCustom16 Last edited by jmac698; 18th September 2011 at 21:10. |
19th September 2011, 08:00 | #907 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,352
|
-Vit- Dither doesn't add any artificial pixels, is not like gradfundb (it doesn't deband, it prevents banding!). Ordered dither is only useful at the end ready for encoding in this context. Prior to that you can keep a 16 bit chain, or use 16 bit filters dithering down to floyd steinberg each time, still this is way better than a 8 bit chain. What I only did was to add better precision to dfttest, and had to dither down for consequent 8 bit processing, thus what you see as noise (which is error diffusion) is just useful source pixel information finding its place in the 8 bit realm. The same useful "noise" you find in every picture (in order to avoid bands/color stepping in 8 bit images), not random thrown noise like addgrain or gradfundb, thats why its not called noise, but dither. I know I didn't do anything wrong in the script, but if you are still insecure ask the gurus. I can delete the script if you think I'm misleading...
jmac698: good one! can I load two clips in smoothcustom for lutxy operations? About the artifacts, I correct myself, its not QTGMC. I think it can probably be ffdshow FFV1, so Im gonna update that and see if it has been solved.
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread Last edited by Dogway; 19th September 2011 at 08:16. |
22nd September 2011, 19:33 | #915 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Yes, should have said. It can't really be used stand-alone for double rate. It uses Bob so it introduces bob-flicker. That's what the other parts of the QTGMC algorithm remove.
Last edited by -Vit-; 22nd September 2011 at 19:44. |
30th September 2011, 09:18 | #917 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
There is a 64 bits version of NNEDI3 (v0.9.2 or v0.9.3), but not of the last version (v0.9.4). I think you can find it in the nnedi thread.
It is possible to use QTGMC in a 64 bit workflow, but using avisynth64_4-16-10, not avisynth64_8-29-10 (crash). Maybe avisynth-x64-20110906 work, i have not tested yet. Last edited by jpsdr; 30th September 2011 at 09:21. |
Thread Tools | Search this Thread |
Display Modes | |
|
|