Data Saver quality settings

[Cav88g]

I think that can be useful to have a size limit for no data saving.

Example:
You can set image max size is 2000 pixel, so anything above is compressed.

This is useful to prevent a sort of banding problem (I don't know if this is the right name of the effect, I'm sorry).

This should be different from actual data saver since now it compresses everything without distinction.

 

[Roler]

I think that can be useful to have a size limit for no data saving.

There already are limits (rule 3.1)

This is useful to prevent a sort of banding problem (I don't know if this is the right name of the effect, I'm sorry).

What? Can you post a screenshot of the "banding" and also your browser, browser version, and operating system (if it's Safari you can just post the iOS/macOS version)?

Except if you meant the image banding artifact on data-saver images, then yeah, that can't be fixed.

This should be different from actual data saver since now it compresses everything without distinction.

Well, data-saver is precompressed (not compressed in real time) so adding options isn't possible unless they keep another copy of the images.

And a client-side option to only use data-saver images for images over 2000px can't be added since the images in a chapter can vary in size so you'd need to fetch every image to detect its size which defeats the point (well, the requests can be aborted once you get the size but that'll still take some extra data and time).

 

[doppler]

If final file size is what you are looking for. Read through this thread I did a while back. A really, really big media file is not needed for reading manga. The coding was optimized for size, not for lowering the quality (sacrificed results).

here is the link:
https://forums.mangadex.org/threads/pinga-pingo-png-optimizer-maybe-tits-up-404.1004925/

 

[Cav88g]

There already are limits (rule 3.1)

Yeah I know, but sometimes it's still a problem

What? Can you post a screenshot of the "banding" and also your browser, browser version, and operating system

I don't know how to post a screenshot sorry. It's like having horizontal and vertical bands.

I use mostly tachiyomi or Samsung browser (latest stable).

Well, data-saver is precompressed

Maybe they can add a "Full HD-jpg" data saver mode? Because sometimes these images are also heavy PNG.

@Roler

 

[Cav88g]

If final file size is what you are looking for. Read through this thread I did a while back. A really, really big media file is not needed for reading manga. The coding was optimized for size, not for lowering the quality (sacrificed results).

here is the link:
https://forums.mangadex.org/threads/pinga-pingo-png-optimizer-maybe-tits-up-404.1004925/

Ok, I tried to understand something but it's pretty difficult since I have no developing skill.
Anyway, if I understand correctly from the last message in that thread, this script does not work anymore, right?

 

[Roler]

If final file size is what you are looking for. Read through this thread I did a while back. A really, really big media file is not needed for reading manga. The coding was optimized for size, not for lowering the quality (sacrificed results).

here is the link:
https://forums.mangadex.org/threads/pinga-pingo-png-optimizer-maybe-tits-up-404.1004925/

Well, MangaDex already uses lossless PNG optimization on original images, but they use oxipng iirc.

I don't know how to post a screenshot sorry. It's like having horizontal and vertical bands.

I use mostly tachiyomi or Samsung browser (latest stable).

You can post a screenshot by uploading it to something like imgur and linking the image (you can use the insert image or insert media button).

I guess you're talking about the image banding artifact on data-saver images.

Maybe they can add a "Full HD-jpg" data saver mode? Because sometimes these images are also heavy PNG.

Data-saver already converts PNGs to JPEGs.

 

[doppler]

Ok, I tried to understand something but it's pretty difficult since I have no developing skill.
Anyway, if I understand correctly from the last message in that thread, this script does not work anymore, right?

Yes, the new versions (after A70) of pinga broke it. But version A70 can still be used. I reviewed the newer stuff in 1.xx releases. He states faster completion times. But he is doing it by lesser optimization -s4 instead of (a70) -s9. A70 could give the same times as 1.xx using -s4 option. My coding spreads the number PNG's to compress over multiple threads (cmd windows). Pinga is multi-tasked but single threaded. Multi-core processors don't even get warmed up.

 

[doppler]

Data-saver already converts PNGs to JPEGs.

The only reason I don't like the data-saver of MD. Jpg can create pixel figments both positive (they appear) and negative (real data disappears). In the end they could look bad when converting.
Bottom line:
If the media has color (any depth) JPG is fine and will compact tighter than PNG.
If the media is B/W (or 4 bits or less depth) PNG is where you want to go. No figments and smaller than JPG.

PNG using lossless is still small than JPG compression. Only when B/W is involved.

 

[BraveDude8]

Highly unlikely we'll ever have more than one option for data-saver due to image storage concerns, and applying it to anything over 2000px would basically make it longstrip-only data-saver.

If you need to save data, the assumption is that you're fine with a sacrifice to quality - any attempts to make data-saver higher quality are missing the point.

 

[Samhill]

I don't know how to post a screenshot sorry. It's like having horizontal and vertical bands.

Ask Bixby or better yet Google Assistant to, "Take a screenshot." If you have Android 13 (I don't think it comes from Samsung) you should have a quick setting (pull down twice from the home screen) to take one.

I like https://imgbb.com/ host because you don't need to join, but you can use whatever host you like. Post the BB code here.

 

[Cav88g]

These are the images. They're not even taken from from mangadex but this shows very well the "banding" effect

https://ibb.co/R6wcZr7
https://ibb.co/2KFCKcS
https://ibb.co/VL2r4P9

 

[WindOcean]

If you need to save data, the assumption is that you're fine with a sacrifice to quality - any attempts to make data-saver higher quality are missing the point.

I already asked a few years back: Why not have WEBP as image format for data saver? It looks much MUCH better than jpeg. And the argument from last time, that webp is not supported by safari, is outdated.

 

[BraveDude8]

I already asked a few years back: Why not have WEBP as image format for data saver? It looks much MUCH better than jpeg. And the argument from last time, that webp is not supported by safari, is outdated.

WebP is optimised for low quality full color images, the vast majority of chapters are high quality black and white images, it barely makes a difference.

Also we'd need to keep JPEG datasaver around for compatibility, meaning we'd now be storing three copies of each image, and disk space is expensive.

I'd love to do JPEGXL datasaver, because that would make a massive difference, but that requires Google to pull their head out of their ass first.

 

[WindOcean]

Well, in personal testing jxl wasn't that great. Especially for those pages with lots of white space webp's artefacts look much more pleasant. I've really pixel peeped on all kinds of images.... Maybe that's an issue 😅

And yes it does make a difference even for black and white images, escpecially for them. Jpeg artefacts are terrible on them, and webp results in decent looking, but small images. Have you used a proper program like ImageMagick for your testing?

As for backwards compatibility it
could just be removed. Most users will never notice. ┐⁠(⁠´⁠ー⁠｀⁠)⁠┌

 

[outofprotocol]

I'd love to do JPEGXL datasaver

Did anyone explore webasm jpegXL decoder?
E.g. https://github.com/niutech/jxl.js

Tried lossless reencode, compared to optimized OxiPNG it was -30% or so (max effort mode), for jpeg there are lossless reencode option for ~20% savings. I did check these numbers on smaller number of samples, things can b different at scale.
So, proposal:

If wasm decoder is good enough for most consumers,

• store originals as jpeg xl images
• convert from png/jpg during upload, maybe even on uploader side to reduce server burden
• serve jxl as is for most clients including api
• for some outdated browsers decode server-side and serve as jpg/png. Decoding is fast, there are good chance no caching is needed

For datasaver store another jxl with worser quality, everything else applies as well.


P.S. sample

https://r2.pocketmoon.me/upload/2024-03-02_lossless_e9.webp

https://r2.pocketmoon.me/upload/2024-03-02_OxiPNG.png

https://r2.pocketmoon.me/upload/2024-03-02_lossless_e9.jxl