Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Compress rapid-fire screenshots #54

Open
nmlgc opened this issue Sep 17, 2023 · 2 comments
Open

Compress rapid-fire screenshots #54

nmlgc opened this issue Sep 17, 2023 · 2 comments
Assignees
@nmlgc
Labels
Enhancement New feature or request Graphics ~≤0.33 pushes Projected number of pushes needed. Might turn out to get more expensive!

Comments

@nmlgc
Copy link
Owner

nmlgc commented Sep 17, 2023 •
edited
Loading

The original game's screenshot feature (#15) only writes uncompressed .BMP files that take up quite a bit of disk space. Due to the rapid-fire nature of these screenshots, this can add up to hundreds of MB very quickly.

Nowadays, there are two three four main contenders for lossless compressed image formats:

  • PNG: Widely supported, best compression, but very slow. So slow that it might cause frame drops when holding the screenshot key.
  • QOI: Released in November 2021, quickly became famous for its simplicity and encoding speed, and is quickly gaining support in other programs. However, its compression algorithm was not built with heavily dithered 256-color source images in mind, and it would therefore compress Shuusou Gyoku screenshots rather poorly. Just mentioning it here because I'm sure that someone would recommend it otherwise.
  • Lossless JPEG-XL: Fast, decently small files on even the lowest effort setting, and we might even want to go higher?
  • Lossless WebP: Best compression for this type of image among all widely used formats, beating JPEG XL at almost every effort setting. Really nice C API, too.
  • GIF: Would actually compress only slightly worse than PNG, but 256 colors are probably not enough once Direct3D-rendered transparent shapes come into play.

None of these are part of SDL, so we'd have to add another library in any case.

Here's a decently busy reference screenshot:
A decently busy reference screenshot

Format File size Encoding speed
BMP, 32-bit 1,228,854 bytes 🏎️
QOI 179,201 bytes 🏍️
JPEG-XL, -e 1 128,955 bytes 🏍️
GIF, optimized 61,290 bytes
WebP, -z 0 54,722 bytes 🚲
WebP, -z 1 52,710 bytes 🚲
WebP, -z 2 46,764 bytes 🚲
WebP, -z 3 43,990 bytes 🏃
WebP, -z 4 42,760 bytes 🏃
WebP, -z 5 43,138 bytes 🏃
PNG, oxipng defaults 42,136 bytes 🦥
PNG, oxipng -o max -Z 41,615 bytes 🐌
WebP, -z 6 40,796 bytes 🚶
WebP, -z 7 40,108 bytes 🚶
WebP, -z 8 40,122 bytes 🐢
WebP, -z 9 39,264 bytes 🐌
@nmlgc nmlgc added Enhancement New feature or request Graphics ~≤0.33 pushes Projected number of pushes needed. Might turn out to get more expensive! labels Sep 17, 2023
@nmlgc nmlgc self-assigned this Aug 1, 2024
@nmlgc
Copy link
Owner Author

nmlgc commented Aug 1, 2024 •
edited
Loading

The JPEG-XL variant received funding from Ember2528's Seihou subscription and will be done after #36.

@nmlgc
Copy link
Owner Author

nmlgc commented Mar 24, 2025 •
edited
Loading

Well, turns out that for this type of image, lossless WebP beats lossless JPEG XL in both compression ratio and compression speed across all levels. It's also a much less complex and bloated codec, and its reference library is much easier to integrate and has a much better C API. Ember2528 agreed that we use that codec instead.
Some file sizes:

seihou 0 1 2 3 4 5 6 7 8 9
Uncompressed 308,278
RLE 17,654
QOI 18,047
oxipng 5,645
WebP 39,518 5,904 5,642 5,574 5,500 5,518 5,518 5,504 5,486 5,490
JPEG XL 6,124 5,088 4,732 4,468 4,427 4,416 4,377 4,112 4,016 4,040
AVIF 26,984 26,984 25,085 24,927 22,582 21,698 21,697 21,627 21,631 21,505
main_menu 0 1 2 3 4 5 6 7 8 9
Uncompressed 308,278
RLE 92,034
QOI 93,884
oxipng 30,702
WebP 54,116 32,194 28,112 27,860 27,712 28,272 28,178 28,120 28,684 27,816
JPEG XL 146,352 51,851 59,453 45,329 37,864 37,276 36,130 35,222 33,793 31,724
AVIF 272,604 272,604 136,220 131,235 119,398 117,525 111,380 110,684 110,543 109,601
ingame 0 1 2 3 4 5 6 7 8 9
Uncompressed 308,278
RLE 185,842
QOI 175,949
oxipng 38,409
WebP 50,678 49,030 43,620 41,760 40,724 40,854 38,608 37,940 37,842 37,138
JPEG XL 123,606 102,949 130,689 102,944 84,916 72,590 68,302 49,618 45,865 46,997
AVIF 462,703 462,703 197,818 156,007 141,043 139,689 133,399 132,573 126,270 125,379
BMP, cropped 185,398
RLE, cropped 177,456
QOI, cropped 165,620
stage6 0 1 2 3 4 5 6 7 8 9
Uncompressed 308,278
RLE 55,838
QOI 52,302
oxipng 18,741
WebP 20,856 19,916 17,070 16,524 16,380 16,562 15,488 15,386 15,404 15,124
JPEG XL 32,204 24,146 35,053 24,599 19,936 19,560 19,336 18,444 17,423 16,183
AVIF 185,676 185,676 84,437 62,354 57,791 56,524 52,956 52,611 51,969 51,795
BMP, cropped 185,398
RLE, cropped 48,954
QOI, cropped 45,874
laser 0 1 2 3 4 5 6 7 8 9
Uncompressed 921,654
QOI 290,088
oxipng 61,595
WebP 85,318 56,724 51,558 53,964 53,492 53,492 51,860 51,460 51,460 41,726
JPEG XL 345,199 287,279 301,608 248,852 92,463 85,529 81,206 66,811 61,445 47,173
AVIF 218,858 218,858 122,100 88,490 82,675 81,245 75,866 75,395 75,462 75,138
BMP, cropped 553,014
QOI, cropped 280,462
laserbomb 0 1 2 3 4 5 6 7 8 9
Uncompressed 921,654
QOI 210,496
oxipng 87,286
WebP 129,472 94,564 86,538 64,990 64,062 64,062 60,776 60,318 60,318 59,198
JPEG XL 332,706 125,197 150,436 128,755 110,357 102,891 99,718 68,968 66,975 64,484
AVIF 313,731 313,731 168,388 114,111 109,239 107,121 104,109 102,054 99,106 99,103
BMP, cropped 553,014
QOI, cropped 200,002
gates 0 1 2 3 4 5 6 7 8 9
Uncompressed 921,654
QOI 157,705
oxipng 90,545
WebP 124,308 125,070 113,896 102,656 102,482 102,482 95,536 94,768 94,768 57,850
JPEG XL 208,293 185,662 212,615 172,008 124,466 117,509 113,563 110,992 97,454 91,146
AVIF 306,742 306,742 293,874 293,276 254,073 243,953 243,947 242,188 241,943 241,359
BMP, cropped 553,014
QOI, cropped 147,670

(RLE is the vintage .BMP run-length compression that was mostly forgotten after the 90's. Added it mostly to hammer home how QOI basically breaks down into a pure run-length encoder for this kind of paletted image, especially in the cropped ingame case. Also, lol at AVIF for being a complete joke and delivering the highest file sizes while taking the longest amount of time.)

The test images:

  • seihou (mostly black, best case to show off an encoder's RLE capabilities):

Image

  • main_menu (some transparent parts, but still staying within 256 colors):

Image

  • ingame (lots of sprites and only a small transparency effect in the Evade gauge. Still much fewer than 256 colors):

Image

  • stage6 (best case for in-game graphics, should compress faster than regular stages due to lots of black):

Image

  • laser (1219 colors on top of a repeated tile):

Image

  • laserbomb (831 colors, similar to the above):

Image

  • gates (2326 colors with a more varied background, probably the most intense test case the game has to offer):

Image

nmlgc added a commit that referenced this issue Mar 26, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
1a354da 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Completes P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Mar 27, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
3c53350 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Completes P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Mar 27, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
af9815b 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Completes P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Mar 27, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
62fd958 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Part of P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Mar 27, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
9164c7c 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Part of P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Mar 27, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
da04942 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Part of P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Mar 28, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
9cec79f 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Part of P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Apr 2, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
ba9a8b5 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Part of P0309, funded by Ember2528.
nmlgc added a commit that referenced this issue Apr 3, 2025
@nmlgc
[Graphics] Screenshots: Measure the time for each format/effort setting
9a2aa0d 
Using `std::chrono::steady_clock` rather than insisting on the SDL
functions is *definitely* fine for now:
• On Windows, MSVC implements it in terms of QueryPerformanceCounter(),
  so it will work on 9x as well.
• Also, that one `std::this_thread::sleep_for()` in the MIDI frontend
  has already been using it.

Closes #54.

Part of P0309, funded by Ember2528.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nmlgc nmlgc

Labels
Enhancement New feature or request Graphics ~≤0.33 pushes Projected number of pushes needed. Might turn out to get more expensive!
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@nmlgc