'plone.scale': GIFs to JPEG? Really?

So we are converting everything but PNG to a JPEG. Fine? No.

Customers sponsor logos are scaled down to JPEG and transparency is converted to black.

I propose to either keep GIF - which may result in poor quality due to a limited palette - or in my opinion better:

Scale to a RGBA PNG.

I'am already in a cleanup of plone.scale (folks, how could we have lived with that so long?) .

So If there is no reason against it I go for changing this (which needs also changes in plone.namedfile and plone.app.imaging).

Target: Plone 5.1

What would be the advantages of converting GIF to PNG? I'd vote for keeping formats as uploaded.

In general all palette based images are converted to RGBA before scale, because scaling palette based images results in poor quality. Then on save to GIF the RGBA is converted back to a palette GIF. This again reduces information and quality. So using a GIF in in my opinion wrong.

Also plone.scale is all about scaling images for the use in the web. Its not meant as a general tool to scale any image. If you need that its better to directly use PIL and optimize for you needs.

Are you saying that the original uploaded is touched as well? Or are original files being stored as-is 1:1?


plone.scale never touches the original.

Are you sure? This is a procedure I'm very used to do in Photoshop and unless you explicitly export the image with either 1) a different dither/color reduction algorithm or, much more impactfully, 2) less colors (from 256 to 128, 64, 32 etc), there's no quality loss when you roundtrip GIF > RGBA > GIF (which is indeed needed for scaling). The colors should be the same iinm. But I don't know how Pillow does it.

Another problem is with animated GIFs (even though that should be broken anyway since all scales were JPGs). Could Pillow detect those, in order to avoid conversions? UPDATE: seems so.

The point is: this is for display in the web.


  • GIF -> RGBA - no information loss
  • RGBA -> Scale down - here the chance that at edges alpha channels or even color blends with opacity different from 0 or 255 are created.
  • RGBA -> GIF - edges and color blends are reduced back to either 0 or 1 opacity and to whats possible with 256 colors while PNG would keep them as full RGBA. So here a reduction happens.

Except if you rely on a crisp 90ies web style I prefer the PNG.

So PNG file size if probably bigger than with GIF, but we could apply option='optimize' on PIL's save to shrink it some bytes....

Since we did not support animated GIF's until now I found this out of scope. But true, we could detect them and in this case keep them a GIF. I think @thet would like to see this too.

1 Like

It's not a case of GIF nostalgia :slight_smile: More of consistency/expectability for users. I mean, I guess we're keeping the object id, which often carries file extension, so we'll serve PNGs named as GIFs? Does this confusion pay off?

I'm not sure I understand this since GIFs may have alpha channels as well.

Lastly, I mentioned Photoshop but I'm only considering transformations aiming web.

GIF defines one index in the palette as transparent. So there is no alpha channel.

Edit: Also SO is helpful: https://stackoverflow.com/questions/1952376/how-to-get-better-transparency-with-gifs

1 Like
  1. the mimetype is important and it is set consistently.

  2. given one uses direct urls to the scale one would get: http://host/Plone/myimage.gif/@@images/image/mini which could be confusing.

  3. given one uses the tag generator the url to the scale gets already the extension: http://host/Plone/myimage.gif/@@images/49f551b9-01b6-4e5a-ad21-667eb9fac7d2.jpeg.

  4. In code I found the case that http://host/Plone/myimage.gif/@@images/image.gif (original) might get generated too, but I have no idea where this may happen.

1 Like

+1 for converting GIFs to PNGs instead of JPEGs.

The old behavior is a bug - converting GIFs to JPEGs instead of PNGs doesn't make much sense to me.
@jensens reasoning about converting GIFs to PNGs make sense - since we have to convert to RGBA anyways, converting back to palette based colors is a loss of information, so better we stick with RGBA and PNGs, which have support for that.

Only concern is about converting animated GIFs. But since this is not supported in any way at the moment we do not break anything. Adding an exception for animated GIFs later is still an option.

Ok, so only #2 and #4 would be inconsistent, which is not as bad, specially if we look at how things are now. I still think the conversion losses would be minimal/inconsiderable because the original will never have alpha channels but I guess we can wait for someone with a bigger itch to complain about it and at this time choose quality over consistency.

Somewhat related:

Using direct links to images to traverse to @@images is something we might not want to do anymore when this PLIP from my colleague Diederik lands in Plone 5.1 to support retina scaling:

Only the the tag generator is able to insert srcset html to fully support this.