-
Notifications
You must be signed in to change notification settings - Fork 671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support progressive JPEGs / incremental WebP decoding #940
Comments
could be useful - progressive JPEG files are encoded in such way that the browser (or any other software) could load them progressively. I don't think / don't know if android's native bitmap decoder (BitmapFactory.decode) can do this. |
another similar issue on Picasso repo |
It's not possible to support this for generic file types - only JPEGs that have been specially encoded for progressive decoding can do this. Android doesn't support progressive JPEGs so you'd need to write a custom |
I think we have to rely on a C library to decode. Before the time iOS had native support of progressive jpegs, there was Concorde - that was based on libjpeg-turbo. Tubo has java bindings, but the roundtrip time of JNI method invocation is slow on android, would be best to minimise the number of JNI calls. I can try to contribute on this with a pull request. I can write C code but I'm not sure I can write C code well. I'm currently learning rust. Rust guarantees memory safety at compile time, without giving the programmer the reposability to release memory - but at the same time it doesn't have a GC. I can try to write the native part of the decoder in rust (+ libjpeg-turbo or mozjpeg or whatever), and then call rust code from kotlin via JNI. Would that be ok with you? |
Hmm I'd like to keep Coil and any extension libraries 100% Kotlin code (and no native code) since it can greatly increase APK size. If it's only possible with native code then I think this is a good candidate for an external extension library (happy to link to it). |
I'm no expert, but as far as I researched, there is no standard Android SDK way to decode progressive JPEG. Standard Java has ImageIO API that supports it, however those classes also depend on native code, assuming the code could be ported to android. Another option would be libjpeg-turbo or other native decoder library. Fresco also relies on native code. Ideally Google developers should implement some new API on the Android SDK itself for this, starting with Android 13, and another Jetpack support library to backport the feature. This could open possibility to implement this feature on any image loading library, Glide, Picasso, Coil. Submitted an issue on Google Issue tracker to ask for such API. Let's wait to see what is their take on the matter.. |
I'd be surprised if Google implements this in AndroidX since it seems out of scope (androidx also disallows using native libraries), but it's worth submitting a ticket. It's also not clear how much use progressive JPEG sees today; if it's small it might not be worth the large effort to implement. Also, it looks like Also it looks like WebP supports something similar to progressive JPEG so I added it to this ticket. |
Most image loading libraries load the image (from network / disk cache / memory cache) then the image gets displayed into imageview.
Yet browsers can progressively display images as they are downloaded, that is - start the download, display a low quality version of the image, then increase the quality as more parts of the file gets downloaded.
Right now the only android library that can progressively load images is Fresco, as you can see on this page. However, in any other aspect, Fresco seem to be inferior.
This feature can be very useful when loading big images on low bandwidth networks.
Could Coil library implement such feature?
The text was updated successfully, but these errors were encountered: