Bloated JXL Output/Final Output Size Not Matching Preview Estimate about imagetoolbox HOT 14 CLOSED

Well, at least it's noted. But, I'll leave that aspect for the upstream parts, like Awxkee's coder and libjxl proper.
Thanks for bearing with me, regardless.

from imagetoolbox.

For comparison, I do not have this issue with this app: https://play.google.com/store/apps/details?id=ebusky.jpeg.xl.image.viewer.converter

from imagetoolbox.

i will check 😃

from imagetoolbox.

Thanks! Also, the input file size is only 2.5MB! Not sure how it got so large, then. (12MP, if that has anything to do with it: 3024 x 4032)

from imagetoolbox.

Maybe that my fault, and i'm passing wrong args, but if not, that's may be related to libjxl or coder which i use

from imagetoolbox.

Hopefully it's an easy fix. I found this, because I'm trying to help with getting JXL support into Fossify Gallery and I'm helping QuackDoc test his PR. It seems that all viewing apps suffer from the decoder (my guess), because all of them show a lower-resolution version than the actual file. The only one that seems to show it correctly is https://github.com/oupson/jxlviewer except it doesn't zoom in past 100% and isn't a gallery app.
So, there could be something funky with the libjxl implementation for Android, in general. Maybe something changed recently, because the PlayStore app I linked was last updated in Feb. of this year.

from imagetoolbox.

Try to open it in image preview screen

from imagetoolbox.

Is that the +Magnifier button in the upper right (like in the second screenshot)?

from imagetoolbox.

It's in the third section

from imagetoolbox.

Got it.
Well, that's weird. I imported the JXL of the flowers and the JPG original and the JXL looked crappier. But, after going back and forth, then it looked fine at some point? Hmmm.
But, weirdly, one other file that I converted twice with this app had one that looked just as bad as I described, while the first attempt now looked fine(ish).
...okay, hold up. I just imported the original for that other image just to see (since I couldn't remember if I did anything different with the settings between the two conversion attempts) and I didn't notice anything different between it (the original) and the first attempt. So, I checked the second attempt and...it looked just as fine as the other two. It definitely looked way worse before. And this is all in one session (I didn't exit out of the Image Preview during making this post).
That seems like it might be the decoder, after all. 🤔

from imagetoolbox.

interesting indeed, i have no idea what's wrong 🧮

from imagetoolbox.

Theres update in libjxl and jxlcoder, maybe that will help

from imagetoolbox.

Okay. I'm using Obtainium. So, as soon as the new binary releases for ImageTooolbox, I'll test it out and let you know if it's working for me.

from imagetoolbox.

I think I need to either rename this issue or create a new one, because it isn't just JXL that's having this problem. I tested converting to MozJpeg, WebP, and Avif and all of them came out much larger than the preview file size claimed (I think it even low balls the input size, saying a 2.2MB PNG was 1.0MB). MozJpeg also came out massively bloated compared to what it should be. That 2.2MB PNG turned into a 597KB Jpeg when converting using Aves Gallery (which uses the system's built in libjpeg-turbo) at Q=93, while ImageToolbox output a 924KB Jpeg when using MozJpeg at Q=85! And the preview estimated it would be around 171KB.
Update: just tried converting that PNG to Jpeg (using the Jpg setting) in ImageToolbox using Q=93 and it output to 1MB (preview said 302KB), which is roughly double what Aves output.

from imagetoolbox.