Last modified: 2014-11-19 18:13:21 UTC
(bug 46936 comment 2) > However what we could do is never serve the original as a thumbnail. > The original is always available if a user visits the "File" > description page and downloads it, but when an article embeds an image > at a size that happens to not have a smaller thumbnail size available, > we currently serve the original. We could probably change that to even > serve a thumbnail for the nominal size (like we do with SVGs), which > would presumably make our urls a lot more consistent and allows for > better optimisation of smaller images.
Sometimes people optimize the original for a specific use case.
(In reply to Bawolff (Brian Wolff) from comment #1) > Sometimes people optimize the original for a specific use case. Do we have a vague idea how often that happens?
(In reply to Andre Klapper from comment #2) > (In reply to Bawolff (Brian Wolff) from comment #1) > > Sometimes people optimize the original for a specific use case. > > Do we have a vague idea how often that happens? Not really. I would guess probably not very often. Cases i could think of - apng files, demos for some particular feature (e.g. maybe on an article about exif, it would include a file with specific color profile) Its also possible that this may increase the size of some files Anyways code wise this is a one line change. I think more research would be needed to see if its a net benefit (or even if it has an appreciable effect at all outside of a few edge cases)
In the closed bug that Krinkle was referencing the concern was that some original image assets are being served instead of optimized ones. My impression now is that if the requested dimensions are greater than the original, then the original (unoptimized) file is served. If a copy of the original image was compressed and served instead then I think there could be real bandwidth-saving gains. There is an attachment in that other bug showing some good lossless file size reduction for PNGs currently being served to users.
I think the opposite happens as well: the thumbnailer currently screws up some image types (I've seen transparent images and animated images mentioned in bug reports). I think including the original image if that is explicitly what is requested (ie, the 'frame' image option) is a good solution. I don't think we should *always* serve images from the thumbnailer, unless/until we add a special case to the thumbnailer to pass through certain image types unmodified.
Having had some additional experience with OCG, I'm leaning more toward comment 4 -- I've seen a lot of really terribly-encoded files, with crazy density settings and garbage EXIF and other strange stuff. Having uniform thumbnails would probably be an improvement.
