FossifyOrg
feat: jxl support
What is it?
- [ ] Bugfix
- [x] Feature
- [ ] Codebase improvement
Description of the changes in your PR
- added JXL (still) decode support
Fixes the following issue(s)
- Fixes #3
Relies on the following changes
- https://github.com/FossifyOrg/Commons/pull/56
Acknowledgement
- [x] I read the contribution guidelines.
I had to relocate jcenter below mavenCentral. for some reason it refused to pick up jxl-coder-glide without relocating it.
Decoding seems to be rather slower then expected, but still fast enough for general use.
large images seem to fail with this, unsure if due to resolution or too much resources needed for decoding. it could be both. however all of the images I have that are reasonably sized work with this.
it's unlikely to be able to support animated JXL's using the glide plugin https://github.com/awxkee/jxl-coder-glide/issues/1 this is something that can be visited at a later date.
I've tested converting PNG/JPG images to JXL using an app from the PlayStore, as well as ImageToolbox (FOSS ver) and in both cases, the image seemed to be much lower resolution than the original. I thought it was an issue with the PlayStore app, so I emailed the developer and reported it. However, after getting the same thing with ImageToolbox, I'm wondering if this is an issue with the Gallery app. I also compared using Oupson's JXL Viewer and it showed a cleaner and sharper image, despite not being able to zoom past 100%. Speaking of, I think his fork of this gallery app also has a similar problem.
Can this be confirmed? Best way to reproduce it would be to convert an existing on-device image using either of those apps and then compare them in the gallery and then the JXL one between the gallery and the jxl-viewer. But, even just viewing a better-than-decent resolution JXL file that you know looks good and seeing if it looks different or more pixelated here.
It seems to be related to the decoder, as ImageToolbox is having what sounds like a similar issue: https://github.com/T8RIN/ImageToolbox/issues/893
It gets weirder, apparently: https://github.com/T8RIN/ImageToolbox/issues/1202#issuecomment-2227155856
I tested Fossify with some Avifs I made using ImageToolbox and it had the same issue. It seems someone else encountered that, as well: https://github.com/FossifyOrg/Gallery/issues/252 Something's up with these custom decoders. I know it's the custom one for Avif, as well, since Simple Gallery Pro and Aves (both of which use the native/on-device decoders for Avif) showed the converted images as blank. On Android 13, btw.
I tested Fossify with some Avifs I made using ImageToolbox and it had the same issue. It seems someone else encountered that, as well: #252 Something's up with these custom decoders. I know it's the custom one for Avif, as well, since Simple Gallery Pro and Aves (both of which use the native/on-device decoders for Avif) showed the converted images as blank. On Android 13, btw.
This is almost definitely not related to decoder but for rendering. For high quality render of subsample you need to have a good resampling ( lanczos3 for example, which doesn’t exists on android ) proper chosen target size where you’ll render into, proper chosen sampling size, and for upscaling you have to have high quality upsampler, or method to smoothly replace your subsampled image with original ones, or in another way use OpenGL/Vulkan surface to render an original image and use projection matrices to scale/downscale an image. This is almost clear that implementation of rendering “just use glide/coil” won’t work this way and misses all the points of quality rendering. Jxlviewer shows better results due to down sampling is not used so that will lead to crashes with OOM or “attempt to draw an image larger than ~100mb in memory” and overkilling memory consumption for huge images, and this one is the mistake also.
So, in general, it is not possible to achieve real “high quality render” without considerations of complex resampling methods, uneasy at start projection matrices with gpu surfaces, huge memory consumption, and easiness of integration where you’re just adding 1 line to gradle and ready to go
Thanks for clarifying. That sounds like it might be a lot of work. But, if it's not a decoder issue, where would the effort need to be focused and applied? The app itself? I was thinking decoder, partly because someone else mentioned that, but also because I didn't think unique rendering code would be needed per format. 🤔
Thanks for clarifying. That sounds like it might be a lot of work. But, if it's not a decoder issue, where would the effort need to be focused and applied? The app itself? I was thinking decoder, partly because someone else mentioned that, but also because I didn't think unique rendering code would be needed per format. 🤔
At least you might always choose different pipelines for grid rendering where you just need a lot of small samples, and restrict downscaling as much as possible until you drop stability of the app at the places where you need the exact image
I guess what I'm wondering is if this needs to be a change made specifically to Fossify Gallery itself. Because, it currently sounds like a lot of labor, potentially, and I'm a little worried it may take a while for someone both qualified and interested in implementing this to come along.
Haven't found a leak but this seems to cause excessive memory usage: https://github.com/FossifyOrg/Gallery/issues/301
