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. |
|
|
Thread Tools | Search this Thread | Display Modes |
15th January 2012, 23:55 | #1 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
Improving compressibility of grainy sources with little to no visual impact - ideas?
As the subject says... I'd like to hear people's ideas or tricks you use for encoding grainy sources when the goal is to preserve the look. Something like denoising without the effects being visible.
I know that one can use encoding tools like psy trellis, but relying on x264's abilities means that the cost of keeping the grain (or something that looks similar to the original grain) is simply there, compromising the amount of bits we can spend on detail that is underneath that grain. That's why I'd like to hear your ideas on how to actually make a grainy source compress (even just slightly) better, so that the overall quality can be improved. As said, I'm interested in such filtering that would have as little visual impact as possible. Some approaches that come to my mind: for example, separating noise and softening it a little bit before adding back; or alternatively some denoising that would only remove faint noise while keeping the coarser, more rough part of it. I assume the latter might be able to preserve the look of film grain, but such effect might actually be partially realised by the encoding itself, so this might not be successful in practice. P.S.: Thanks for your input Last edited by mandarinka; 16th January 2012 at 00:12. |
16th January 2012, 00:38 | #2 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Just these days, I plugged a little script with a similar goal: dampen the grain just a little, to keep the original look, and make it fast, because it's kind of PITA if a sluggish script does almost nothing. (And in particular when it's plenty of seasons with plenty of episodes...)
I took Spresso, and extended the spatial principle to temporal, using Fluxsmooth. The basic chain Code:
Spresso(4,24,2).STpresso(4,24,4,12,3,49,1) The script is pretty fast, speed hit is neglectible. (Eventually, the encoding even may go faster, due to the grain becoming "easier".) Code:
function STPresso(clip clp, int "limit", int "bias", int "RGmode", int "tthr", int "tlimit", int "tbias", int "back") { limit = default( limit, 3 ) # spatial limit: the spatial part won't change a pixel more than this bias = default( bias, 24 ) # bias: the percentage of the spatial filter that will apply RGmode = default( RGmode, 4 ) # the spatial filter is RemoveGrain, this is its mode tthr = default( tthr, 12 ) # temporal threshold for fluxsmooth. Can be set "a good bit bigger" than usually tlimit = default( tlimit, 3 ) # the temporal filter won't change a pixel more than this tbias = default( tbias, 49 ) # the percentage of the temporal filter that will apply back = default( back, 1 ) # after all changes have been calculated, reduce all pixel changes by this value. (Shift "back" towards original value) LIM1 = (limit>0) ? string( round(limit*100.0/bias-1.0) ) : string( round(100.0/bias) ) LIM2 = (limit<0) ? "1" : string(limit) BIA = string(bias) BK = string(back) TLIM1 = (tlimit>0) ? string( round(tlimit*100.0/tbias-1.0) ) : string( round(100.0/tbias) ) TLIM2 = (tlimit<0) ? "1" : string(tlimit) TBIA = string(tbias) expr = (limit<0) ? "x y - abs "+LIM1+" < x x 1 x y - x y - abs / * - ?" \ : "x y - abs 1 < x x "+LIM1+" + y < x "+LIM2+" + x "+LIM1+" - y > x "+LIM2+" - " \ + "x 100 "+BIA+" - * y "+BIA+" * + 100 / ? ? ?" texpr = (limit<0) ? "x y - abs "+TLIM1+" < x x 1 x y - x y - abs / * - ?" \ : "x y - abs 1 < x x "+TLIM1+" + y < x "+TLIM2+" + x "+TLIM1+" - y > x "+TLIM2+" - " \ + "x 100 "+TBIA+" - * y "+TBIA+" * + 100 / ? ? ?" bzz = clp.removegrain(RGmode) mt_lutxy( clp, bzz, expr, U=3,V=3) tthr==0 ? last : mt_lutxy(last,last.mt_makediff(mt_makediff(bzz,bzz.fluxsmootht(tthr),U=3,V=3),U=3,V=3),texpr,U=3,V=3) back==0 ? last : mt_lutxy(last,clp,"x "+BK+" + y < x "+BK+" + x "+BK+" - y > x "+BK+" - y ? ?",U=2,V=2) }
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
16th January 2012, 01:13 | #3 | Link |
Registered User
Join Date: Sep 2008
Posts: 365
|
I usually run TTempSmoothF(strength=1,maxr=7) to increase compression without noticeable quality loss, but I've seen this create some artifacts on the luma plane on high motion scenes, using motion compensation usually solves this, but the speed will slow down quite a bit...
But considering Didée's history on this forum, his solution is more likely a better option |
16th January 2012, 15:11 | #4 | Link |
Registered User
Join Date: Mar 2006
Posts: 1,049
|
http://registry.gimp.org/node/11742 - can be nice if someone will implement this as a Avisynth filter...
|
16th January 2012, 15:51 | #5 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
@pandy: For the time being, you can do with FFT3dFilter or dfttest. Or generally with any spatial filter - apply a lowpass, filter the lowpassed image, re-apply the hipass.
___ edit: found a free minute. Code:
fft3dfilter(sigma=0.01,sigma2=1,sigma3=4,sigma4=8,bw=16,bh=16,ow=8,oh=8,bt=1,plane=0)
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 16th January 2012 at 16:32. |
16th January 2012, 17:22 | #6 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
I'm testing the S(T)Presso functions and I'm pleasantly surprised For example, I was able to get reductions even with lowered settings that virtually 'did nothing' (which is nice, although I didn't have much time to check what it does with quality, with low differences in filesize it's hard to tell). Optimal settings would be higher, but so far I was trying it from the obsessive side of things.
What I noticed however is something I assume is fluxsmooth-related, because I recall it from DFMDerainbow: at the default tthr of 12, I was getting some artifacting in pans (can probably happen in other motion), where fluxsmooth got fooled and averaged stuff it shouldn't have (motion compensating prevented it); and also, in an animation source with colour flashes, the averages caused changes in hue in large areas (lowering tthr to about 6 made them mostly go away) or stuff like gun blazes. This probably wouldn't be issue in live action footage, and even here, the averaging shouldn't be that visible in motion, human eyes probably don't care much. I don't know what's the internal operation of fluxsmooth like, but it probably isn't very careful about chroma... Last edited by mandarinka; 16th January 2012 at 17:25. |
16th January 2012, 17:50 | #7 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,717
|
Didée, can you please come up with a modification for 1080p sources? That function looks just like what I was looking for some time ago - improve compressibility but retain much of the detail.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
20th March 2012, 11:47 | #12 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Why not? What error message? What script?
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
20th March 2012, 13:54 | #14 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Sure. This forum offers private message (PM) functionality.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
23rd April 2012, 15:59 | #16 | Link | |
Registered User
Join Date: Oct 2009
Posts: 212
|
Quote:
Last edited by SilaSurfer; 23rd April 2012 at 16:39. |
|
23rd April 2012, 23:11 | #17 | Link |
Leader of Dual-Duality
Join Date: Aug 2010
Location: America
Posts: 134
|
@SilaSurfer
From what I understand the whole point of using fluxsmooth is that it works very quickly so adding motion compensation atleast proper motion compensation would probably make it a lot less viable as a "quick guiltless compression aid" then again I could be wrong and maybe proper motion compensation could be achieved while not completely ruining the speed.
__________________
I'm Mr.Fixit and I feel good, fixin all the sources in the neighborhood My New filter is in the works, and will be out soon |
25th April 2012, 15:59 | #18 | Link | |
Registered User
Join Date: Oct 2009
Posts: 212
|
Quote:
Last edited by SilaSurfer; 25th April 2012 at 16:04. |
|
25th April 2012, 21:37 | #19 | Link | |
Leader of Dual-Duality
Join Date: Aug 2010
Location: America
Posts: 134
|
Quote:
__________________
I'm Mr.Fixit and I feel good, fixin all the sources in the neighborhood My New filter is in the works, and will be out soon |
|
25th April 2012, 21:50 | #20 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
The rough demo is present, since many many years, in the documentation of MVTools. Section "Usage examples". Just replace DegrainMedian with FluxSmooth.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
Thread Tools | Search this Thread |
Display Modes | |
|
|