IIRC the way you encode grayscale in WebP is a SUBTRACT_GREEN transform that makes the red and blue channel 0 everywhere, and then use a 1-element prefix code for R and B, so the R and B for each pixel take zero bits. Same idea with A for opaque images. Do you know why that's not good enough?

I made a mistake there with subtract green.

If I had just added 128 to the residuals, all remaining prediction arithmetic would have worked better and it would have given 1 % more density.

This is because most related arithmetic for predicting pixels is done in unsigned 8 bit arithmetic. Subtract green moves such predictions to often cross the 0 -> 255 boundary, and then averaging, deltas etc make little sense and add to the entropy.

Can you explain why?

I edited the answer into the previous message for better flow.

Thankfully the following comment explains more than I know, I was speaking purely from empiric experience.

Then you can't know that any difference you see is because of how WebP encodes grayscale.

Just tried it on random manga page

- OxiPNG - 730k

- webp lossless max effort - 702k

- avif lossless max effort - 2.54MB (yay!)

- jpegxl lossless max effort - 506k (winner!)

Probably depends on the manga itself. Action manga probably don't compress as well as more dialogue-heavy works.

I would, at a first blush, disagree with that characterization? Dialogue equals more fine-grained strokes and more individual, independent “zones” to encode.

I wonder if the text would be consistent enough for JXL's "patches" feature to work well.

Now I'm really curious. If anyone has more time than me they could do some sample compressions and I'd be interested in the results.