Last modified: 2014-11-17 09:21:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7757 - allow cropping images when rendered
allow cropping images when rendered
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 8357 19473 (view as bug list)
Depends on:
Blocks: commons
  Show dependency treegraph
 
Reported: 2006-10-30 10:41 UTC by David Monniaux
Modified: 2014-11-17 09:21 UTC (History)
21 users (show)

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


Attachments
patch anabling somewhat functionallity (5.23 KB, patch)
2006-12-22 22:45 UTC, Carl Fürstenberg
Details
updated patch (6.86 KB, patch)
2006-12-23 02:06 UTC, Carl Fürstenberg
Details
Updated patch (8.96 KB, patch)
2006-12-23 02:38 UTC, Carl Fürstenberg
Details
new patch (9.64 KB, patch)
2006-12-26 20:53 UTC, Carl Fürstenberg
Details
same patch (10.76 KB, patch)
2006-12-26 20:55 UTC, Carl Fürstenberg
Details

Description David Monniaux 2006-10-30 10:41:33 UTC
Allow cropping when specifying thumbnailed images.

Currently, if one wants to show only a detail of a photograph, say, isolating
the head of a person, one has to download the photo, crop it and reupload it.
Comment 1 Brion Vibber 2006-12-22 18:03:51 UTC
*** Bug 8357 has been marked as a duplicate of this bug. ***
Comment 2 Carl Fürstenberg 2006-12-22 22:45:45 UTC
Created attachment 2925 [details]
patch anabling somewhat functionallity

Have tried to enable this functionality, not an easy task :) at the moment it
only works when using imagemagick and when resizing the image, but I belive
it's an start.
Comment 3 Carl Fürstenberg 2006-12-23 02:06:38 UTC
Created attachment 2928 [details]
updated patch

made some major modifications to the patch, this I think works better. the
syntax for cropping an image is:

[[Image:Foo|crop=width:offset*height:offset]]

can be combined with resizing:

[[Image:Hawk eating prey.jpg|crop=900:300x400:900|300px]]
Comment 4 Carl Fürstenberg 2006-12-23 02:38:27 UTC
Created attachment 2929 [details]
Updated patch

Lousy hackish support for svg
Comment 5 Carl Fürstenberg 2006-12-26 20:53:46 UTC
Created attachment 2963 [details]
new patch

tried to get the svg cropping to work, it works some times, but not always :(
Comment 6 Carl Fürstenberg 2006-12-26 20:55:29 UTC
Created attachment 2964 [details]
same patch

forgot a file (MessageEN.php)
Comment 7 Bryan Tong Minh 2009-08-11 14:21:33 UTC
Fixed in r54745 with syntax [[File:foo.jpg|<width>px|crop=<left>x<top>x<width>x<height>]] with all parameters after left optional.
Comment 8 Brion Vibber 2009-08-19 02:07:58 UTC
I'm not fond of this syntax or implementation; reverted in r

Reverted:
r54748 "Making demon happy (adding public/protected to function definitions) and add some comments along the way."
r54746 "Update formatting for r54745"
r54745 "Added crop support for inline images."

Several issues:
* Implementation is ImageMagick-specific, no support for GD backend
* Specification syntax is pretty ugly and non-obvious imo... [[File:foo.jpg|<width>px|<left>x<top>x<width>x<height]]
* Crop syntax seems to be tied to pixels... I _presume_ source pixels? This would break if a file is re-uploaded with a new size.
* In general I'm very leery of tacking on more infinite-options-in-infinite-combinations for image rendering; our treatment of resizing already has implications for CPU and disk usage and this just adds another level of arbitrary-rendered horror. ;)

I'd much rather we move towards limiting the number of rendered variants we have, not increase them... IMO cropping would be better served with an interface allowing for explicit, visible cropping which creates either a new saved version, or a 'cloned' virtual file which can be referred to by name... and more importantly, uses of it would be trackable so that if crops needs to be updated they can be cleanly.
Comment 9 Guillaume Paumier 2009-12-30 20:51:45 UTC
(In reply to comment #8)
> IMO cropping would be better served with an
> interface allowing for explicit, visible cropping which creates either a new
> saved version, or a 'cloned' virtual file which can be referred to by name...
> and more importantly, uses of it would be trackable so that if crops needs to
> be updated they can be cleanly.

I couldn't agree more with that.
Comment 10 Michael Dale 2009-12-30 23:04:09 UTC
I don't see much of an issue with treating source assets as a non changing resource. 

In place uploaded destructive updates to source images assets ~should be~ widely discouraged.[1] We should not keep infinite-options non-used images around since they are software transformations and can be re-created and cached as used. In the case of legal destructive transformation like blacking out a logo or privacy personal representation rights ~blurring a face~, we want that to instantly percolate through the derivatives.

Storing procedural transformations as an "new saved version" will in my estimation make it more complicated to prune the infinite-combination unused transformations ~not easier~. Furthermore re-sizing those "new asset" transforms will result in another set of transforms. Or say the parent image is removed for copy-write infringement or you want a high res version of the crop for a book, where the crop was uploaded as a new asset at screen-resolution.

We need a unused image transformation garbage collector for unused arbitrary thumbnails sizes. The same system could be used for cropped images, if we create new assets for these simple transforms it will make this garbage collector more complex. 

== Syntax == 

In terms of crop syntax in the short term I like something like: [[File:Image.jpg|400px|Crop=top:22.423%;left:30.43%;bottom:10%;right:22%]]. I don't like [[Image:Foo|crop=width:offset*height:offset]] because it does not keep the existing size parameter convention, would let you request non-scale transformations, makes you need to do mathematics if you want to re-size the image in page size, and would not scale up well with SVG.

Long term the syntax should integrate it into the "SMIL" frame like representation something like:
http://www.w3.org/TR/SMIL3/smil-extended-media-object.html#q31
or excerpts there of. The ~smil like~ xml could go onto dedicated "Composite" namespace pages.

The ~smil like~ stuff is on its way to be supported via javascript or naively in the browser tool-chain ... so the editor interface that enabled users to crop ( or apply other filters or layered transforms ) in the browsers could also upload the transformation file. ( Modern browsers support canvas and it supports uploading jpg representation of transformations ) ... We could use the browser uploaded transformation system in the short term. In such case as a stop-gab using something like the explicit file interface that Brion described is ideal.

Long term we would want to parallel the transformation description language on the server side and just store the transformation xml, and handle transformation and associated usage caching ( to not store infinite versions of things) all on the server. That we can scale out delivery across platforms and interfaces.  ie browser's won't want to upload the 300dpi crop that will be needed for the book print. When cropping on a cellphone we may want size "A" instead of size "B" reference image. And finally if we start including {{DynamicText}} in svg figures we want to be able to dynamically output static representation per translations or what have you.


[1] http://commons.wikimedia.org/wiki/Commons:Don%27t_be_bold
Comment 11 STyx 2010-05-13 12:46:19 UTC
This is a great idea to limit the proliferation of images. Especially within cartography, it has a small set of SVG maps of great qualities and many maps of subdivisions don't exist. In the present state of things, we will create these missing sub-maps by copying and reframing the original map ; which is a bad way to do that.

How to:
Add a parameter <geometry> to the command  [[Image:...|<geometry>|...]].
The syntax of this parameter <geometry> remains to be defined, but imho, commandes X (see [http://www.x.org/archive/X11R6.8.1/doc/X.7.html#sect6) should be copied.

I don't like :
[[File:Image.jpg|400px|Crop=top:22.423%;left:30.43%;bottom:10%;right:22%]]

Improvement: 
Moreover, this extension could be combined with (or based on) Commons:Help:Gadget-ImageAnnotator (see http://commons.wikimedia.org/wiki/Help:Gadget-ImageAnnotator http://commons.wikimedia.org/wiki/Commons:Using_ImageAnnotator). Then, we will proceed as follows for http://commons.wikimedia.org/wiki/File:Bundesrat der Schweiz 2009 Teil 1.JPG :

[[Image:Bundesrat der Schweiz 2009 Teil 1.JPG#Members of the Federal Council]]
Comment 12 STyx 2010-05-13 13:32:54 UTC
See also http://www.imagemagick.org/www/command-line-processing.html#geometry 

Therefore 

[[File:Image.jpg|400px|Crop=47.57%x77.687%+30.43%+22.423%]]

is a more standard syntax than 

[[File:Image.jpg|400px|Crop=top:22.423%;left:30.43%;bottom:10%;right:22%]]

but 

[[File:Image.jpg#mycrop|400px]]

should be the best using ImageAnnotator (if possible)
Comment 13 Jeff G. 2010-07-31 19:47:25 UTC
The possibility of such a capability was mentioned in http://commons.wikimedia.org/w/index.php?title=Commons:Deletion_requests/File:German_stamp-_Marlene_Dietrich_crop.PNG&diff=41773339&oldid=41764625 and then in http://commons.wikimedia.org/wiki/Commons:Village_pump#When_to_crop_and_when_not_to_crop with the following text: 'If we had image tags that would let us crop in wikitext, perhaps "There is little point in doing crops such as this in any case" might make some sense, but we would have to teach everyone who is using crops how to crop in wikitext. Many original photographers leave a large margin for error when composing their photographs, with the thought "I can always crop it later" - this was what I was taught in photography class. To prefer full images with EXIF metadata, and not allow cropping, flies in the face of classic photography.'
Comment 14 timothyausten 2011-12-05 08:26:23 UTC
(In reply to comment #8)
> I'd much rather we move towards limiting the number of rendered variants we
> have, not increase them... IMO cropping would be better served with an
> interface allowing for explicit, visible cropping which creates either a new
> saved version, or a 'cloned' virtual file which can be referred to by name...
> and more importantly, uses of it would be trackable so that if crops needs to
> be updated they can be cleanly.

Without cropping support, original, uncropped images get orphaned. Also, it would not ruin the simple beauty of wiki markup because it only renders ordinary css.
Comment 15 Erwin Dokter 2012-01-03 13:19:39 UTC
Chiming in here... instead of server-side cropping, the same effect can be achieved with CSS overflow/positioning. Downside is that the entire image is still downloaded, but it is not destrucrive and it only requires that the image be scaled according to the size and cropping desired.
Comment 16 Michael Dale 2012-01-03 18:46:27 UTC
(In reply to comment #15)
> Chiming in here... instead of server-side cropping, the same effect can be
> achieved with CSS overflow/positioning. Downside is that the entire image is
> still downloaded, but it is not destrucrive and it only requires that the image
> be scaled according to the size and cropping desired.

Yea templates exist for that. See:
http://en.wikipedia.org/wiki/Template:Css_Image_Crop

The idea of server side crop transform would be non-destructive creating a local thumbnail.
Comment 17 Thehelpfulone 2012-06-22 19:40:31 UTC
Reassigning to wikibugs-l per bug 37789
Comment 18 Dereckson 2012-06-23 21:02:47 UTC
See also bug #37732
Comment 19 Sumana Harihareswara 2012-10-12 01:43:09 UTC
Comment on attachment 2964 [details]
same patch

Marking patch as obsolete given its reversion in comment #8.
Comment 20 Dereckson 2013-03-26 12:24:51 UTC
Adding to tracking bug 37883.
Comment 21 Rezonansowy 2014-01-09 17:30:42 UTC
Since Wikimedia Commons policy doesn't allow to override file with other content, implementation of this won't affect selected images in future.
Comment 22 Rezonansowy 2014-01-09 17:32:09 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > Chiming in here... instead of server-side cropping, the same effect can be
> > achieved with CSS overflow/positioning. Downside is that the entire image is
> > still downloaded, but it is not destrucrive and it only requires that the image
> > be scaled according to the size and cropping desired.
> 
> Yea templates exist for that. See:
> http://en.wikipedia.org/wiki/Template:Css_Image_Crop
> 
> The idea of server side crop transform would be non-destructive creating a
> local thumbnail.

Yes, agree. That's a good way to do this.
Comment 23 Rezonansowy 2014-01-09 17:34:42 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > Chiming in here... instead of server-side cropping, the same effect can be
> > achieved with CSS overflow/positioning. Downside is that the entire image is
> > still downloaded, but it is not destrucrive and it only requires that the image
> > be scaled according to the size and cropping desired.
> 
> Yea templates exist for that. See:
> http://en.wikipedia.org/wiki/Template:Css_Image_Crop
> 
> The idea of server side crop transform would be non-destructive creating a
> local thumbnail.

This template has been considered as hard to use and they're right. This template has been only a hotfix to do this and needs a regular solution.
Comment 24 Michael Dale 2014-01-09 17:49:06 UTC
The magic of wikitext; once we have a server side solution, this template can just be updated to call that. Likewise with some of the other templates that do similar things.
Comment 25 Rezonansowy 2014-01-11 09:45:18 UTC
(In reply to comment #24)
> The magic of wikitext; once we have a server side solution, this template can
> just be updated to call that. Likewise with some of the other templates that
> do
> similar things.

Could you say more about the your solution? I we have something like this in #c3 we don't need any templates.
Comment 26 Rezonansowy 2014-01-11 09:46:01 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > The magic of wikitext; once we have a server side solution, this template can
> > just be updated to call that. Likewise with some of the other templates that
> > do
> > similar things.
> 
> Could you say more about the your solution? I we have something like this in
> #c3 we don't need any templates.

Ops, should be #comment3
Comment 27 Michael Dale 2014-01-11 14:36:17 UTC
your solution looks good. I was just commenting that once that is implemented, the respective templates could call your code, this way any usage of said template will be seamlessly upgraded to server side based cropping.
Comment 28 Rezonansowy 2014-01-19 12:35:19 UTC
This bug is here since 2006. We have solution, we have approval. Can someone implement it?
Comment 29 Andre Klapper 2014-03-14 11:44:31 UTC
*** Bug 19473 has been marked as a duplicate of this bug. ***
Comment 30 C. Scott Ananian 2014-06-04 21:26:33 UTC
See also bug 35756 comment 13, where cropping functionality is proposed that also allows:

[[File:Foo.jpg|crop|100x200]]

to be an exactly 100x200 image which is scaled and cropped to fit.

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


Navigation
Links