MCTemporalDenoise [v1.4.20 - Update 2010/07/02]

[Boulder]

I call them biased results. Personally I try to keep, even while denoising, the final result as close as possible to original one. I degrain simply because it's a side effect of poor technology, not an artistic choice. There are exceptions, where grain is put in postproduction to deliberately give that effect. Anyway, when I look with my eyes at the world, I see no grain, that's why I remove it.

Then why do you filter your videos to death with MDegrain averaging over almost ten frames? Do you honestly believe that you remove only noise and no detail while smoothing everything that looks like noise?

I'd like to see a before-after sample, I think I already asked for one when we discussed MDegrain. It would be quite interesting to see how it really looks.

[tormento]

I just recall this discussion from 2004
IMHO every kind of filter altering image "ruins" semiframes and makes deinterlacing less accurate, at least from digital source. If the source is analogue, i.e. tapes and whatsoever, every case must be considered separately.

[tormento]

Then why do you filter your videos to death with MDegrain averaging over almost ten frames?
Because it's not tr that flattens down details but thsad. As I already told in another thread, the more frames you have to predict movement vectors, the more precise will be the denoising because you will correctly tracking objects.

You can clearly see it on fast moving objects: lower tr gives bad results while higher forms a more detailed image.

[hello_hello]

Not true. It can produce multiple times the same image but the image itself is not the correct one for multiple reasons, such as: which hardware you are using to decode, which renderer you are using to show, etc. The only, theoretically correct image, is a software produced one, unless you accept some compromises in chroma, fast decoding routines and so on. The purpose of a player is to keep a constant flow of motion, not to produce the perfect image. The fact itself you consider a player a "perfectly reliable" source speaks for itself.

And the method you use to view video all suffer from the same problems. Do you think VDM2 or whatever you're using magically reproduces the image without using a renderer?
Open a slow script with MPC-HC and watch it give up when it's not being fed frames fast enough. It drops frames when they don't arrive quickly enough so your claim is nonsense, and I always compare frames by navigating directly to a frame number while MPC-HC is paused so it'll wait for the frame even if it takes a minute.
The fact that I consider MPC-HC perfectly reliable only reflects how reliable it is.

All you're doing now is trying to avoid explaining why your method of de-interlacing and denoising my sample doesn't look as good as QTGMC by changing the subject.

Not true. Your screenshots speak for themselves.

FFS. I told you why I resize to square pixel dimensions. I didn't just invent some random SAR to base the resizing on.

Errr.... which ones? Moreover FFMpeg has the capability to report the correct SAR for video streams, it doesn't "default" anything. Recently I had to convert some hundreds of DVDs to mkv and every single one had its own SAR, such as 64:45 (the majority), 10:11 and even odder ones. FFmpeg reported each one of them correctly.

Yep, it probably defaults to an exact 16:9 aspect ratio for 16:9 DVDs and to an mpeg4 DAR for 4:3 DVDs because they're most likely to be correct. It still doesn't mean the SAR is saved to the video stream, it just means they're the ffmpeg default guesses for 16:9 and 4:3 DVDs.

Please don't reply anymore with what you believe, please reply with tecnically consistent proven facts.

You'll be in for a shock when you finally realise you're the one making bad assumptions.

P.S: You uploaded jpg images. You know that jpeg is a lossy format, don't you?

Do you think saving the screenshots as jpegs somehow distorts their aspect ratios?

[tormento]

Do you think saving the screenshots as jpegs somehow distorts their aspect ratios?
Didn’t all started as image quality comparison?

[Boulder]

I just did a very quick test on a static scene with my script, using 1 or 3 frames for MAnalyse and MDegrain. Even at low sad (thsad=100), the 3-frame method produces a significantly blurrier result and removes detail as well.
Once again the problem is recognizing what is detail and what is noise. The object to track may not be that big, for example features such as pores or small patches of color on one's skin are quite hard to keep if you really start denoising.

[tormento]

I just did a very quick test on a static scene with my script, using 1 or 3 frames for MAnalyse and MDegrain. Even at low sad (thsad=100), the 3-frame method produces a significantly blurrier result and removes detail as well.

Try with tr=9. :)

[Sharc]

[QUOTE=tormento;1908534
GSpot gives an idea of those, even requiring some understanding: i.e. on a 64:45 SAR DVD, it reports a SAR of 5:4, PAR of 1.422 (64:45) and DAR of 16;9.
[/QUOTE]

Yes, SAR and PAR are independent of cropping. I never heard of a '64:45 SAR DVD' though. DVD did not even specify the SAR.
Tools report a lot, and not always correct. The PAR (Pixel Aspect Ratio) or SAR (Sample Aspect Ratio) of a given source cannot be calculated. If it is not specified in the header or in the metadata one has to guess it using the "circle test".
Far off topic, no more arguing ;)

[hello_hello]

Didn’t all started as image quality comparison?

And I uploaded those original screenshots as PNG, but all you've done is find excuses to avoid discussing why the QTGMC version looks better. You're free to download my de-interlacing sample and upload screenshots that show mine were somehow misleading.

[hello_hello]

https://forum.doom9.org/showthread.php?p=1058927#post1058927

"Those three tables contain all the numbers you will ever need for any DVD source. Which table you use is mainly a matter of personal preference because you have virtually no chance to find out the real DVD PAR (i.e. the PAR used in the mastering process) for sure. It might be generic, it might be ITU. Black bars left/right are an indication for ITU, but you can’t be certain. Also the absence of bars might mean generic, but it’s no proof either."

[Sharc]

Brother John said it all :)

[hello_hello]

I'm not a musician, but the drum on the ground (bass drum?) - I think it's usually "circular" .

If you use that as a "circular reference" :D , then that lower image is too wide

Your brain can deceive you. It tends to make things round when experience tells it they should be. The one that appears round is possibly the one you look at first because your brain makes it round and therefore thinks the other one isn't. Possibly.
I thought the mpeg4 aspect ratio looked more round, and the studs on his strap look more natural, but here's some better screenshots with the original frame in case someone else wants to draw circles. Switch between the images I drew circles over and the circles appear to change, yet they're both perfectly round. I'm still on the side of it being mpeg4, but someone else may be able to draw circles in a slightly different place and have the result look different, because the difference isn't huge. It's hard to find a perfectly straight-on, very defined circle to use as a reference, and as there's no easily discernable "centre" for this one, it's hard to centre the drawn circles exactly. If I find a better shot I'll upload it.

Untouched frame:

https://i.postimg.cc/yJ1ffv6N/original-frame.png (https://postimg.cc/yJ1ffv6N)

16:9 resizing:

https://i.postimg.cc/q6qV9pkz/16-9.png (https://postimg.cc/q6qV9pkz)

20:11 resizing:

https://i.postimg.cc/0rb4RWYM/20-11.png (https://postimg.cc/0rb4RWYM)

Uploaded as png so tormento won't claim jpegs distorted the aspect ratio.

[tormento]

"Those three tables contain all the numbers you will ever need for any DVD source.
That is complete bullshit. Can you read PAR on those tables?

SAR and PAR are definitely not the same thing. I can present you DVD with SAR of 11:9, such as "Super size me" if I recall well.

I will stop replying to you, as your beliefs resembles more a religion than a technical POV.

[hello_hello]

That is complete bullshit. Can you read PAR on those tables?

SAR and PAR are definitely not the same thing. I can present you DVD with SAR of 11:9, such as "Super size me" if I recall well.

I will stop replying to you, as your beliefs resembles more a religion than a technical POV.

Show me the DVD please. Can you upload a sample? You're just using a new excuse to put your fingers in your ears.

PAR and SAR are exactly the same thing, but digital video doesn't have pixels as such, it has samples, so at some stage the term was changed. If you think they're not the same thing, it'd be a good idea if you refrained from replying further.

One of those tables refers to your SAR of 64:45 which would give you an exact 16:9 image. Do you think the maths changes because the table refers to it as a PAR instead? Seriously, how do you think that works?

DVDs can only have two storage aspect ratios (with the exception of very rare 4:3 DVDs with a width of 704).

720 / 576 = 1.25 for PAL
720 / 480 = 1.5 for NTSC

[Boulder]

Try with tr=9. :)

Unfortunately still the same results. The details are being removed because thsad needs to be at least 200 if you want to start removing noise (bad quality Blu-ray source; The Walking Dead, season 5). That is why I do very light denoising myself, because that heavy-duty approach leads only to a plastic look.
In my own encodes, I subtract the result from the original and check if it shows something else than noise. Easy to tweak thsad and limit for changing pixel value.

[hello_hello]

I can't see 11:9 in MeGUI's list of standard generic and mpeg4 SARs. Is it some special SAR? According to the table I linked to it's not an ITU SAR either.

https://i.postimg.cc/PLtvJbDG/ME1.gif (https://postimg.cc/PLtvJbDG) https://i.postimg.cc/crnnbLWz/ME2.gif (https://postimg.cc/crnnbLWz)

[Sharc]

SAR and PAR are definitely not the same thing….

PAR and SAR are exactly the same thing….


Are we talking about the same SAR here at all?

PAR = Pixel Aspect Ratio
SAR = Sample Aspect Ratio
or:
SAR = Storage Aspect Ratio?

The 3 letters are ambiguous.

[hello_hello]

As close to another straight on shot as I could find. Not quite (I don't think), so maybe the circle should be stretched horizontally a little due to aspect. It's hard to tell. My money is still on mpeg4 rather than generic.

Original Frame:

https://i.postimg.cc/gXpG2b2c/original.jpg (https://postimg.cc/gXpG2b2c)

Generic:

https://i.postimg.cc/K4FYZB17/generic.jpg (https://postimg.cc/K4FYZB17)

Mpeg4:

https://i.postimg.cc/rdx8TwcY/mpeg4.jpg (https://postimg.cc/rdx8TwcY)

[hello_hello]

Are we talking about the same SAR here at all?

PAR = Pixel Aspect Ratio
SAR = Sample Aspect Ratio
or:
SAR = Storage Aspect Ratio?

The 3 letters are ambiguous.

Hopefully tormento isn't that confused, given he's been referring to a 64:45 SAR for the video I uploaded. It can only be sample AR. We'll have to wait to find out why it's not the same thing as pixel AR.

Edit: Maybe I'm wrong and he is that confused. 11:9 is the storage AR for a PAL DVD if you ignore 8 pixels each side, giving 704x576 a 16:9 DAR.

704 / 576 = 1.222222
11 / 9 = 1.222222

[Sharc]

I can present you DVD with SAR of 11:9, such as "Super size me" if I recall well.

Very interesting.
Isn't the 11:9 =1.2222... some tool approximation for either the standard
40:33 = 1.2121.... mpeg-4 PAR for 16:9 NTSC, or
155200:127953 = 1.2129.... ITU PAR for 16:9 NTSC DVD?

Edit:
Or yep, you mean indeed the STORAGE ASPECT RATIO of 704/576=11:9=1.2222.... In this case I am pretty sure that the SAMPLE ASPECT RATIO for this DVD is according to ITU PAL DVD, i.e. 4600:3159 for 16:9 or 1150:1053 for 4:3.
As I said, SAR is not equal SAR, and we should be clear what we mean beforehand :p

[tormento]

Isn't the 11:9 =1.2222... some tool approximation for either the standard
Not all DVD are anamorphically encoded and not all are 16:9.

Likewise to what happened to panascope movies, they started to use anamorph to optimize PAL/NTSC resolution (that is 720 pixel by 576 by standard, with an aspect ratio of 4:3 considering what is really displayed on screen, i.e. not teletext or overscan) to avoid wasting bandwidth otherwise occupied by horizontal black bars.

Thus doing, they allow to see non 4:3 DVDs with bit better quality on higher resolution screens than SD when the player is resizing them.

Resizing to lower resolution instead of anamorphically encoding is really stupid. You waste all that video material you could benefit from on HD screens.

[tormento]

Are we talking about the same SAR here at all?
SAR = Storage Aspect Ratio and it can't be PAR at all, as they are defined as:

SAR × PAR = DAR,

where PAR = Pixel Aspect Ratio (>=1) and DAR = Display Aspect Ratio (4:3, 16:9, etc)

On traditional, i.e. 1:1 square pixels, PAR=1 and SAR=DAR, not PAR.

In anamorphic video, PAR > 1.

In that case, you have to modify SAR in the encoder to have the correct final result.

[Sharc]

In h.264, h.265 standards SAR is defined as Sample Aspect Ratio which is the same as Pixel Aspect Ratio for mpeg-1 and mpeg-2.
This ambiguity has unfortunately caused a lot of confusion.
Also, the --sar parameter in the x264 encoder stands for Sample Aspect Ratio.

I have no idea why the standard bodies changed from PAR to SAR. Maybe because a pixel can't have an 'aspect ratio' in the strict sense.

[hello_hello]

Not all DVD are anamorphically encoded and not all are 16:9.

ALL DVDs are anamorphic, however the "industry" referred to 16:9 DVDs as anamorphic and 4:3 DVDs as full-screen, harking back to the days of 4:3 CRTs. I've never met a DVD with a 1:1 sample/pixel aspect ratio. If any other sample/pixel aspect ratio means the video is anamorphic, all DVDs are anamorphic.

Resizing to lower resolution instead of anamorphically encoding is really stupid. You waste all that video material you could benefit from on HD screens.

That's why I resized my encodes by simply stretching the width, rather than reducing the height for the correct DAR. Even you should realise that means I've increased the number of pixels, not reduced them, while obviously not increasing the amount of picture detail, but also while not reducing it.
If you're referring to the table of SAR's/PAR's I linked to and the example given for resizing down, did you also notice it was written in 2007 when people were still commonly using Xvid and/or burning their encodes to CD before watching the video on a CRT?

You are however, wrong. Resolution isn't everything. It's a fairly accepted fact that 1080i has roughly the same spacial resolution as 720p, but a higher temporal resolution, therefore you can de-interlace 1080i to 50/59.94fps and resize to 720p without a noticeable loss of detail. Likewise for an interlaced PAL DVD, you can often de-interlace to 50fps and resize down. For interlaced 4:3 PAL DVDs, I often deinterlace with QTGMC and crop and downscale to 640x480, and the encoded version looks at least as detailed, with better deinterlacing than a player would be capable of.

Progressive video is a different story. If a PAL DVD contains 576p worth of detail, you'll obviously lose some of it when resizing down, but that's often not the case. I've regularly resized PAL 16:9 DVDs to 960x540 after cropping, and it rarely loses detail, but with a bit of filtering, the encode can appear sharper and more detailed than the original at 1024x576. For example:

DVD:
https://i.postimg.cc/GTjWg0ct/resized-to-square-pixels.jpg (https://postimg.cc/GTjWg0ct)

960x540 encode:
https://i.postimg.cc/mzWZ0sGy/downsized-and-filtered.jpg (https://postimg.cc/mzWZ0sGy)

I guess my generic vs mpeg4 aspect ratio screenshots are being ignored too now?

[hello_hello]

SAR = Storage Aspect Ratio and it can't be PAR at all, as they are defined as:

SAR × PAR = DAR,

Riddle me this, do you specify --sar 64:45 in the x264 command line or do you use --par 64:45?

You'd use the former because x264 refers to sample aspect ratio, not pixel aspect ratio, but they're the same thing.

http://www.chaneru.com/Roku/HLS/X264_Settings.htm#sar

sar
Default: Not Set
Specifies the input video's Sample Aspect Ratio (SAR) to be used by the encoder in width:height. This in conjunction with frame dimensions can be used to encode an anamorphic output by determining the Display Aspect Ratio (DAR) via the formula: DAR = SAR x width/height.

where PAR = Pixel Aspect Ratio (>=1) and DAR = Display Aspect Ratio (4:3, 16:9, etc)

Not to be picky, but 4:3 NTSC DVDs have a pixel/sample aspect ratio of less than 1:1.
8:9 for an exact 4:3 DAR.
10:11 for an mpeg4 DAR.

[tormento]

This ambiguity has unfortunately caused a lot of confusion.
Unfortunately you are right.

In x264 standards DAR = SAR x width/height, when instead, according to standards, SAR = width/height, i.e. x264 SAR = standards PAR...

[Stereodude]

Is there nothing you guys won't argue about? And is this the right thread for the current discussion?

[hello_hello]

Unfortunately you are right.

In x264 standards DAR = SAR x width/height, when instead, according to standards, SAR = width/height, i.e. x264 SAR = standards PAR...

I guess that means you were also wrong when you claimed my beliefs were based more on religion than technical fact, although I suspect your fingers are firmly wedged in your ears now.

[poisondeathray]

Your brain can deceive you. It tends to make things round when experience tells it they should be. The one that appears round is possibly the one you look at first because your brain makes it round and therefore thinks the other one isn't. Possibly.
I thought the mpeg4 aspect ratio looked more round, and the studs on his strap look more natural, but here's some better screenshots with the original frame in case someone else wants to draw circles. Switch between the images I drew circles over and the circles appear to change, yet they're both perfectly round. I'm still on the side of it being mpeg4, but someone else may be able to draw circles in a slightly different place and have the result look different, because the difference isn't huge. It's hard to find a perfectly straight-on, very defined circle to use as a reference, and as there's no easily discernable "centre" for this one, it's hard to centre the drawn circles exactly. If I find a better shot I'll upload it.



When there is pillarboxing, usually it's a good assumption that they are using ITU aspect ratios. I'm guilty of this too. But a lot can go wrong between acquistion and dvd distribution.

These are "perfect" circles in a graphics program. Not hand drawn. You can fiddle with it, subpixel shift up/down, fractional scaling, etc... but the circles themselves are perfect. I find it better to use semi transparent overlays. It's pretty clear that 1024x576 is too narrow, 1048x576 is a closer match. Assuming the ?bass drum is supposed to be circular

1_1024x576
https://i.postimg.cc/mDG2yMSx/1-1024x576-00000.png

1_1048x576
https://i.postimg.cc/9X7sjKVB/1-1048x576-00000.png

2_1024x576
https://i.postimg.cc/2yrQM1rM/2-1024x576-00000.png

2_1048x576
https://i.postimg.cc/qvh3ms2g/2-1048x576-00000.png

[hello_hello]

poisondeathray,
The program I use for drawing circles (Irfanview) is primarily an image viewer with some paint-like drawing abilities via a plugin. I don't think it can draw transparent overlays (just solid color), but I should find a program that does as it appears to be a better way to do it if you can find perfect circles in the picture. Is there a free, easy to use program you'd recommend?

Sometimes I see a straight on shot of a CRT or LCD display and draw rectangles to measure the aspect ratio.
A fun fact: The aspect ratio of the CRT TV displaying the opening credits at the beginning of The Simpsons (at least the early 4:3 episodes) has an aspect ratio of roughly 1.275 instead of 4:3. I know it's just a drawing but I had to try something.... :)

At least I know my brain didn't let me down for this one (it has before) and it does have an mpeg4/ITU DAR.

Cheers.

Edit: For tormento's benefit that means the PAR/SAR would be 16:11 if you go with an mpeg4 20:11 DAR, giving you display dimensions of 1047.27 x 576, or you can use the harder to remember ITU PAR/SAR of 4600/3159, giving you display dimensions of 1048.43 x 576 (as they're virtually the same), rather than the generic PAR/SAR of 64:45, which gives you exact 16:9 dimensions of 1024 x 576.

The benefit of using the mpeg4 display aspect ratios, rather than ITU, is there's only two of them, much like the generic 16:9 and 4:3 display aspect ratios. 20:11 for both "16/9" PAL and NTSC, or 15:11 for "4/3" PAL and NTSC. The 20:11 and 15:11 display aspect ratios will give you the mpeg4 PARs/SARs listed in the table I linked to, if you calculate them based on the PAL and NTSC storage dimensions.

576 × 20/11 / 720 = 1.4545 = 16:11 (SAR/PAR)
480 × 20/11 / 720 = 1.2121 = 40:33 (SAR/PAR)

576 × 15/11 / 720 = 1.0909 = 12:11 (SAR/PAR)
480 × 15/11 / 720 = 0.9090 = 10:11 (SAR/PAR)

And if you crop any of the above to a width of 704, you end up with exactly 16:9 or exactly 4:3.

As you've apparently discovered, ffmpeg defaults to a generic SAR/PAR for 16:9 DVDs and an mpeg4 SAR/PAR for 4:3 DVDs. In my opinion that will mostly be correct for newer 16:9 DVDs, and almost always correct for 4:3 DVDs, but they can be either.

I suspect, but can't really prove, that all BBC 16:9 DVDs are an exception to the rule and always have an mpeg4/ITU DAR.

[poisondeathray]

poisondeathray,
The program I use for drawing circles (Irfanview) is primarily an image viewer with some paint-like drawing abilities via a plugin. I don't think it can draw transparent overlays (just solid color), but I should find a program that does as it appears to be a better way to do it if you can find perfect circles in the picture. Is there a free, easy to use program you'd recommend?


Not sure...

I'm don't really use irfanview; but it should be possible in gimp or any image editor program. You can layer on some colored layer at some % opacity (or transparency, same thing, different programs use different terms). You can constrain an elliptical mask to a perfect circle by using hot keys, such as CTRL+SHIFT, or something like that. Then fiddle around with the scale, positioning etc.. It's nicer to have subpixel positioning or scaling control but not all programs have it

I use AE for this. It's overkill for this, but I'm more comfortable with the interface. Hitfilm Express is a free version or Hitfilm, and basically an AE clone, I assume it can do the same as easily, not sure



I suspect, but can't really prove, that all BBC 16:9 DVDs are an exception to the rule and always have an mpeg4/ITU DAR.

BBC uses 702 width for their AR calculation. For them, the 16:9 square pixel equivalent is 1050x576, and 4:3 788x576 . I mirrored their old guideline somewhere before. Something like "BBC A Guide To Picture Size" . If you can't find it on google , I can look for it if you're really interested. But many people round to 704 in practice.

[hello_hello]

I'm don't really use irfanview; but it should be possible in gimp or any image editor program. You can layer on some colored layer at some % opacity (or transparency, same thing, different programs use different terms). You can constrain an elliptical mask to a perfect circle by using hot keys, such as CTRL+SHIFT, or something like that. Then fiddle around with the scale, positioning etc.. It's nicer to have subpixel positioning or scaling control but not all programs have it

I use AE for this. It's overkill for this, but I'm more comfortable with the interface. Hitfilm Express is a free version or Hitfilm, and basically an AE clone, I assume it can do the same as easily, not sure

The program I use lets you draw perfect circles via CTRL+SHift too, but there's no repositioning them later. I'll check out those programs. Thinking about it, there's a free program called Paint.Net or something like that, which does lots of cool things. I'll see if I can find it too. I still prefer to be XP compatible at the moment though. :)

BBC uses 702 width for their AR calculation. For them, the 16:9 square pixel equivalent is 1050x576, and 4:3 788x576 . I mirrored their old guideline somewhere before. Something like "BBC A Guide To Picture Size" . If you can't find it on google , I can look for it if you're really interested. But many people round to 704 in practice.

Now you mention it, I do remember that, but I think it was for broadcast purposes so I wasn't necessarily sure that always transfers directly to their DVDs.
I'm pretty sure I decided the 16:9 BBC DVDs I have worked with (which is a small number) were mpeg4, so if they do use 702x576 or 1050x576 as 16:9 for DVDs, I was only off by a couple of pixels.

[StainlessS]

there's a free program called Paint.Net
Used to be free, at least donation/shareware now I think.

Also, dont think XP compatible anymore.

EDIT: Paint.NET.3.5.11.Install(LAST for XP).exe :- http://www.mediafire.com/file/g4b9b534vj40xtv/Paint.NET.3.5.11.Install%2528LAST_for_XP%2529.exe.7z/file

EDIT: Seems to be free according to WikiPedia + other sites,
but look here on M$ site & App Store(Win10 Pro/Home Only : £6.99):- https://www.microsoft.com/en-us/p/paintnet/9nbhcs1lx4r0?activetab=pivot:overviewtab
EDIT: Has free trial.

Was sure that this was developed at some university, M$ seems to have taken total ownership after the students developed it for them.

EDIT:

It started development as an undergraduate college senior design project mentored by Microsoft, and is now maintained and developed by Rick Brewster.
Originally intended as a free replacement for the Microsoft Paint software that comes with Windows, it has grown into a powerful yet simple image and
photo editor tool. It has been compared to other digital photo editing software packages such as Adobe® Photoshop®, Corel® Paint Shop Pro®,
Microsoft Photo Editor, and The GIMP.

If you buy Paint.NET in the Windows Store, you'll be supporting its development directly (normally we ask for a donation).
You will get the convenience of fast, easy installation onto all of your Windows devices along with fully automatic,
behind-the-scenes updates with all the newest features, improvements, and fixes.

EDIT: Wikipedia

Paint.net originated as a computer science senior design project during spring 2004 at Washington State University.
Version 1.0 consisted of 36,000 lines of code and was written in fifteen weeks.[4] In contrast, version 3.35 has approximately
162,000 lines of code. The paint.net project continued over the summer and into the autumn 2004 semester for both the
version 1.1 and 2.0 releases.

Development continues with one programmer who worked on previous versions of Paint.net while he was a student at WSU.
As of May 2006 the program had been downloaded at least 2 million times,[5] at a rate of about 180,000 per month.[6]

Initially, Paint.net was released under a modified version of the MIT License, with the exclusion of the installer, text,
and graphics.[7] It was completely open-source, but because breaches of license, all resource files (such as interface
text and icons) were released under a non-free Creative Commons license forbidding modification, and the installer was
made closed-source.[8] Version 3.36 was initially released as partial open-source, but Brewster later took down the
source code, citing problems with plagiarism. In version 3.5, paint.net became proprietary software.
Users are now prohibited from modifying it.[8][9]

Starting with version 4.0.18, paint.net is published in two editions: A classic edition remains freeware, similar to all other
versions since 3.5. Another edition, however, is published to Microsoft Store under a trialware license and is available to
purchase for US$7. According to the developer, this was done to enable the users to contribute to the development with
more convenience, even though the old avenue of donation was not closed.[10][11]
According to Wikipedia, requires Win7SP1 or above.

[hello_hello]

StainlessS,
Thanks for the link. I read the Wikipedia stuff and was just about to go hunting for version 3.5.11 when I read your post. I have it downloaded and installed. I've not played with layers much. I understand the principle, I'll just need to play around.
Cheers.

[hello_hello]

Something like "BBC A Guide To Picture Size".

Why did I look???

I recall reading about industry standard square pixels having a 767:768 aspect ratio, and here's a riddle I've never worked out. If you take the PAL "almost exact" ITU PAR's from Brother John's table and multiply them by 767/768 you get the exact Digital PARs for PAL, before they were fudged to 12:11 & 16:11. According to Wikipedia the exact PAL digital PARs should be 59:54 and 118:81.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Digital_video_processing

(128/117) × (767/768) = 59/54
(512/351) × (767/768) = 118/81

Applying the same to the almost exact ITU NTSC PARs doesn't result in a PAR I've ever seen mentioned and I've never understood why. Maybe it's just some mathematical co-incidence for PAL.

Anyway, I understood what I read regarding the BBC version of PARs but I don't understand where 1:1.094 comes from. Are widths of 788 and 1050 differently fudged versions of the exact digital PARs of 59:54 and 118:81??
BBC - Commissioning - A Guide to Picture Size.pdf (https://community.avid.com/cfs-filesystemfile.ashx/__key/CommunityServer.Components.PostAttachments/00.00.54.02.29/BBC-_2D00_-Commissioning-_2D00_-A-Guide-to-Picture-Size.pdf)

[StainlessS]

Never mind about whatever version of PAR, who cares if looks about right.

Now what about this McTemporalDenoise thing, any good ?

[poisondeathray]

@Hello_hello , read this for where the numbers come from and the assumptions behind it
https://en.wikipedia.org/wiki/Talk%3APixel_aspect_ratio#Can_sb._check_the_pixel_aspect_ratio_of_4:3_576i?

But, SS is right. Close is good enough. No more AR talk. There are 1000 page threads on several forums going into this

Back to MCTD

[hello_hello]

The MCTD chatter is so loud I can hear my pixels changing shape. :)

[real.finder]

first step, https://github.com/realfinder/AVS-Stuff/commit/bcfd0ef58836adee7148ffdc2b1b8f9e99940f3f

[real.finder]

ok, so now, let's try make MCTD great again! (with HBD) first is GradFun2DBmod (v1.5), GradFun2db (v1.0)

can those be replaced with f3kdb? I think this what vs port did

TTempsmooth (v0.9.4), need someone port back TTempsmooth from VS! I did said this before https://forum.doom9.org/showpost.php?p=1907953&postcount=28 same for EEDI2 (v0.9.2) (or maybe EEDI3 as new replacement) and SangNom/2 or mod but seems MeteorRain only did VagueDenoiser...

since I have virtual studio 2019 in an old laptop, is there any specific steps so I can do ports myself? or it's impossible for c++ n00b (almost zero knowledge and experience with c/c++)? :)

[Boulder]

since I have virtual studio 2019 in an old laptop, is there any specific steps so I can do ports myself? or it's impossible for c++ n00b (almost zero knowledge and experience with c/c++)? :)

I believe these cases are the ones where you either step onto the path to learn coding or stay out of it. So, probably not impossible but will surely require a whole lot of work along the way. Maybe HBD = here be dragons now :D

[tormento]

I believe these cases are the ones where you either step onto the path to learn coding or stay out of it. So, probably not impossible but will surely require a whole lot of work along the way. Maybe HBD = here be dragons now :D
Is there some guide to have Visual Studio compile sources from GIT? I saw some already have .vsproj but for the others?

[Boulder]

To compile in VS, you need a VS project which should be included with the sources if there is one available. Some plugins can be compiled using other tools, I think mainly GCC. Often you can get this information from the project page if it exists.
I've never created a project out of scratch myself (well, at least in 20 years IIRC) so I don't know any details. I've only used the existing project files provided by the authors. Maybe taking a look at one of the existing ones is useful regarding what is required to even start working on the project.

[real.finder]

so, no hope but waiting someone do it...

[Stereodude]

ok, so now, let's try make MCTD great again! (with HBD) first is GradFun2DBmod (v1.5), GradFun2db (v1.0)

can those be replaced with f3kdb? I think this what vs port did

TTempsmooth (v0.9.4), need someone port back TTempsmooth from VS! I did said this before https://forum.doom9.org/showpost.php?p=1907953&postcount=28 same for EEDI2 (v0.9.2) (or maybe EEDI3 as new replacement) and SangNom/2 or mod but seems MeteorRain only did VagueDenoiser...
I don't know if you can use EEDI3 in place of EEDI2. From the wiki (http://avisynth.nl/index.php/Eedi3): "eedi3 doesn't really have anything to do with eedi2 aside from doing edge-directed interpolation (they use different techniques)."

That doesn't sound like it's just a tweaked and improved version that can be substituted. However, I admit I've never really looked at what MCTD does internally, so maybe it still can.

[real.finder]

ok, so now, let's try make MCTD great again! (with HBD) first is GradFun2DBmod (v1.5), GradFun2db (v1.0)

can those be replaced with f3kdb? I think this what vs port did


ok, so I did read what VS did, it don't has any enhance settings so the output of both already different, I will care for GradFun2DBmod (v1.5), GradFun2db (v1.0) later (since other plugins is still missing)

[tormento]

What are the missing x64 HDB filters and avsi right now to have a modernized MCTemporalDenoise?

And remember they must have newer AVS+ header ;)

[kedautinh12]

ok, so now, let's try make MCTD great again! (with HBD) first is GradFun2DBmod (v1.5), GradFun2db (v1.0)

can those be replaced with f3kdb? I think this what vs port did

TTempsmooth (v0.9.4), need someone port back TTempsmooth from VS! I did said this before https://forum.doom9.org/showpost.php?p=1907953&postcount=28 same for EEDI2 (v0.9.2) (or maybe EEDI3 as new replacement) and SangNom/2 or mod but seems MeteorRain only did VagueDenoiser...

since I have virtual studio 2019 in an old laptop, is there any specific steps so I can do ports myself? or it's impossible for c++ n00b (almost zero knowledge and experience with c/c++)? :)

Can replaced with gradfun3mod??
https://pastebin.com/JtWfSQ84
Edited
AviSynth-vsTTempSmooth
https://github.com/Asd-g/AviSynth-vsTTempSmooth
AviSynth-SangNom2
https://github.com/Asd-g/AviSynth-SangNom2

[real.finder]

Can replaced with gradfun3mod??
https://pastebin.com/JtWfSQ84

not this scripts again! https://forum.doom9.org/search.php?searchid=8730330 and it's a big no

Edited
AviSynth-vsTTempSmooth
https://github.com/Asd-g/AviSynth-vsTTempSmooth
AviSynth-SangNom2
https://github.com/Asd-g/AviSynth-SangNom2

already know about them :) EEDI2 and EEDI3 still missing

[real.finder]

test update https://github.com/realfinder/AVS-Stuff/raw/Community/avs%202.5%20and%20up/MCTemporalDenoise.avsi it wont use enhance for HBD by default, so it will work with HBD now

I will try some tests later with GradFun2DBmod and GradFun2db vs f3kdb to replace GradFun2db (but enhance for HBD will stay false by default)