script doesn't entirely blank existing commit tiles

[numberoverzero]

It looks like existing commits aren't being pushed below the threshold for the tile coloring even when using the gitfiti option (which I think uses max_commits^2 if I'm reading the source correctly, but probably not).

In my run, this resulted in the surrounding pixels staying the lightest green color, and a stray darker green pixel inside the oneup (below the left eye).

The changes aren't taking a day for me to see, I think you can force a redraw by toggling the new contribution setting.

Before:

After:

My input when running the script:

Enter github url
Enter nothing for https://github.com/ to be used: 
Enter your github username:
>numberoverzero
Enter name of the repo to be used by gitfiti:
>$REPO
Enter the number of weeks to offset the image (from the left):
>8
By default gitfiti.py matches the darkest pixel to the highest
number of commits found in your github commit/activity calendar,

Currently this is : 38 commits

Enter the word "gitfiti" to exceed your max
(this option generates WAY more commits)
Any other input will cause the default matching behavior
>gitfiti
enter file(s) to load images from (blank if not applicable)
>
enter the image name to gitfiti
images: oneup, kitty, octocat, oneup_str, hello, hackerschool, octocat2, oneup2, hireme
>oneup2
gitfiti.sh saved.
Create a new(!) repo at: https://github.com/new and run it.

[gelstudios]

interesting, what's happening here is that the commit count for the day/pixel under the mushroom's eye is being added to the commits generated by gitfiti. So any tile touched by gitfiti will have at least existing commits + new commits.

You could try changing the multiplier to severely scale down existing commits relative to the new.

I guess gitifiti could figure out a given day's commit count and subtract that number from the proposed gitfiti input...

[trickpattyFH20]

same issue here