search

FossifyOrg / Gallery

Browse your memories without any interruptions with this photo and video gallery
https://www.fossify.org
GNU General Public License v3.0
1.78k stars 61 forks source link

[BUG] Low resolution AVIF decoding (~720p for 4k image) #252

Open ThomasBaruzier opened 4 months ago

ThomasBaruzier commented 4 months ago

Checklist

Affected app version

1.1.0

Affected Android/Custom ROM version

Android 14 / HyperOS 1.0.2.0

Affected device model

Mi 11 Ultra / SD888

How did you install the app?

F-Droid / IzzyOnDroid

Steps to reproduce the bug

Download this image:

4k-816-48-svt avif

Rename the extention from .avif.jpg to .avif (github won't let me upload .avif files) Open it in Fossify gallery

Expected behavior

Decoding at the resolution of the image given 4k image -> 4k decoding (or progressive, based on screen resolution)

Actual behavior

~720p decoding

Screenshots/Screen recordings

Fossify, when zooming:

Screenshot_2024-07-03-09-05-11-605_org fossify gallery

Firefox android, when zooming:

Screenshot_2024-07-03-09-14-26-910_org mozilla firefox-edit

Additional information

Image compressed using latest avifenc git and svt av1 psy git, resolution 3060 × 4080. Seems to happen with every avif image out there.

OkyDooky commented 2 months ago

Adding this here:

awxkee commented 1 month ago

Adding this here:

AVIF and HEVC, WEBP are video codecs, that means they encode and decode the whole frame at one shot, so this won't be probably ever done because codec are not designed for that.

Decode the whole frame, then do rescale or crop ROI is the only option for ROI decoding for adopted video codecs. Even if android supports ROI decoding of Webp/Hevc it is done this way by someone who made BitmapRegionDecoder.

This is very unlikely to be provided be libavif, because this is unrelated to decoding or encoding, not a common use case, and crop is easy to do when you need to.

DoS007 commented 1 month ago

Can confirm this issue, I have an avif image with untypical resolution and the displayed quality is bad (much worse than it is on computer). I need to zoom in to see it, because image is big (14000 height or so).

OkyDooky commented 1 month ago

AVIF and HEVC, WEBP are video codecs, that means they encode and decode the whole frame at one shot, so this won't be probably ever done because codec are not designed for that.

Decode the whole frame, then do rescale or crop ROI is the only option for ROI decoding for adopted video codecs. Even if android supports ROI decoding of Webp/Hevc it is done this way by someone who made BitmapRegionDecoder.

That makes sense. But, the question again is: where does this get implemented? In the decoder plugin you made or in the Gallery app itself? It'd be nice if the solution is easy enough to implement and maintain. Also,

HEVC

Wut? AVIF is based AV1 and WebP is based on VP8. How does HEVC factor in?

This is very unlikely to be provided be libavif, because this is unrelated to decoding or encoding, not a common use case, and crop is easy to do when you need to.

Well, one of the main contributors to libavif said in the second issue that:

Adding some avifCropRect cropOutput to avifDecoder might be worth discussing though.

So, it's not impossible. But, that was in 2022 and I don't think we want to just wait on them if this is reasonably solvable sooner.

awxkee commented 1 month ago

That makes sense. But, the question again is: where does this get implemented? In the decoder plugin you made or in the Gallery app itself? It'd be nice if the solution is easy enough to implement and maintain. Also,

This is just one loop in JNI. You can load bitmap by any loading system, crop in jni and recycle.

Wut? AVIF is based AV1 and WebP is based on VP8. How does HEVC factor in?

HEVC is base format for image files known as .heic/.heif

OkyDooky commented 1 month ago

That sounds simple enough.

HEVC

Ah, got it. I was confused, because you used the image formats for the other two, and I don't use heif or heic. Thanks for clarifying.

awxkee commented 1 month ago

That makes sense. But, the question again is: where does this get implemented? In the decoder plugin you made or in the Gallery app itself? It'd be nice if the solution is easy enough to implement and maintain. Also,

For JXL, I may provide software ROI extraction. I'm not completely sure that I want to do it, because there are many other things more important things to handle there, but if this sounds reasonable and someone will implement it here I can consider it. And purpose of this still a little unclear, because you still need a generic option for AVIF here, and it is exactly the same as crop of any other existing Bitmap.

OkyDooky commented 1 month ago

I was just going to ask if using the crop method would be a good temporary solution for JXL until libjxl adds the ROI decoding feature properly.

And purpose of this still a little unclear, because you still need a generic option for AVIF here, and it is exactly the same as crop of any other existing Bitmap.

I'm not quite sure what needs clarifying. 🤔

awxkee commented 1 month ago

What I can do ( or someone else ) it is completely different from libjxl can do. So if I'll add this the are definitely will be questions: why I can't decode image "many thousands"x"many thousands" if there are crop, and this crop just misleading on its purpose. So, the question is: why is not common case, that misleading on its purpose, should be added if it has no advantages other same implementation by 3rd party that requires it?

OkyDooky commented 1 month ago

If I understand you correctly: you're wondering why we would want a feature that is subpar to a "real" implementation? I'm re-reading the thread, but I'm not sure how a ROI crop would be misleading, especially for AVIF. For JXL, my idea was that it would be a temporary "band-aid" solution. It seems the ROI API stuff for libjxl is intended to be implemented after its 1.0 release, but that feature may still be a year away from actually getting in. I think having something that works "at all" would be desirable by most JXL/AVIF users while we wait for a full solution.

how come I can't decode gigapixel images???

I think it'd be more likely people would complain on this app's GitHub than on your decoder's, but they may just need to be told it's a limitation of their device (except in the cases where it is explicitly is a software limitation). We could even pin an issue about it if it does seem to be a common complaint.

awxkee commented 1 month ago

I'm re-reading the thread, but I'm not sure how a ROI crop would be misleading, especially for AVIF.

If I'll do so it will be part of decoding JXL pipelane and won't work for avif. And for AVIF you will still need to do it yourself, and it is unclear then why it should be added to JXL if you still need to do it for AVIF, and solution for AVIF will work for both where for JXL is not.

I'll think about that.

libjxl is intended to be implemented after its 1.0 release

I won't update libjxl until this issue is resolved. I'm a little sceptical that they are going to resolve this one at all. There is already nothing worthy for this size against avif, and increased size in almost twice makes this completely useless to me. It'd be easier to abandon jxl-coder rather than maintain if there will be some incompatibilities with 1.0.