Last modified: 2009-12-30 22:40:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3757, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1757 - improving the images/thumbnailing system
improving the images/thumbnailing system
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-26 01:08 UTC by peter green
Modified: 2009-12-30 22:40 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description peter green 2005-03-26 01:08:18 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)
Comment 1 peter green 2005-03-26 01:15:18 UTC
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.
Comment 2 Michael Zajac 2005-04-12 22:26:18 UTC
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.
Comment 3 David Benbennick 2005-06-29 15:24:04 UTC
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.  
Comment 4 T. Gries 2005-07-10 13:14:49 UTC
(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.
Comment 5 peter green 2005-07-11 00:10:44 UTC
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?
Comment 7 peter green 2005-07-11 01:18:30 UTC
ok undoing changes that appeared to have been caused by mispost as per the log
that brion posted
Comment 8 Klaus Stock 2005-08-15 13:39:23 UTC
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).
Comment 9 Nemo 2009-01-19 14:47:18 UTC
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.
Comment 10 Guillaume Paumier 2009-12-30 17:26:15 UTC
(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.
Comment 11 Roan Kattouw 2009-12-30 22:40:52 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links