Currently studying CS and some other stuff. Best known for previously being top 50 (OCE) in LoL, expert RoN modder, and creator of RoN:EE’s community patch (CBP).

(header photo by Brian Maffitt)

  • 3 Posts
  • 14 Comments
Joined 2 years ago
cake
Cake day: June 17th, 2023

help-circle

  • Different people also have different sensitivity to different types of artifacts. No doubt a degree of the complaints is overblown due to a big of tribal / mob mentality going on, but a few of the people complaining might just be more sensitive to it.

    With TAA specifically there’s probably also implementation differences going on, where someone has a bad experience with it once or twice and then generalizes that experience to all implementations of it.






  • MHLoppy@fedia.ioto196@lemmy.blahaj.zonerule
    link
    fedilink
    arrow-up
    2
    ·
    23 days ago

    Shit, you’re absolutely right, I missed an (in hindsight very obvious) optimization - bit depth. It’s been so long since I’ve actually needed to worry about it that I forgot that the setting existed! What makes it even worse is that I did already play with quantizing the colors dwon to a more limited space, I just never baked that in as the bit depth haha.




  • MHLoppy@fedia.ioto196@lemmy.blahaj.zonerule
    link
    fedilink
    arrow-up
    8
    ·
    23 days ago

    The maximum color quantization you can do on this image without huge information errors is something like:

    • 1x yellow-brown for stars / streamers / shorts / socks
    • 1x brown for tree base (though it might be better to remove the base to save a color)
    • 1x red for baubles / hat / sweater / shoes
    • 1x green for tree
    • 1x blue for hair (potentially you could merge the tree color if you want to really push it)
    • 1x skin tone for skin
    • 1x pink for mouth
    • 1x black for lines
    • 1x light yellow for background

    Which is 9 total colors. This would also require living with aliased text ( c r u n c h y ), since it would be data-expensive to add extra shades of gray. At that point you’re no longer making a low-quality copy of the original - you’d basically be making a pixel art version of it since you can’t afford any colors for anti-aliasing and gradients.

    Here’s an example PNG with 9 unique colors and some pretty simple patterns without huge information density: https://files.catbox.moe/bj0acl.png

    Even that’s 1,847 bytes! (i.e., basically 2KB)


    Edit: I made a big (in hindsight, obvious) mistake by forgetting I can literally just change the bit depth of the image when saving, so the example I’ve provided is actually very inefficient by comparison. Valmond has set me straight.



  • MHLoppy@fedia.ioto196@lemmy.blahaj.zonerule
    link
    fedilink
    arrow-up
    15
    ·
    24 days ago

    It’s quite challenging to keep the text legible within a 1KB limit. Here I manually removed a few details that more-or-less weren’t visible post-compression anyway, then cut the color palette a little. You have to use such a low resolution with such high compression that almost everything gets amputated to keep the text kinda-readable (and even AVIF and JPEG XL (which are usually better than WebP) struggled, at least in my editor): https://files.catbox.moe/eyp2w7.webp

    If you can live with 2KB, you don’t have to amputate nearly as much: https://files.catbox.moe/g5htfo.webp

    In both cases I manually reconstructed the top of the star, but that’s a bit “extra” lol.


    And just for comparison, no text and 10KB at “full” res: https://files.catbox.moe/9bkn21.webp

    The same thing but half res (more optimal at this file size): https://files.catbox.moe/cac65u.webp


    Valmond’s implicit suggestion of not just quantizing as a pre-processing step (which is what I foolishly did), but actually reducing the saved bit depth of the image might give you something that looks much better overall than what any of the WebP versions we’ve been playing with here do - if you put in more effort!

    Here’s an example of a not-fully-optimized implementation that gets down to ~2.5KB as a PNG, or ~2KB as a lossless WebP (i.e., the two images are identical in quality):

    With some judicious manual optimization (which I haven’t done here), it’s plausible you could get this down to 1KB with better overall fidelity than the lossy WebP versions we’ve been playing with. Not 100% sure, as optimizing images for file sizes this small is not really my wheelhouse!

    My main concern with this approach is that you’re bottlenecked by resolution - large areas of plain color have a hard limit on their compression with PNG, but lossy compression can go wild with stuff like that.