Last modified: 2009-12-30 22:40:52 UTC
the current thumbnailing system while reasonable for photographic jpegs isn't a great deal of use for anything else furthermore the inability to replace an image with one in a different format is a pain furthermore the inability to rename during upload is a pain all theese issues are to some extent intertwined i think the real soloution involves 1: letting users select the output format (including bitdepth/jpeg quality) when making a thumbnail 2: letting the output format for all thumbnails of a particluar image 4: stripping the file extention from uploads and storing that seperately elsewhere (maybe a file extention on the images filesystem is needed but it shouldn't be in the page name of the image page). ie if we currently have a jpeg of an image and we can get hold of the file the jpeg was made from then we can upload a lossless png for archival, tell mediawiki its thumbnails should be jpegs and not impact its use in articles at all (other than the marginal increase in quality)
sorry entry 2 should have been 2: letting the output format for all thumbnails of a particluar image be set through the image description page with sensible defaults (something like 4 bit png for originals that are 1 or 2 bit, 8 bit png for originals that are 4 or 8 bit, 24 bit jpeg for everything else). It might be an idea to count colors in the original image and base our descisions on that rather than the originals actual bitdepth.
This would be super-yummy if I could upload complex line art in SVG, PS, or PDF format (which can't be embedded on the page in most browsers), and specify thumbnails to be rendered in PNG format.
I would love to be able to upload PNG photographs (converted from TIFFs taken from the Library of Congress) and specify that the thumbnails used in articles are JPG.
(bug moved from other category) I just noticed and I am re-reporting that still this bug appear to be present: "When uploading new images, the small-scale version shonw on the description page is not updated, i.e. shows the small version of the formerly uploaded version" Remark; yes, I cleared all browser caches and fully restarted the browser to exclude local browser problems. This bus is now reported after a quick verification test for _1.5alpha1_ implementation. I will investigate, whether this bug is also in the current CVS version.
it seems like a comment somehow got posted to the wrong bug number and renamed the bug report in the process. anyone have any idea whats going on?
http://bugzilla.wikimedia.org/show_activity.cgi?id=1757
ok undoing changes that appeared to have been caused by mispost as per the log that brion posted
The quality issue may get solved by the proposed patch from bug 3083. The proposed solution does not require/allow user decision about the quality; it does things automatically. See bug 3083, comment 11 for some more explanations. > This would be super-yummy if I could upload complex line art in SVG MediaWiki has been "SVG-ready" for quite some time now. All you need to do is to get an enternal SVG renderer, configure it and enable SVG support in LocalSettings.php. ImageMagic provides only incomplete support for SVG (and requires additional support libraries as well).
This post can explain why it would be useful to have different image types under the same title: http://ultimategerardm.blogspot.com/2009/01/tiff-and-opportunity.html.
(In reply to comment #0) > > furthermore the inability to replace an image with one in a different format is > a pain That's bug 20971 - Upload new versions of files with different file type. > furthermore the inability to rename during upload is a pain WFM > 1: letting users select the output format (including bitdepth/jpeg quality) when > making a thumbnail I don't see this happening. Users shouldn't be confronted to that kind of internal complex stuff. > 2: letting the output format for all thumbnails of a particluar image That's bug 1316 - Allow image thumb output format to be specified. This could probably be done as an extension that *could* also deal with specific options such as bitdepth/quality if you really want it. > 4: stripping the file extention from uploads and storing that seperately > elsewhere (maybe a file extention on the images filesystem is needed but it > shouldn't be in the page name of the image page). That's bug 4421 - Image file extension should not be part of the name. Closing as INVALID since it's a mix of duplicates.
(In reply to comment #10) > > 1: letting users select the output format (including bitdepth/jpeg quality) when > > making a thumbnail > > I don't see this happening. Users shouldn't be confronted to that kind of > internal complex stuff. > It would also not scale: we would have to store different versions of thumbnails for users with different preferences, which means a few of those options would roughly double or space requirements for thumbnails.
