Randomize, Mutate buttons

[Creator20Guest]

Two buttons that randomize and mutates the values of every single function in the program (example: Composite Noise intensity, Head Switching height, Tracking Noise height, Sharpen intensity, Edge wave speed, etc...).
Take this examples below:

• Randomize is just that... Sets all the function values to a random value...

Example: Snow = 0.00025, to 100 with randomize function

• Mutate is something different, with the Mutate button automatically changes all the values by a low range

Example: Snow = 0.15, to 0.50 with mutate function. Or 0.15 to 0.050

I don't know if someone understood my point, but I wish in some future we get these buttons, thanks.

[notdigidani]

this is actually a very interesting idea, i hope she adds this too

[abcnorio]

You can write a script (R, python) by reading the json config, add max/min values, and draw samples from a special type of random distribution (norm, t, beta, ...) and therefor create a lot of config sets. Just random values can be achieved by this as well but may not hit the point due to the sheer amount of variance by using complete randomness. It depends on what you need. IF e.g. you want to prepare images for some AI/ML fine-tuning, you need variance but not too much. So it makes sense to put the mass of the prob distribution on a certain value (taken e.g. from a profile like SVHS/betacam/VHS/...) and add a +/- tolerance (multiplier of the sd of the distribution), and draw accordingly. If you use a skewed distribution this differs as well (then maybe use a beta distribution). You can set a seed for exact reproduction. With the cli version of ntsc-rs you can do this as a batch mode even without any embedding into the software ie. it can be fully scripted. Using ffmpeg you can apply this even on single frames/ images with a certain overhead as the cli version cannot do single frames output at the moment, it gives out mp4/mkv.

[notdigidani]

but it would be cool if it was actually implemented inside the program itself

[abcnorio]

Yes understandable. Almost finished it as a script (test runs were just fine). However, doing some tests with complete randomness this makes only partially sense (and can be achieved rather easily - you just create the possible sample space for each parameter and draw from it)). I "struggle" more with using a profile as a base and slightly change it. For each parameter one needs another - at best manually and visually "confirmed-adjusted" - config. Biggest challenge is to have a good guess about the underlying model one should use. For the linear parameters e.g. a truncated model seems to work, for the log() parameters at the moment a beta dist is used and estimated via MLE (via R package) from certain "expert's assumptions", etc. Those values enter as probs the sampling procedure. If you use a profile it does not make sense to randomize every parameter, esp. the logical T/F ones. All in all a sheet is used as a base and then the script works with that. The script is written in a way that one can easily add another prob model if the ones suit not. For me the script works very well because the cli version is much more important due to a lot of images to slightly tweak.

[abcnorio]

Some notes now from direct experience with randomization:

• Certain parameters esp. the categorical ones should not be changed if you want to maintain some kind of profile like SVHS/ VHS/ betacam/ ..., the changes are too much and look ugly and unnatural unless you want just some "random fun". Esp. changes for "scanline phase shift" and such parameters create trouble. So added a switch to drop changes if a marker is set.
• it requires a lot of manual work with visual inspection using the GUI to define tolerance limits (lower, upper bounds) to maintain a profile. It's a longer trial-and-error run, not done in some minutes or half an hour.
• It makes sense to create output for single images (with multiple variations per image) as well as for different images - no video yet implemented as this is not relevant for me now.
• Creating a sufficient sample space for each parameter once allows to draw from that for each variation trial. The minimal amount of time required to define and apply that sample space is worth the invested - short - time.
• Pure random draws are easy to implement (just sample randomly from sample space) like drawing from an urn.
• Prob dists - a truncated normal (for some scales) and a beta dist (for the log scales) seem to work fine (although some pros from statistics may shake their head, but we do not do too serious statistics here, we just want some randomness within certain limits that we understand) - for those interested read about "creating a Bayesian prior from expert's statements and insights and turn this inot a numerical statement along a prob dist". That's a good starting point for our goals here.
• Scripting the cli version with intermediate output to mp4 with 00:00:00.10 and e.g. 25 fps works fine and takes more time, but is just ok. Output is a png (extracted from mp4 via ffmpeg), quality is pushed to 50 for h264 (still have the problem with ffv1 not working).
• it's a pure R script (enhanced by some additional R packages), called directly from bash with Rscript env and requires some helpful bash commands like ffmpeg, realpath, etc. Thus, the whole thing is fully bash-capable.

In sum, proof of concept - works and does the job quite well.

@valadaptive -> Thanks for the cli version of ntsc-rs - it's a real gem!