-
Notifications
You must be signed in to change notification settings - Fork 6.1k
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
JPEG images loaded from disk cache look weird #63
Comments
Thanks, hope you find it useful! I think I've seen a similar quality issues on certain devices. Are you seeing this on a particular device and/or version of Android? If you try simply writing the decoded jpeg to a temporary file and then decoding it, does the newly decoded bitmap have the same quality issues? The image is written to disk using the framework Bitmap#compress method and the code is pretty straightforward here: As far as I can tell we do use the quality you set, though the default is definitely < 100. |
It is not on some specific device, since I have tested it both on my Galaxy S4 and 2 emulators. |
I'm looking in to this. Can you paste the Glide.load... line you're using? I'm guessing one of the transformations or the downsampling may reduce the quality, but I haven't been able to replicate this yet. |
I'm not using anything fancy, just a Glide.load(url).listener(x).into(imageView) (the listener is just for a fadein animation, since I want it to happen even when the item comes from cache; there should be a setting for that btw). |
Thanks for being willing to look in to this. Saving to the cache happens in my earlier link (which we seem to have established is not the issue), loading the image into memory happens in the downsampler (https://github.com/bumptech/glide/blob/master/library/src/com/bumptech/glide/resize/load/Downsampler.java). When you just use load().into(), there is a transformation also (https://github.com/bumptech/glide/blob/master/library/src/com/bumptech/glide/resize/load/Transformation.java#L33). Using load().asIs() should disable the transformation, but it's always possible there's a bug. |
Hmm... After looking a little into it, it seems that the framework Bitmap#compress is the culprit: it seems that whatever quality setting one sets, there is always a quality degradation. Other peopler seem to have the same problem (see https://groups.google.com/forum/#!topic/android-developers/q7oysr45kSI and https://groups.google.com/forum/#!topic/android-developers/C3savvS2pqs) and the only real solution I saw was "save it using a lossless format -> PNG". |
We can absolutely add an option to make this possible, though it will require changing the code. I'm not sure why no one else has brought it up, I can definitely see it being a framework issue. If you want to put up a pull request to add this yourself, please feel free! Your best bet is to revive setBitmapCompressFormat: https://github.com/bumptech/glide/blob/master/library/src/com/bumptech/glide/resize/ImageManager.java#L231. You can just set a bitmap compress format as an instance variable in ImageManager (default to null if none is set rather than the current JPEG), and then change the compress code (https://github.com/bumptech/glide/blob/master/library/src/com/bumptech/glide/resize/ImageManager.java#L527) to use the given compress format if it's not null, or continue to do what it's doing now if the compress format is null. |
Going to call this closed, feel free to reopen if you still see issues. Thanks for reporting and looking in to this! |
I have a problem on my Moto X. I think it might be related. I use Glide to load the images in a ListView (lazy) in the getView method of my list adapter. I notice the banding, especially on the images that have smooth gradients. The images look fine in Chrome browser though. And it's not only the disk cache, unless Glide first writes the files after downloading, then reads from disk and then loads them into the ImageView. The code that I use: Glide.with(this.context)
.load(targetUrl)
.override(500, 500)
.placeholder(R.drawable.artwork_placeholder)
.thumbnail(0.1f)
.into(target); I use Glide 3.3.1 |
You're probably seeing the same issue as described here, but the API to change the format has changed: BitmapPool bitmapPool = Glide.get(context).getBitmapPool();
StreamBitmapDecoder decoder = new StreamBitmapDecoder(Downsampler.AT_LEAST, bitmapPool,
DecodeFormat.ALWAYS_ARGB_8888);
Glide.with(yourFrament)
.load(url)
.asBitmap()
.imageDecoder(decoder); I know this is rather clunky, so I opened #177 to track making this easier. |
Thanks, that works, but I still have the problem when writing to disk. Sorry, I'm not that familiar with Glide, could you post the code to always write as PNG? And it's not that it's clunky, I think you just should add the above code to the wiki. It also seems that when using .asBitmap(), there is no fade-in animation when the images are loaded, how could one fix that? |
Sorry for the slow response. The cross fade animation is done using a TransitionDrawable. Since asBitmap() means you load a bitmap, we can't automatically do the crossfade for you. That said, you can use a normal view animation using on one of the You can use Just FYI, compressing a given Bitmap to a PNG often takes around 10x longer than compressing the same Bitmap to a JPEG. The biggest difference in quality should be using ARGB_8888, so it might be worth just playing the the jpeg compression level and seeing if you can get acceptable quality without always using PNGs (assuming you don't have all transparent images). |
The problem is, when you compress a JPEG image that was already compressed, the artifacts from the previous compression get worse and become very apparent. The way around this would be downloading the JPEG file and saving it directly to disk, without tinkering with it. |
Interesting, makes sense. In that case you you should take a look at the Using SOURCE or ALL will make Glide download the bytes of whatever image you request directly into the cache and then decode the original untouched image. ALL will also cause any thumbnail you create (using a transformation or by downsampling) to be cached as well so if you want the highest quality possible SOURCE is probably your best bet. ALL might make sense if you also want to show small thumbnails where quality matters less. |
Also I did some digging today and there is an issue here. Using either |
I opened a separate bug for tracking the |
Hi, I have been using this library in my new project and I must say it is amazing!
The only issue I have is that when jpeg (not png, those are absolutely fine) images are loaded from disk cache, they look like their color palette has been reduced; white gradients take a greenish hue, etc.
This only happens when using disk cache, since when the images are first downloaded (or loaded from memory cache), they look fine.
I tried setting the image compression quality of the ImageManager to 100 with no apparent effect.
Any help would be appreciated...
The text was updated successfully, but these errors were encountered: