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
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
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
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?
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
> 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.