Closed myself600 closed 1 year ago
While WebP gives better compression it adds an extra dependency and isn't as well supported as PNG. Currently the plan is for PNG support since we already have PNG support as a dependency.
This has been brought up a few hours ago:
https://discord.com/channels/518540764754608128/764970679564501052/1125826058512515113
While WebP gives better compression it adds an extra dependency and isn't as well supported as PNG. Currently the plan is for PNG support since we already have PNG support as a dependency.
PNG is inefficient by today standards (still good for small images) and WebP is widely supported AFAIK. Which platform has issues with it?
As for the extra dependency, maybe an optional build flag could help, but since it's not too important, I'll stay with a script as a solution (saves me 100s of MB vs. PNG).
Yes I was there for the conversation.
PNG is a goal, other formats and options maybe accepted if done in a minimalistic way, which is feasible since it will likely work via SDL_Image which has a wide range of supported formats when using the system version.
I'll stay with a script as a solution (saves me 100s of MB vs. PNG).
That would imply at least 1200 screen shots. I'm not saying that it's impossible though. But it's not a common case and even a few hundred MB isn't much by today standards
PNG is inefficient by today standards...
I would argue that PNG is still widely used and widely supported because it is considered adequate by today's standards.
saves me 100s of MB vs. PNG
If you have so many screenshots that WebP saves you hundreds of MB, then it makes sense to use a more space-efficient format. Most users would save maybe a few KB at best.
My vote is for png.
I hate webp. I keep finding webp images online and they piss me off
Just two small notes:
cjxl -q 100 -e 10 --allow_expert_options
for five minutes but I'm running stable libjxl at v0.8.2.
A few weeks ago I have seen one palette related commit getting merged for 0.9 that fixed one case in which WebP beat JXL.Thus I would vote against adding WebP ever. Not that this really matters for now since you decided for PNG for the meantime but it might be relevant in the future.
PNG is a goal, other formats and options maybe accepted if done in a minimalistic way, which is feasible since it will likely work via SDL_Image which has a wide range of supported formats when using the system version.
That would imply at least 1200 screen shots. I'm not saying that it's impossible though. But it's not a common case and even a few hundred MB isn't much by today standards
~1100 only on this computer, atm. (until I decide to delete them). It matters as I don't have endless disk space (I have to delete stuff regularly).
I would argue that PNG is still widely used and widely supported because it is considered adequate by today's standards.
So is jpg, mp3, gif, whatever. If it works..
If you have so many screenshots that WebP saves you hundreds of MB, then it makes sense to use a more space-efficient format. Most users would save maybe a few KB at best.
Idk about that, but sure. I like to screenshot everything unusual, even if in 99% it'll never be used for anything (for ex., I was able to post a picture of an item from Wirt a few weeks later on Discord).
I hate webp. I keep finding webp images online and they piss me off
It's great imo. Why does it "piss you off"?
@schrmh JXL is not a viable option as per now (worse than WebP) as outlined in OP.
- Yea, I noticed that libwebp is a hard dependency of sdl2_image on Arch/Ubuntu/etc. despite being optional.
It's a hard dependency because that's how they built it. You can build SDL_image without it, but then the package maintainers for those platforms would have to either provide a less functional package or maintain two separate packages. If the platform already has support for libwebp, then they might as well just use that and build support for it.
DevX also supports statically linking SDL_image from source, in which case we do not include support for WebP.
So is jpg, mp3, gif, whatever. If it works..
JPG is also considered adequate by today's standards for lossy compression.
GIF is still widely supported, but not as widely used anymore since PNG more or less replaces it. A notable use case for GIF that isn't replaced, however, is animated images.
MP3 is also fine for lossy compression, and we already support that.
None of these are good examples if you're trying to support your case.
JPG is also considered adequate by today's standards for lossy compression.
GIF is still widely supported, but not as widely used anymore since PNG more or less replaces it. A notable use case for GIF that isn't replaced, however, is animated images.
MP3 is also fine for lossy compression, and we already support that.
I consider these to be technically obsolete, but kept alive for compatibility reasons (they're good enough, even tho they're crappy, and people tend to switch only when it's really necessary - e.g. video formats, support for specific color space, etc.). I personally don't use any of them in terms of encoding.
None of these are good examples if you're trying to support your case.
There's nothing other than what I've already said. I'm okay with PCX, PNG or whatever (lossless format) the devs will choose (more so after this was being uniformly rejected) as post-processing can be done manually.
Replace PCX with lossless WebP to conserve disk space and add compatibility (e.g. Discord). See #6057.
Comparison with other image formats (patent-encumbered ones such as BPG aren't included):
PCX (843,3 KiB) - Screenshot from 2023-07-04 23-02-48.pcx PNG (534,8 KiB,
ffmpeg -lossless 1
) - legacy format, worse compression WebP (367,5 KiB,cwebp -lossless
) JPEG XL (589,5 KiB,cjxl -q 100
) - doesn't support 8-bit palette AVIF (1,7 MiB,avifenc -l
) - it doesn't really work :shrug: