set a maximum file size ?

[kevinrue]

Some stickers stand out with their file size.

The vast majority of stickers are less than 500KB while the top 7 are over 1 MB with the largest filesize reaching 3.3 MB.

Shall we set an upper limit to the allowed file size?
Should we ask the maintainers of the current largest stickers to replace them with files capped to a maximum file size?

[mblue9]

Sounds like a good idea to specify a size limit.

If it makes things easier on your end @kevinrue for creating the hexwall, maybe you could resize the largest few and open a PR? You could tag the contributors to let them know, rather than waiting for them to find time to do it themselves.

By the way, I noticed there are a few open PRs with new stickers @lgatto has been merging but is currently on holiday. Is there anyone else with merge permissions (maybe @LiNk-NY ?) who could help approve and add them for today's deadline?

[kevinrue]

For the hexwall, I already have some code to process the stickers to "normalise" certain aspects (e.g., I downsample some of them during the identification of the average colour for the purpose of sorting by colour, I also make sure that the background is cropped to the hexagonal outline of the sticker). However, the largest stickers do take noticeably longer to be processed, while the majority of stickers take only a few seconds. That led me to cache a lot of information between runs to avoid the costly recalculation of those steps.

It's not a dealbreaker to me, so I'm not very keen to take responsibility for resizing other people's stickers, as I don't want the blame if they're unhappy with the result or wish to keep a copy of the large file (they could theoretically get it back from the git history).

I recently saw I could approve but not merge, so probably not a big help?

[LiNk-NY]

@mblue9 @kevinrue
I agree with having a size limit though I am not sure how to recommend a specific limit.
I gave you both maintainer access to the repository. You should also be able to approve incoming submissions.

[lgatto]

We can add the file size limit to the instructions, in the README. I'll tentatively set 500KB.

[lgatto]

@kevinrue - do you want to open issues and tag the respective maintainers?

[kevinrue]

@lgatto sure I can do that (not right now but at the next opportunity)

[kevinrue]

For illustration, here's the current list of > 500 KB.

        ontoProcHex.png            1200_logo.png             Bioc2024.png               coRdon.png         EuroBioC2025.png 
              "3.492 MB"               "3.125 MB"               "2.441 MB"               "1.863 MB"               "1.693 MB" 
          HPAanalyze.png  biocAsiaSticker2023.png              DRIMSeq.png                vissE.png                ideal.png 
              "1.178 MB"               "1.124 MB"               "0.892 MB"               "0.888 MB"               "0.771 MB" 
       biocasia-2025.png         EuroBioC2024.png                 scry.png            orthogene.png               standR.png 
               "0.73 MB"               "0.663 MB"               "0.531 MB"               "0.531 MB"               "0.527 MB" 

That is 15 packages (5.5%) over the cutoff for 257 packages below.

I feel a bit bad for those just above the cutoff. Given the plot below, I'll draw the line a tiny bit higher, as the outliers really start from 600 KB (second line).

That brings down to 12 packages (4.4%) above the adjusted "file size value" :)

[kevinrue]

As mentioned above, I've stopped at the 600 KB threshold for now. Seems excessive to pick on the 3 poor packages between 500KB and 600KB given the plot above.

[lgatto]

I'll leave it to 500KB in the README, and we keep a 100KB buffer space :-)

[federicomarini]

As a possible solution for most of these outlaw stickers (which includes also one of mine): https://pngquant.org/

On a Mac ultra easy to get via brew install pngquant, then it is really a matter of simply saying pngquant ideal/ideal.png and replace that.

[Bisaloo]

Following up on pngquant's suggestion:

I have been using pngquant with a lot of success for several years now but I recently discovered oxipng which has resulted in even better compression.

It can also be used via the tinyimg R package.