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 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.
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.
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.
It's not a case of GIF nostalgia 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.
the mimetype is important and it is set consistently.
given one uses direct urls to the scale one would get: http://host/Plone/myimage.gif/@@images/image/mini which could be confusing.
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.
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.
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.
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.
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?