Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Mark Rejhon - 2000-10-30 04:03 ```Some more that trips things up....that will require sector-based deinterlacing, even horizontally... - Weather shows, where weatherman moves and stops moving (Causes graphics to intermittently flicker when he is moving) - TV guide channel. Right-hand-side is video advertisements, and left hand is sharp TV guide graphics. - Small video windows in the middle of graphics - News conferences - Advertisements We definitely need zone-based CombFactor! Mark Rejhon wrote: > > Another scenario that needs zone-based deinterlacing: > > Golf balls flying through a blank sky. > > Currently, this executes a weave algorithm, which makes the golf > ball break up into weave artifacts. If we had zone based > deinterlacing, the sky would be weaved (with new algoirthm) > while the golf ball would be bobbed (with the old algorithm). > > (Right now, as it stands, golf balls look downright ugly in > this version. ;) > > Mark Rejhon wrote: > > > > Hi Steve, > > > > You're amazing! This is a reasonable compromise between the > > old one (better for motion) and the new one (better for motioneless). > > It's not a perfect compromise but I think this warrants a new release > > very shortly. I think we should make this Version 1.9.1 ;) > > What do you think? > > > > //// > > > > I have an idea... How about doing both algorithms on the > > same image? That is, use the old algorithm for blocks > > of image that is in motion, and use the new algorithm > > for blocks of image that is stationary. Perhaps 4x16 > > pixel blocks or something. > > > > To do this, will require GetCombFactor to produce a new > > buffer that holds a 2-dimensional array of CombFactor's > > to represent different blocks of image. > > > > Then CombFactor would return both a full-screen CombFactor, > > but also return a 2-dimensional CombFactor array that > > represents the CombFactor of small image blocks of a > > custom defined size (like 4x4 pixels, 8x8 pixels, > > 4x16 pixels). > > > > That way, we can execute the new algorithm on blocks that > > have a low CombFactor .... And the old algorithm on blocks > > that have a high CombFactor .... > > > > What do you think, Steve Grimm? ;-) > > > > Please comment if this idea is feasible! > _______________________________________________ > Deinterlace-discuss mailing list > Deinterlace-discuss@... > http://lists.sourceforge.net/mailman/listinfo/deinterlace-discuss -- _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

[Deinterlace-discuss] Both video deinterlace algorithms now supported Steven Grimm <koreth@mi...>
 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Mark Rejhon - 2000-10-29 23:24 ```Hi Steve, You're amazing! This is a reasonable compromise between the old one (better for motion) and the new one (better for motioneless). It's not a perfect compromise but I think this warrants a new release very shortly. I think we should make this Version 1.9.1 ;) What do you think? //// I have an idea... How about doing both algorithms on the same image? That is, use the old algorithm for blocks of image that is in motion, and use the new algorithm for blocks of image that is stationary. Perhaps 4x16 pixel blocks or something. To do this, will require GetCombFactor to produce a new buffer that holds a 2-dimensional array of CombFactor's to represent different blocks of image. Then CombFactor would return both a full-screen CombFactor, but also return a 2-dimensional CombFactor array that represents the CombFactor of small image blocks of a custom defined size (like 4x4 pixels, 8x8 pixels, 4x16 pixels). That way, we can execute the new algorithm on blocks that have a low CombFactor .... And the old algorithm on blocks that have a high CombFactor .... What do you think, Steve Grimm? ;-) Please comment if this idea is feasible! //// Steven Grimm wrote: > > I've changed the code so both deinterlace algorithms are available. > I called the new algorithm "Video Deinterlace (Weave)" and the old > one "Video Deinterlace (Bob)" to indicate their tendencies to err > on the side of weaving or bobbing. > > The autodetect code selects between the two algorithms by looking > at the field difference. I'm currently using the same thresholds > as the 3:2 pulldown detection, which may or may not be a bright idea. > The basic idea, ignoring 3:2 pulldown for the sake of clarity, is > > if difference > Threshold32Pulldown > if difference > ThresholdPulldownMismatch > video-bob mode > else if it's been low for a few fields > video-weave mode > else > if it's been low for StaticImageFieldCount fields > simple-weave mode > else > video-weave mode > > I raised the StaticImageFieldCount default to 100 since going from > video-weave to simple-weave doesn't improve image quality, it just > cuts down on CPU time. > > This appears to work okay, though it goes into video-bob mode a bit > more than I'd like. This may be a matter of poor choice of thresholds, > but what I'd really like to do is get both the field difference and > the comb factor for each new field, and base the decision of which > video deinterlace algorithm to use on the comb factor. Trouble is, > we don't ordinarily compute the comb factor right now, so adding that > would make the mode detection eat more CPU time. > > What we ought to do, I think, is merge CompareFields() and > GetCombFactor() into one function, since they repeat each other's > work to some extent. The PAL code would benefit from this as well; > right now its autodetection is only based on comb factor, never > field difference. > > Oh, one other tweak that makes life a lot nicer: I added a > shift+spacebar accelerator to cycle backwards through the deinterlace > modes. That way you don't have to walk through all the film modes > to get from one video mode to another. > > -Steve > _______________________________________________ > Deinterlace-discuss mailing list > Deinterlace-discuss@... > http://lists.sourceforge.net/mailman/listinfo/deinterlace-discuss -- _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Mark Rejhon - 2000-10-29 23:46 ```Hi, I keep seeing many examples why we need zone-based deinterlacing; Sports graphics, network logos, popup namecards, captions, etc, whenever there's intermittent motion. The jagged come back and dissappear as it switches between the two algorithms depending on the amount of motion elsewhere in the image. Either way, your idea of using both algorithms is a pretty neat compromise! Though I'd love you to improve upon that further by using the zone-based deinterlacing suggestion that I illustrated below! Maybe someday, down the road, you can replace the two algorithms with one that blends between the old one and the new one, depending on the CombFactor of each zone (mini block) of the image. Thanks, Mark Rejhon Mark Rejhon wrote: > > Hi Steve, > > You're amazing! This is a reasonable compromise between the > old one (better for motion) and the new one (better for motioneless). > It's not a perfect compromise but I think this warrants a new release > very shortly. I think we should make this Version 1.9.1 ;) > What do you think? > > //// > > I have an idea... How about doing both algorithms on the > same image? That is, use the old algorithm for blocks > of image that is in motion, and use the new algorithm > for blocks of image that is stationary. Perhaps 4x16 > pixel blocks or something. > > To do this, will require GetCombFactor to produce a new > buffer that holds a 2-dimensional array of CombFactor's > to represent different blocks of image. > > Then CombFactor would return both a full-screen CombFactor, > but also return a 2-dimensional CombFactor array that > represents the CombFactor of small image blocks of a > custom defined size (like 4x4 pixels, 8x8 pixels, > 4x16 pixels). > > That way, we can execute the new algorithm on blocks that > have a low CombFactor .... And the old algorithm on blocks > that have a high CombFactor .... > > What do you think, Steve Grimm? ;-) > > Please comment if this idea is feasible! ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Mark Rejhon - 2000-10-29 23:48 ```Another observation... I notice that in football games, as there is horizontal motion, there is steaking (trailing ghosts) of the 5-yard bars. Hitting the P pause key while a footbal game is panning horizontally quickly, confirms this. Also, sometimes I see combing artifacts between red and green of the same luminousity. I can just about notice these combing artifacts (even sometimes with the old algorithm). For faster computers, we probably should think about checking chroma too, not just luma. We definitely need an architecture of multiple algorithms that are easy to add without interfering with existing ones.... That way people (like you) can experiment with adding new algorithms that may require a faster computer! _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Mark Rejhon - 2000-10-29 23:56 ```Another scenario that needs zone-based deinterlacing: Golf balls flying through a blank sky. Currently, this executes a weave algorithm, which makes the golf ball break up into weave artifacts. If we had zone based deinterlacing, the sky would be weaved (with new algoirthm) while the golf ball would be bobbed (with the old algorithm). (Right now, as it stands, golf balls look downright ugly in this version. ;) Mark Rejhon wrote: > > Hi Steve, > > You're amazing! This is a reasonable compromise between the > old one (better for motion) and the new one (better for motioneless). > It's not a perfect compromise but I think this warrants a new release > very shortly. I think we should make this Version 1.9.1 ;) > What do you think? > > //// > > I have an idea... How about doing both algorithms on the > same image? That is, use the old algorithm for blocks > of image that is in motion, and use the new algorithm > for blocks of image that is stationary. Perhaps 4x16 > pixel blocks or something. > > To do this, will require GetCombFactor to produce a new > buffer that holds a 2-dimensional array of CombFactor's > to represent different blocks of image. > > Then CombFactor would return both a full-screen CombFactor, > but also return a 2-dimensional CombFactor array that > represents the CombFactor of small image blocks of a > custom defined size (like 4x4 pixels, 8x8 pixels, > 4x16 pixels). > > That way, we can execute the new algorithm on blocks that > have a low CombFactor .... And the old algorithm on blocks > that have a high CombFactor .... > > What do you think, Steve Grimm? ;-) > > Please comment if this idea is feasible! ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Steven Grimm - 2000-10-30 00:05 ```I planned to do something similar as part of the as-the-data-arrives video processing mod. It can get even fancier than that, in fact; there's no reason why we can't do pulldown detection, etc. at high granularity as well. Think Mystery Science Theater with the silhouettes in video mode and the rest of the picture in film mode. This should be straightforward and not too terribly expensive to do on a per-scanline basis, which will handle 90% of the cases since scores and captions and stock tickers tend to stretch horizontally across the screen rather than vertically (is that the case for material you watch too?) Doing smaller regions within scanlines may take more horsepower than any of our development systems have, which would obviously make testing a bit of a problem! You can adjust the region size to mitigate that somewhat, but my unsubstantiated gut feel is that for my system, anyway, I'd have to make the regions big enough that the benefit would be questionable. What to show in the status bar when you're half in film mode and half in video mode is the burning question. :) -Steve On Sun, Oct 29, 2000 at 06:28:30PM -0500, Mark Rejhon wrote: > Hi Steve, > > You're amazing! This is a reasonable compromise between the > old one (better for motion) and the new one (better for motioneless). > It's not a perfect compromise but I think this warrants a new release > very shortly. I think we should make this Version 1.9.1 ;) > What do you think? > > //// > > I have an idea... How about doing both algorithms on the > same image? That is, use the old algorithm for blocks > of image that is in motion, and use the new algorithm > for blocks of image that is stationary. Perhaps 4x16 > pixel blocks or something. > > To do this, will require GetCombFactor to produce a new > buffer that holds a 2-dimensional array of CombFactor's > to represent different blocks of image. > > Then CombFactor would return both a full-screen CombFactor, > but also return a 2-dimensional CombFactor array that > represents the CombFactor of small image blocks of a > custom defined size (like 4x4 pixels, 8x8 pixels, > 4x16 pixels). > > That way, we can execute the new algorithm on blocks that > have a low CombFactor .... And the old algorithm on blocks > that have a high CombFactor .... > > What do you think, Steve Grimm? ;-) > > Please comment if this idea is feasible! > ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Steven Grimm - 2000-10-30 00:15 ```On Sun, Oct 29, 2000 at 06:50:03PM -0500, Mark Rejhon wrote: > Maybe someday, down the road, you can replace the two > algorithms with one that blends between the old one and > the new one, depending on the CombFactor of each zone > (mini block) of the image. In fact, I spent most of yesterday doing just that, trying to come up with an algorithm that combined the best of both the current ones. It's trickier than it seems at first blush, and I wasn't able to find a satisfactory solution. I must have gone through at least 10 different algorithms -- some of them did fancy things like delay playback by a frame so they could look ahead at the next frame to see if an apparent weave artifact would still be there next time around. (I think that idea will lead to the optimum algorithm, BTW, but clearly there's some subtle aspect of it that I couldn't figure out.) The problem is that one of the new algorithm's strengths is its ability to render what look like comb artifacts but aren't, like 1-pixel-high horizontal lines. If you naively computed the comb factor of the small region around a horizontal dividing line, you'd get a really high value and thus switch to the old algorithm, making the line flicker like crazy again. -Steve ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Steven Grimm - 2000-10-30 00:36 ```> It's not a perfect compromise but I think this warrants a new release > very shortly. I think we should make this Version 1.9.1 ;) > What do you think? I think all the stuff that's landed in the last couple of days -- a new deinterlace algorithm, triple buffering, proper surface locking, your UI improvements -- really warrants a bigger indication of change. I'd vote for 1.10. (2.0, we can save for subpicture mode detection; if that doesn't warrant a major version number I'm not sure what would.) -Steve ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Mark Rejhon - 2000-10-30 04:03 ```Some more that trips things up....that will require sector-based deinterlacing, even horizontally... - Weather shows, where weatherman moves and stops moving (Causes graphics to intermittently flicker when he is moving) - TV guide channel. Right-hand-side is video advertisements, and left hand is sharp TV guide graphics. - Small video windows in the middle of graphics - News conferences - Advertisements We definitely need zone-based CombFactor! Mark Rejhon wrote: > > Another scenario that needs zone-based deinterlacing: > > Golf balls flying through a blank sky. > > Currently, this executes a weave algorithm, which makes the golf > ball break up into weave artifacts. If we had zone based > deinterlacing, the sky would be weaved (with new algoirthm) > while the golf ball would be bobbed (with the old algorithm). > > (Right now, as it stands, golf balls look downright ugly in > this version. ;) > > Mark Rejhon wrote: > > > > Hi Steve, > > > > You're amazing! This is a reasonable compromise between the > > old one (better for motion) and the new one (better for motioneless). > > It's not a perfect compromise but I think this warrants a new release > > very shortly. I think we should make this Version 1.9.1 ;) > > What do you think? > > > > //// > > > > I have an idea... How about doing both algorithms on the > > same image? That is, use the old algorithm for blocks > > of image that is in motion, and use the new algorithm > > for blocks of image that is stationary. Perhaps 4x16 > > pixel blocks or something. > > > > To do this, will require GetCombFactor to produce a new > > buffer that holds a 2-dimensional array of CombFactor's > > to represent different blocks of image. > > > > Then CombFactor would return both a full-screen CombFactor, > > but also return a 2-dimensional CombFactor array that > > represents the CombFactor of small image blocks of a > > custom defined size (like 4x4 pixels, 8x8 pixels, > > 4x16 pixels). > > > > That way, we can execute the new algorithm on blocks that > > have a low CombFactor .... And the old algorithm on blocks > > that have a high CombFactor .... > > > > What do you think, Steve Grimm? ;-) > > > > Please comment if this idea is feasible! > _______________________________________________ > Deinterlace-discuss mailing list > Deinterlace-discuss@... > http://lists.sourceforge.net/mailman/listinfo/deinterlace-discuss -- _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 Re: [Deinterlace-discuss] Both video deinterlace algorithms now supported From: Steven Grimm - 2000-10-30 07:07 ```On Sun, Oct 29, 2000 at 11:06:57PM -0500, Mark Rejhon wrote: > We definitely need zone-based CombFactor! There's really no need to convince us... I think we all agree it's a good goal. Now someone just has to do it. Probably won't be me, at least not for a while; I've let a fair bit of real work pile up over the last few days while I've been playing with dTV and I kind of need to catch up now. I'm going to swear off dTV hacking for a while. It's too addictive. :) To encourage others: before I started playing with the deinterlace code last week, I had not written a line of Intel assembly code in about 10 years, had never used an MMX instruction before, and had only a vague idea how the old deinterlace algorithm worked. So it's possible to come up to speed on this stuff in very short order. I've done my best to make it even easier by putting lots of comments in my code; you should be able to follow exactly what it's doing without much effort. Hope someone can step up to the plate and make it happen! -Steve ```

 [Deinterlace-discuss] //// NEWS ALERT //// dTV Version 2.0.0 Released! From: Mark Rejhon - 2000-10-30 10:32 ```And here's the release you've been waiting for... We go simultaneously to Version 2.0.0 and to a three-digit version numbering system! Version 2.0.0 Binary - http://deinterlace.sourceforge.net/distributions/dTV200exe.zip Source - http://deinterlace.sourceforge.net/distributions/dTV200src.zip Bug fixed - Tearing is gone at all refresh rates! Bug fixed - Error message no longer pops up if you resize video window too small. Bug fixed - Video no longer becomes purple when resizing or maximizing. Better Automatic Aspect Ratio Detection defaults Smoother Synchronization Triple Buffering Added Option to Disable Startup Splash Screen Changed Keyboard Shortcuts; See List - New shortcuts added for video source and video format selection - Some existing shortcuts modified for better intuition New Video Deinterlace Algorithm - better for slow moving images, especially graphics displays. Old Video Deinterlace Algorithm - still available, better for fast motion. Automatic switching between three Video Deinterlace algorithms: - Simple Weave during static images - New Video Deinterlace during slow moving images - Old Video Deinterlace during fast moving images _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 [Deinterlace-discuss] Bad 3:2 pulldown worse in dTV 2.0 From: Mark Rejhon - 2000-10-30 21:56 ```Hi, Just so that you know, I notice that the bad 3:2 pulldown rejection capability is worse in dTV version 2 - it looks like we will have to look into this! _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 [Deinterlace-discuss] Re: //// NEWS ALERT //// dTV Version 2.0.0 Released! From: Michael Eskin - 2000-10-31 20:23 ```Hi Mark, Steven, I've started doing some development work with the new release and I have a fix to a problem with the VxD device enumeration and detection. It doesn't work right if you've had several other boards installed in your system at some point because Win98 leaves old entries in the ENUM/PCI registry area. When you try and do your device detection the current VxD uses the first match of the device ID in the registry, which may not coorespond to the installed device. I've got a fix for the VxD to continue enumerating all devices until if finds a match. I'll figure out how to get it in the project this afternoon. I've joined the sourceforge site, just need to figure out the web based project management. If either of you are interested in coming to work at Conexant in San Diego, I'd like to extend an offer to fly you out for an interview. We have several positions for software engineers in our video products groups and are actively recruiting. Cheers and best regards, Michael Eskin Conexant Systems ```

 [Deinterlace-discuss] Re: //// NEWS ALERT //// dTV Version 2.0.0 Released! From: Mark Rejhon - 2000-10-31 20:57 ```Hi, That's great! Let me know if you want instructions on how to access the source code in the CVS repository.... Please say hello to Adrin Kwong, an old Ottawa friend of mine, currently working at Conextant in San Diego! Michael Eskin wrote: > > Hi Mark, Steven, > > I've started doing some development work with the new release and I have a > fix to a problem with the VxD device enumeration and detection. It doesn't > work right if you've had several other boards installed in your system at > some point because Win98 leaves old entries in the ENUM/PCI registry area. > When you try and do your device detection the current VxD uses the first > match of the device ID in the registry, which may not coorespond to the > installed device. I've got a fix for the VxD to continue enumerating all > devices until if finds a match. I'll figure out how to get it in the project > this afternoon. I've joined the sourceforge site, just need to figure out > the web based project management. > > If either of you are interested in coming to work at Conexant in San Diego, > I'd like to extend an offer to fly you out for an interview. We have several > positions for software engineers in our video products groups and are > actively recruiting. > > Cheers and best regards, > > Michael Eskin > Conexant Systems -- _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 [Deinterlace-discuss] Re: //// NEWS ALERT //// dTV Version 2.0.0 Released! From: Mark Rejhon - 2000-10-31 23:25 ```Hi Michael, Are you on the dTV mailing list? You should send all correspondence to deinterlace-discuss@... instead of just to my email address for quicker response. To join the mailing list, go to: http://sourceforge.net/mail/?group_id=7420 You can also add an email filter to put all mailing list email into a separate folder, so it doesn't clutter up your email. Tom Barry also has had problems sometimes getting dTV running under Windows 2000 - sometimes it would work, and sometimes it would not work. Does your change below, fix this? Michael Eskin wrote: > > Hi Mark, Steven, > > I've started doing some development work with the new release and I have a > fix to a problem with the VxD device enumeration and detection. It doesn't > work right if you've had several other boards installed in your system at > some point because Win98 leaves old entries in the ENUM/PCI registry area. > When you try and do your device detection the current VxD uses the first > match of the device ID in the registry, which may not coorespond to the > installed device. I've got a fix for the VxD to continue enumerating all > devices until if finds a match. I'll figure out how to get it in the project > this afternoon. I've joined the sourceforge site, just need to figure out > the web based project management. > > If either of you are interested in coming to work at Conexant in San Diego, > I'd like to extend an offer to fly you out for an interview. We have several > positions for software engineers in our video products groups and are > actively recruiting. > > Cheers and best regards, > > Michael Eskin > Conexant Systems -- _______________________________________________________________________ ____ Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@... http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W "A friend is someone who will be there without asking anything of you. A friend is someone you know that knows you, and accepts you." _______________________________________________________________________ ```

 [Deinterlace-discuss] Michael/Conexant was here ! From: Yvon Quere - 2000-11-02 07:56 ```On Tue, 31 Oct 2000, Michael Eskin wrote: >Hi Mark, Steven, Hi Michael >I've started doing some development work with the new release and I have Great news. Your presence is greatly appreciated and motivating for all people working on this. Thanks to Conexant and to you for being here ! >a fix to a problem with the VxD device enumeration and detection. It Good news, that's a very good start :-) I'm taking the risk of sounding selfish but I'd really like to know more about the whole story of agc and macrovision. Beside dTV, I'd like to know in which way a grab chipset manufacturer "pledges allegiance" to the macrovision copy protection system. Vcr manufacturers are doing so by making their machine reluctant to record things with such signal in it but what about a chipset ? Again, thanks for giving a hand ! Yvon -- Yvon Quere ---------------------------------- |\ _,,,--,,_ ,) - yvon.quere@... /,`.-'`' -, ;-;;' |,4- ) )-,_ ) /\ 01.69.63.17.83 -----------------------------'---''(_/--' (_/-' ------ ```