USE TURBO MODE!!! I also highly recommend using turbowarp. (See link under this chunk.) The project blurs the image a certain amount of times that increases exponentially based on the blur level. Also, the time estimations are designed to estimate the time that the blur calculations will take on turbowarp. You can get there with the link provided below. ------------------> turbowarp.org/696387502 <---------------------
Thank you to @Geotale for discovering this brilliant strategy for insane optimizations for image scanning. Thank you to @Griffpatch for bringing this discovery to my attention with a YouTube video. Thank you to @supersls for following the instructions provided by @Griffpatch to make a super fast image scanner. Doing so makes it so I don't have to. I could, but why do that work when I can just skip it at no cost? It's not laziness, it's e f f i c i e n c y. Okay maybe it's laziness. But what did I do? I came up with an idea for how to go about blurring an image. Doing so required converting the overall color values to RGB. Then I had to write an algorithm to find the average value of red, green, and blue in the selected space and all of the valid spaces of it's 4 adjacent spaces, storing the results in separate red, green, and blue storage lists to prevent these values from influencing the calculation. Next, I had to transfer the data of these storage lists back to their respective lists. After doing this, I had the project repeat this a certain amount of times determined by an exponential formula based on the input blur intensity. I finished it off by converting the finalized RGB values back into their overall color values. But the way I had it, you started by choosing a blur value from 0 to 255. I realized that when using exponential growth to determine the number of times to repeat the blur loop, I would be making anyone who chooses to pick a value of 255 wait for the program to repeat the loop 628 quindecillion (6.3X10^50) times. (See chunk below for the exact statistics.) I calculated the average amount of time to complete each repetition of the blur loop, and found it to be close to a tenth of a second. This means that they would have to wait 1.9 tredecillion (1.9X10^42) years. (See chunk below for exact statistics.) Because of this, I reduced the maximum blur intensity to 31. This way, the longest you would have to wait would only be 1 day. But I didn't want people selecting maximum blur, and giving up after an hour, wasting an hour of their life. So I decided that if the calculation is expected to take at least 1 minute, it should warn the user that it may take a while. But that wouldn't be enough information, so I had it convert the estimated amount of seconds necessary to complete every repetition of the blur loop into a more user friendly form, displaying the expected wait in days, hours, or minutes, depending on which one is the most simple. (Ex. 7823 seconds would be shown as 2 hours, and 1453 seconds would be shown as 24 minutes.) I also included proper singular and plural terminology. (Ex. A minute value of 12 will be associated with 'minutes,' while a minute value of 1 will be associated with 'minute.') The system had a lot of bugs and mistakes, however. I had to spend over 3 hours of head scratching (no pun intended) finding the problems and solving them. And it was ready. I am quite proud of this. I am also so grateful that you have taken the time to read this, or even just trying to comprehend it. Thank you so much. STATISTICS First build max blur loop count: 627555566564004652765367183984729332696541473778604 First build max blur calculation time: 1855307491498781342340686939571554635098652 years, 110 days, 5 hours, 32 minutes, and 2.417388 seconds. Time spent on coding: About 6 hours.
