Artifacts in Anime/Toon Footage

[Mister Hatt]

Word, that is indeed noise and not grain. People should word their posts correctly.

[post-it]

Word, that is indeed noise and not grain.
People should word their posts correctly.

.. An Example of Picture(s) should be posted .. showing what each article is being talked about.
.. it is a simple way to narrow-down where the problem might be

.. just an opinion

P.S. .. words fail too many times; You already know that from my transliterations on this board.
[ and yeah, it might be a little 1960'ish to do things with pictures but; everyone knew what we
were talking about back then .. today, people HAVE TO ASK, "know what I mean?" while they themselves
are trying to explain what THEY are trying to say: I don't like it but, the medium we're call communication
seems to be breaking-down from Improperly Identifiable Wordings. Even the 800 AD Church's understood
that Pictures could Identify what the commoners could not pronounce. ]

[Mister Hatt]

I've explained it often enough. Grain is of a uniform size and only impacts the luma channel. It is usually constant but sometimes changes across frames. Noise is uneven in size, often has coloured tints like purple, green, and red, and is often quite blocky. They are easy to tell apart. Dirt is a type of small eneven noise on fine edges, like the points of hair. It usually sits in the luma channel though. Anything else?

[post-it]

.. nope; that's as direct as possible. 'me need-um a dirt remover!

^_^ .. THx

[mirkosp]

I've explained it often enough. Grain is of a uniform size and only impacts the luma channel. It is usually constant but sometimes changes across frames. Noise is uneven in size, often has coloured tints like purple, green, and red, and is often quite blocky. They are easy to tell apart. Dirt is a type of small eneven noise on fine edges, like the points of hair. It usually sits in the luma channel though. Anything else?

Scratches, which happen in old footage, or are used these days as an "old looking" effect.

[Mister Hatt]

Film clumps and scratches are obvious as all hell though :V

[Anno-san]

What does everyone find so great about ZarX264GUI? MeGUI is much more customizable and powerful imo.

[Qyot27]

What does everyone find so great about ZarX264GUI? MeGUI is much more customizable and powerful imo.

That's sort of the point - Zarx264gui is meant as a simple transcoder for users that are intimidated by/complained about MeGUI's complexity (or at least it started out that way). It also tended to stay closer to x264's settings parity while MeGUI languished in development hell for months and got outpaced by a metric assload of x264's options.

I don't know where MeGUI's current parity with x264 is, as I think it was picked up again a couple times. But by that point I'd pretty much eschewed GUI solutions entirely, only using them as a springboard for CLI settings (and even that got minimized by the introduction of the preset/tune system in x264's CLI, although I do some preset overrides).

[mirkosp]

What does everyone find so great about ZarX264GUI? MeGUI is much more customizable and powerful imo.

It uses JEEB's x264. And if you know what you're doing you can customize it completely all the same. Considering that using x264 directly from command line is faster than using it from any gui, most encoders actually don't use either, so GUIs end up being for people that just know only in part how to encode, which means that in reality having a simple gui with just the options you really need to tweak instead of leaving something in the wrong hands is better.

EDIT: Heh, Qyot was faster.

[Qyot27]

I should probably also make it clear that I do think there's essentially three types of options in apps like x264, when considering GUI design:
A) options you should or must alter
B) options that are a matter of preference on whether to alter
C) options you shouldn't alter (which are only used by those who really know what they're doing, and which are probably at their defaults for an extremely good reason, thus altering them isn't recommended no matter who you are)

A GUI should provide access to A and B, but not C. The aid of a GUI is to make it easier to customize A and B, while leaving C alone so you don't screw yourself over. To frame this in light of Zarx264gui, MeGUI, and x264's CLI, Zarx264gui probably lies between A and B (some B options exposed, but not all), MeGUI is probably firmly in the B area or between B and C. x264's CLI is in the A, B, and C camps depending on how you configure it (preset/tune is definitely A, preset overrides can be on B or C level).