forum

[Rule Change] Background images must be of reasonable file size

posted
Total Posts
15
Topic Starter
Eni
Here is a recent ranked map with ridiculous background file size: Camellia - Feelin Sky (Camellia's "200step" Self-remix)

pimp suggested a more reasonable background size, but the mapper did not agree with this change. Since there is no rule in the RC, it becomes difficult to enforce changes like this that make osu! better for everyone.

-----------

File size usually depends on the amount of things happening in the background (I shall refer to this as "noise"). The less noise there is, the less file size you should expect.

This background has very few colors and clearly lacks noise, so you should expect the file size to be relatively low. Unfortunately, we let a background of this quality get ranked with 3.22 MB in file size, which is absolutely absurd for a background of this caliber.

Ranked background (3.22 MB): https://railgun.s-ul.eu/ipGmxb2b
Compressed background (347 KB): https://railgun.s-ul.eu/LifF8pk9

If you open both links, you can clearly see that they both look the same and the compressed background loads much faster. The compressed background is over 9 times smaller than what is now ranked. Since I know that some people still have trouble downloading 4 MB maps, we should at the very least use backgrounds of reasonable file size.

-----------

This RC change is similar to Kibbleru's, although I propose that we get rid of dimension restrictions entirely and instead focus on file size. See my reasoning here.

Current:
Background images must not exceed a width of 1920 pixels and a height of 1200 pixels. Images with lower vertical or horizontal resolutions than that of the player's will be upscaled to fit the entire screen.
Proposed:
Background images must be of reasonable file size. The more noise in the background, the larger the expected file size. Background images should not be larger than 2 MB. Noisy backgrounds of resolution 1920x1200 should not be larger than 1 MB. Use proper judgment when compressing backgrounds.
Open for comments.
Net0
2mb is a good cap for 1080p since I did some tests and high quality jpg usually goes around 1~2mb but it's hard to get a very exact value since it all depends on the specific image. Very minimalist and simple background will have a much smaller filesize compared to complex colored and many details images since the amount of information on that bitmap is bigger.

However I do agree that some backgrounds are just big without any purpose and compression should be something worth taking as a guideline, but without a good and detailed information about is hard to come up with a new guideline for RC since it will be based on mostly "attempts" and guesses
Monstrata
I don't think file size is really an issue considering a beatmap doesn't have to be ranked to be stored on osu's database, so any argument about these large images cloging up the server etc... are next to impossible to enforce short of automated submission restrictions.

Of course you can still argue that it creates large download files for people, but imo this just isn't true for the vast majority of people.

As well, a lot of other things can contribute to large file sizes. I think pushing this as a rule lends itself to potentially tricky cases because other things might get pointed out in the future. Basically if this is pushed as a rule it would "enable" other things to be enforced. Let me give you an extreme example: "Delete all bookmarks before ranking a map". Objectively reduces file size. Of course, this is ridiculous, but lets consider some less ridiculous ones like "Crop hitsounds so that there is no silence after the hitsound has played." This is quite valid and in many cases can take up between 10-25% of the hitsound file itself (many hitsounds have unnecessary silences after them). And this translates to around 500kb-1mb and even more on larger maps with multiple hitsound sets. Or maybe some rules down the line about optimizing storyboard functions. For example certain animations can be recreated using far simpler commands etc... but not everyone has the coding knowledge to be able to write code in that way.

I'm not saying this isn't an issue, but I feel putting this as a rule lends itself to a lot of other possibly less favourable or more murky situations suddenly becoming valid or justified.

Personally I think this issue doesn't really affect the majority of players anyways, and should be treated as a method of potentially improving the mapset. But if the mapper does not wish to reduce the file size, they shouldn't have to as it shouldn't be an obligation.
pimp
the RC applies only for maps going for ranked so we really can't do nothing about the other maps, but once this is added to the RC, people will get used to the changes and they will apply to their next maps (if they are smart).

in my opinion what's going to get ranked should be optimized as much as possible, so if we eventually start discussing bookmark "abuse" then that's fine, it's very easy to tell when someone is adding bookmarks just to grab attention or something like that... if removing bookmark abuse can reduce file size significantly then it's worth it. hitsoupnd extra length will usually not be intentional and i believe it would be much less common than bookmarks or background, but if hitsounds have unusually big file size then it's worth fixing for sure.

anyway background file size should really have at least a guideline, every single beatmap has to include it and we can add backgrounds for every single difficulty, just imagine one of those maps with 13+ difficulties with individual unoptimized backgrounds. basically all the optimization we do following the ranking criteria (limiting mp3 bitrate, croping sb images, removing video's audio track, removing unused files from folder etc) are wasted effort if we don't regulate background size.
pishifat

Monstrata wrote:

I don't think file size is really an issue considering a beatmap doesn't have to be ranked to be stored on osu's database, so any argument about these large images cloging up the server etc... are next to impossible to enforce short of automated submission restrictions.


also need to consider how ranked maps are more downloaded and how servers are used to compensate for that. idk any of the details for this though, so i cant make any strong calls

---

re main post:
i think if this is going to happen, we'd need to know what the majority of people consider to be a reasonable filesize. anything is "technically" passable now, but if a bg is 10mb, it'll be shot down by people's common sense, regardless of rc control. if trying to enforce a max of like 2mb though, there's some people who think 2mb isn't enough and will argue against that being added, which will result in no rule being added at all

if a consensus is met for the max filesize of any image used as a bg, then something can be done. need more people to pitch in on that
Topic Starter
Eni
2 MB should be more than enough as a hard limit. As for 1920x1200 and below, anything above 1 MB should not be reasonable.

This 1920x1200 background I compressed came from an original 8596x6042 image and is only 813 KB in size: https://railgun.s-ul.eu/GTAV17ut

If anyone can find a detailed 1920x1200 background that has larger file size than this after compression, please post it here.

Theoretically BSS could automatically compress beatmap images and other assets so the mapper never has to worry about it. This is what popular services like social media websites do, but this would mean that mappers lose the freedom to control the quality of their assets.

Mappers will be able to use 2560x1440 and 3840x2160 backgrounds that fall below the 2 MB limit. If the limit is not met, they can simply decrease the resolution or increase compression as they see fit.

------------

Edit: I'd also like to point out this map: Camellia feat. Nanahira - Amor De Verao which uses 8 backgrounds, all of them at least 1 MB and half of them at least 2 MB, even though none of them are larger than 1920x1080. The entire .osz is 24 MB without video, which even for my internet takes a while to download.

Here is the largest background of the set (2.8 MB): https://railgun.s-ul.eu/BjkIdQSN

Here is the same background I compressed in less than one minute (283 KB): https://railgun.s-ul.eu/FspPpzI1

The same can be done for quite literally all the backgrounds in this set.

Compare: https://railgun.s-ul.eu/ocjfvib0 (also 2.8 MB)

And: https://railgun.s-ul.eu/GMkqOJHZ (457 KB)

If these images were properly compressed, this set would easily be under 12 MB (50% of time saved for everyone downloading it, etc., while still maintaining the same image quality).

Part of the problem is that many mappers see png as the ideal format (even if the original image was jpg!). Realistically, using jpg will not cause a noticeable difference for most osu! players (many ranked backgrounds are of jpg quality to begin with, just exported as png and consequently use more space than needed).

There is no need to unnecessarily increase bandwidth costs (which I assume osu! has) and active players can enjoy a smaller osu! folder without manual intervention on their part.
Ryuusei Aika
agree with mons
Uta
I don't think 2-4 MB is not really a big of a problem.
bossandy
It is not a problem at all.
But bandwidth is not free.
so I do agree need some change regarding BG file size.
But instead of a complex rule.
I would like to simplify the rule.
maybe just not larger than 1mb?
simple and fair I guess.

think about in case if I use five 3mb pngs for my 5 diffs mapset, will it acceptable?
defiance

Uta wrote:

I don't think 2-4 MB is not really a big of a problem.
^
Akeruyri
I can notice a pretty big difference in the compressed background, the hair looks like shit. But, almost everyone has 100% background dim and its not a gameplay element so i guess compressing it is fine
Topic Starter
Eni
Well the point of allowing 2 MB instead of 1 MB is so that we can start ranking 1440p / 4k backgrounds in osu! (yes, they're smaller than 2 MB).

I guess people ranking 1080p backgrounds 1+ MB in size is unavoidable, so how about this instead?

Background images must be of reasonable file size. A mapset with one background image must not be larger than 2 MB. A mapset with multiple background images must use no more than 1 MB for each image.

The problem is that people will see this file size limit as a hard limit, even if the background isn't worth e.g. 1.2 MB. So I'm still down with automating compression instead of letting individual mappers do it (this would also be a good time to fix existing backgrounds with large file size).
pishifat
added 2.5mb limit along with the 2k res proposal, hope that's ok with everyone: https://github.com/ppy/osu-wiki/pull/2156
pimp
no that's not ok, 2.5mb is just too much considering that you can add different backgrounds per difficutly.
so far the people oposing the filesize regulation didn't say anything that valuable.

i'd say ~1.4mb would be ok if there is only one background used in the mapset.
Topic Starter
Eni
I'm a bit late to reply, so I apologize.

I think a 2.5 MB limit will only solve extreme cases. osu! is not a wallpaper website, so I think compression makes sense. There have been some high quality background images ranked recently with low file size, and some low quality images with high file size. I would love to see a solution where these low quality images aren't taking up more space than the high quality ones.

As another example, Akatsuki Records - ENDLESS FANTASY uses some nice backgrounds that are unfortunately oversized.
  1. Ranked background (1600x900) (1.5MB)
  2. Compressed background (1600x900) (141KB, 90.68% file size reduction)
And again:
  1. Ranked background (1920x1080) (1.4MB)
  2. Compressed background (1920x1080) (148KB, 89.79% file size reduction)
I really think we should be compressing these images automatically, since these numbers are huge and will likely be significant when all beatmaps are taken into account. Automatic compression means that mappers can just upload their background images and not have to worry about compression on their end.
Please sign in to reply.

New reply