stefan schrieb: > Steven M. Schultz schrieb: > >> On Wed, 5 Jul 2006, Michael Hanke wrote: >> >>> Hmmm... Please excuse my dumb question. Here are you puzzling me a little >>> bit. >>> >>> >> It is not dumb at all! You raise some very interesting points that >> people should be aware of. >> >> > Yes, indeed. > >>> My model of thinking with respect to interlacing/deinterlacing is as >>> follows: >>> - If the material is tv life (say a football match with very fast motion) >>> then >>> I think that is is a good idea to let the material interlaced because of >>> the >>> "kammeffekt" (Sorry, I don't know the correct english word). >>> >>> > Well, I was quite satisfied with such an answer for a long time, too, > but nowadays, I'm not. > > 1. Deinterlacing has nothing to do with destroying temporal resolution. > yuvdeinterlace has (as any other good deinterlacer, I know) the option > to deliver 50 frames interpolated from 50 fields. As it does *not* alter > the original scanlines in this case, the quality is higher than what any > other, freely available deinterlaciner does do in this case. This is OK, > even for fast moving sport-events. You get 50 frames out of 50 fields. > Subjective Quality in this case is a lot *better* than before. You can > use this for nice slow-motion-effects, too... > > 2. Most people can not distinguish temporaly decimated material from > 50(60) to 25(30) fps, if it is progressive. Yes, if it is interlaced, > they can. But this is because of the *defects* of interlaced images. > Yes, I agree that 50 fps progressive material would even be a little > better than 25 fps progressive material, but this is somewhat like the > discussion if we really need 24 Bit 96 kHz audio (which we clearly do > *not* really need... as we are no bats) to get a more "analog" listening > expirience. The physiological limit of visual temporal resolution which > leads to the impression of fluent motion is about 12-15 fps depending on > the individual. 25 fps is so much above this that (for most people) we > can forget about 50 fps. 50 fields/s just remains an excuse for 1920s > technology in this context. > > >> "temporal resolution" is the appropriate phrase. And 60 (or 50) >> fields/sec will give better "motion" than 25 (30) frames/sec. >> >> > Correct. > >> Of course 60 (or 50 for Europe) _frame_/second progressive would >> be fantastic for sporting (high action) events - and in the US some >> stations do indeed broadcast 1280x720p HDTV at 60 frames/sec. >> >> > I do agree, too. > > >>> direction. The critical thing happens if I use my Canopus to digitize to dv >>> which has 420 subsampling. If I would deinterlace in that case, the >>> vertical >>> chroma resolution becomes wrong. Am I wrong here? >>> >>> >> You are CORRECT. Deinterlacing 4:2:0 is TRICKY and complicated by >> the fact there are 3 variants of 4:2:0 >> >> > No, not completely. For 2 of that 3 variants the result will be correct. > The 3rd variant is caused by a bug in the kernel-implementation of > interlaced 4:2:0 with the BTTV-chipsets. The 4:2:0 subsampling of the > canopus is correct and does not cause problems. The BTTV-driver (the > chipset can do it correctly...) is wrong here. This is known for ages, > now. But as it seems that no-one notices it... > > >> See >> http://www.mir.com/DMG/chroma.html >> >> for a good explanation of the 420 layouts. >> >> > This does not refer to the problem he discribes. This does refer to the > different spatial positions of the chroma-samples relative to the > luminance-samples-position. The relative spatial position of > chrominace-samples is irrelevant to a deinterlacer. The relative > *temporal* position however is not (and this gets severely damaged with > a BTTV in 4:2:0 mode...). > >>> BTW. Sometimes I have the feeling that the fields are shifted by one frame >>> in >>> the dv capturing. Can this happen? >>> >>> > Only if it's a VHS-deck, you record from. Signal quality is bad then. > This is true for the sync impulses, too. In any other cases I would > agree with Steven and say no. > > >>> often used commercial VHS tape for my archive. >>> > I hope it has more than 240 lines of horizontal resolution... > > >>> It had an unusual high noise >>> >>> > does not surprise me... > >>> level. Playing around with the different denoiser settings my test audience >>> had a very strange view: The best impression made the noisy tape because of >>> its "sharpness"! When using yuvdenoise (without any tuning) the picture was >>> considered blurred, unsharp, unviewable >>> >>> > Hmm, do you use the current CVS version? I guess, not, as the current > CVS version is preset to not filter at all. The old version had some > default values set, mainly to let people see the filtering happen and > then finetune it to their needs, but this quickly came out as a bad > idea: People allways tried to use the default-settings to filter > everything with the result of blurred, flat images... So I set all > defaults to zero. The user is forced to choose values fitting to the > video, now. > > To noise-filtering in general: > > 1. it can be mathematically proven, that denoising *always* will destroy > useful information. > 2. use as low filtering, as possible (unlike you want ugly results...) > 3. the settings were you just can't see a noise-filter working, are good... > > (4. I tend to (if I can spare the bitrate...) not denoise at all -- I > invented a denoiser, but I'm not too mad *g*. The best method to denoise > is: no denoising at all but raising the bitrate and encode all noise, > too. Halving the horizontal resolution and keeping the max. bitrate is > jut the same. Esp. if the video does not have more than 350 lines of > horizontal resolution (VHS!)) > >> If I read that correctly you're saying that the NOT-denoised video >> was preferred to the 'denoised' version. >> >> > > This, I can't verify, as the noise-floor in my videos is generaly that > high, that the encoder produces visable blocks, which my audience keeps > finding even more ugly than a little loss in sharpness... With true > noise you easily can crank up to 10Mbps... When correctly set all my > audience preferred the denoised over the not-denoised material. If it is > the other way it is a strong indice of too harsh filtering. > > >>> This seems to be a psychological question: Better noisy than unsharp. >>> >>> > > Yes, correct, our brain is trained to imagine what could have been there > if the information is random. If it is clearly flat, it does not leave > room for imagination... We perceive it as dull/flat/unsharp, then. > > >> It depends on the person of course. But yes, excessive denoising >> seems to blur / soften the image too much. >> >> > > Which can be proven, as stated above. This is just because of the fact > that at some level the algorithm can not for sure destinguish between > detail and noise, any more... So it decides somehow and makes mistakes... > > >> The solution is to either 1) use higher capacity media (dual layer) >> >> > > This often fails because of the maximum datarate a DVD has. VHS-tapes > often are that damn noisy that you would need 10+Mbps to avoid ugly > blockyness... > > >> or 2) use "half D1" (that is a misnomer but the term has become common >> usage) frame size - for "PAL" that's 352x576 (for "NTSC" it is >> 352x480) and a high bitrate. >> >> > > This is (at least for VHS-tapes) the solution as it increases the > relative resolution. > sorry... "...relative bitrate" > >>> In the literature about denoising methods, I found edge sharpening >>> denoising >>> methods based on anisotropic diffusion equations. For me as a mathematician >>> this approach looks very sound. Does somebody have experiences with such >>> >>> > > I have tried that one in a simple (suited for implementation, not for > theoretical beauty...) version. It was a) extraordinary slow b) did not > provide a really viewable result and c) was blurry... It clearly (as all > 2D filters do...) performed much worse (esp. with any form of > mpeg1/2/4-encoder behind it) than simple non-motion-compensated-temporal > filtering alone. > > There are a lot denoising-ideas arround (most of them invented to come > arround patents). Only very few can help a video-encoder behind it (and > this is the *only* justification to denoise at all!!!) > > >> No, I've no experience with that - but then I'm not a mathematician ;) >> >> > > My brother is... He liked the idea, too... This is, why I tried it... > > BTW: I liked the idea of max. entropy filtering, too, once... didn't > perform reasonably, either... > > >> It sounds similar to the 'blur' + 'unsharp mask' technique though. >> >> > it is quite similar. Despite it does edge detection first. > > >> I'll have to try enabling the 'motion compensated' ("high quality") >> mode that was recently added to yuvdenoise. It will be interesting to >> see the difference (both in speed and quality). >> >> > I look forward to hear the results... :-) In the meantime it seems, that > I need to tweak the MC-Patch-Size... > > cu > Stefan > >
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
