>>https://8kun.top/qresearch/res/10600146.html#10600492 PB/LB

That is a good start, but we need to have a random way to change images, that changes them in a random way each time, otherwise the detection models can just be updated to the new static picture just like they did with the original.

Sure we have more time with black corners, but as eluded to this is going to be a game of cat and mouse, if we can make something that changes images in a non predictable way then they are going to have to decide how many false positives they want to auto-block.

I know it's ugly right now, but it does the job, go have a look at 8kun ImageMangler 0.0.1 https://pastebin.com/GcWnrgf7

Let me know what does and does not work. I am thinking that next update we will want is logic to determine if it is a corner slice, and if so to make heavier changes to that slice, random border noise/colour changes between each slice, random colour and offset changes to each slice, maybe logic around the res and best density and other mangler variables set based on res.

I live lurking here, the more adoption and feedback the more I will contribute. I am a generalist not a coder, if anyone at any time wants to make it into a proper modular structure you are more than welcome, otherwise I see that kind of work as a waste of time now.

If I ghost after this post (I wanna break now) but this is useful enough, BAKER please update the Other Tools section with this entry near Bakertools 0.7.3 and I will look out for feedback when I return.

>>10601457

Its also possible I was focused on getting the code out and testing feedback, again didn't want to waste time finding the perfect thing to link it. It worked. Also I updated 0.7.3. Fish away.

>>10601498

Agreed, hence my approach

>>10601345

>>10601516

Here's some freebies, go nuts. There are params you can change in the script, but if you don't trust it here are some outputs. Lemme know how they go.

>>10601545

Hence my approach of an easy to use tool to mangle the images, we use the same sauce like we normally do, as master proof if you will, then mangle it locally, resulting in a different variation each time.

>>10601549

Hence my approach, the picture frame is harder if it is harder to frame what you are looking for. Taking this approach their compute costs go through the roof, their iteration cycles slow the fuck down (the time it takes before they can react to our methods) or they start blocking the crap outta everyone and their dog's pictures.

>>10601567

Finally some traction. Ok now I can go take a proper break. Here are some more freebies with more sectors and more variability on randomness

>>10601581

Eagerly awaiting your code

>>10601595

Only as long as the black squares do. The banned bit in the middle will still be detectable if it aint mangled. Every tweet/post/blah needs to be as close to unique whilst human familiar as possible.

>>10601609

My pleasure. Last thing on this then it's break time for reals.

When you solve that captcha where you identify cars or trains or traffic lights or whatever it is, you are helping train the counter to this technique, get a few wrong here and there, you usually still get through and it helps us keep human knowledge with the human side.

>>10601765

>>10601345

Any takers on this getting into tools? Despite the endless tech arguments this actually works, has a low learning curve and is short enough to break apart and follow if you thinks I'm haxing your gibson.

>>10601823

Yeah I always wondered about repos, prob not anon enough, hence all the pastbin.

Considering the reaction so far I don't think it is worth making it better right now. It does the job now and any more convenience is just more code / dependencies / effort to understand / suspicion. If it gains traction by people actually using it instead of hypothetical arguments then we can work together on improvements.

>>10601843

Cyrix 686 fo lyfe

>>10601864