After looking closer at this issue, I learned that PNG images without an alpha channel (no transparency) are converted to JPG.
This can easily be seen with my demo page. Both sets of images were PNG on upload, but the ones with the white background were converted to JPG. (Confirm by checking the page with browser dev tools.)
This is especially problematic when already-optimized PNG images having fine detail (screenshots with small text, for instance) are uploaded. The degradation in quality is much more noticeable. It’s not clear if this is a bug, but it seems there should be a way to bypass Imgix.
Anyone know of a way around this, short of using an HTML element to directly reference the master file on Amazon S3? Any info or insights appreciated!
p.s. The “solution” adopted by the user in this post is far from ideal since the “conversion” website that was used really just base64-encodes the PNG image, which of course bloats the image data.
Is it that the uploaded image is converted to jpeg and stored as that, or is it that the non-alpha png is sent down to the browser as jpeg?
What I’m suggestion is what happens if you source the image as :processed with imgix (quality 100)… Does that force native format maybe?
I haven’t messed around with that much and an away from desktop or I mighta just tried it real quick!
The uploaded “master” image saved to S3 is unaltered - i.e. remains PNG. What’s served by Imgix (to the browser) is JPG.
No, I tried that. Has no effect. You can even specify PNG format in the ImgIx options, but no joy.
That explain a lot. I only recently started noticing this. This is very problematic and not very ideal. I recently started working on UI and this stood out as a problem.
Has there been any solution to this? I’m running into the same problem.
Hi, as you may have noticed by now, all images inside image elements are served via Cloudfront and processed to be served as highly compressed jpgs.
This is also the case for pngs without transparency, and it isn’t a bug, but rather a design choice to give users the best performance out of the box.
I understand that it may result in visibly poor image quality for small PNGs, but since most cases we encountered to date involved very high resolution retouched photos, this default behavior was quite satisfactory and gave very acceptable quality for all intents and purposes.
We are working on a way to add advanced features like disabling this processing step to the property editor without making it too cluttered ; in the meantime you can bypass this by serving the master image from S3 inside an HTML element as suggested above, or by appending ?ignore_imgix to the image source property inside the image element.
Since this is a hack, you should expect expect worse loading times as you are bypassing our edge caching engine.
Adding an alpha channel to your image can also solve your issue but it may be more time-consuming to do so.
We will make sure to notify when we add these advanced settings to our image elements!
Sweet. Thanks, @aless. That’s a good stopgap solution.
I would also note that highly optimized PNG’s can be quite small. I routinely get 50-70% reduction (with no noticeable degradation in image quality) using https://tinypng.com for PNG’s with alpha, so it makes sense to bypass Imgix in those cases, assuming it’s a one-off image for design / UI purposes.
This topic was automatically closed after 14 days. New replies are no longer allowed.