• Bug 8357 has been marked as a duplicate of this bug. ***

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.

attachment crop.patch ignored as obsolete

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]]

attachment crop.patch ignored as obsolete

Updated patch

Lousy hackish support for svg

attachment crop.patch ignored as obsolete

new patch

tried to get the svg cropping to work, it works some times, but not always :(

attachment crop.patch ignored as obsolete

same patch

forgot a file (MessageEN.php)

attachment crop.patch ignored as obsolete

Bryan.TongMinh wrote:

Fixed in r54745 with syntax [[File:foo.jpg|<width>px|crop=<left>x<top>x<width>x<height>]] with all parameters after left optional.

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.

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

mdale wrote:

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

loustyx wrote:

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]]

loustyx wrote:

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)

RSYQFIOJGWZA wrote:

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

timothyausten wrote:

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

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.

mdale wrote:

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

Thehelpfulonewiki wrote:

Reassigning to wikibugs-l per bug 37789

See also bug #37732

sumanah wrote:

Comment on attachment 2964
same patch

Marking patch as obsolete given its reversion in comment #8.

Adding to tracking bug 37883.

Since Wikimedia Commons policy doesn't allow to override file with other content, implementation of this won't affect selected images in future.

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

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

mdale wrote:

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.

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

(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

mdale wrote:

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.

This bug is here since 2006. We have solution, we have approval. Can someone implement it?

• Bug 19473 has been marked as a duplicate of this bug. ***

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.

(Edit: that bug is now T37756.)

I had opened T207883, unaware of this request.

Having read this, can we simplify this? Just allow something like this:

[[File:Gold coin both sides.jpg|thumb=File:Gold coin heads.jpg|thumb|Gold coin, click to see both sides]]

Leave it to users to create separate files with crops using CropTool or any other method.