allow cropping images when rendered
OpenPublic

Description

Author: David.Monniaux

Description:
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.

See also T67284: Insert cropped image from Scan, T39732: Wikimedia Commons needs a built-in raster image editor / photo editor


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37732

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz7757.
bzimport created this task.Via LegacyOct 30 2006, 10:41 AM
brion added a comment.Via ConduitDec 22 2006, 6:03 PM
  • Bug 8357 has been marked as a duplicate of this bug. ***
AzaToth added a comment.Via ConduitDec 22 2006, 10:45 PM

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

AzaToth added a comment.Via ConduitDec 23 2006, 2:06 AM

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

AzaToth added a comment.Via ConduitDec 23 2006, 2:38 AM

Updated patch

Lousy hackish support for svg

attachment crop.patch ignored as obsolete

AzaToth added a comment.Via ConduitDec 26 2006, 8:53 PM

new patch

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

attachment crop.patch ignored as obsolete

AzaToth added a comment.Via ConduitDec 26 2006, 8:55 PM

same patch

forgot a file (MessageEN.php)

attachment crop.patch ignored as obsolete

bzimport added a comment.Via ConduitAug 11 2009, 2:21 PM

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.

brion added a comment.Via ConduitAug 19 2009, 2:07 AM

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.

gpaumier added a comment.Via ConduitDec 30 2009, 8:51 PM

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

bzimport added a comment.Via ConduitDec 30 2009, 11:04 PM

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

bzimport added a comment.Via ConduitMay 13 2010, 12:46 PM

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

bzimport added a comment.Via ConduitMay 13 2010, 1:32 PM

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)

bzimport added a comment.Via ConduitJul 31 2010, 7:47 PM

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

bzimport added a comment.Via ConduitDec 5 2011, 8:26 AM

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.

Edokter added a comment.Via ConduitJan 3 2012, 1:19 PM

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.

bzimport added a comment.Via ConduitJan 3 2012, 6:46 PM

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.

bzimport added a comment.Via ConduitJun 22 2012, 7:40 PM

Thehelpfulonewiki wrote:

Reassigning to wikibugs-l per bug 37789

Dereckson added a comment.Via ConduitJun 23 2012, 9:02 PM

See also bug #37732

bzimport added a comment.Via ConduitOct 12 2012, 1:43 AM

sumanah wrote:

Comment on attachment 2964
same patch

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

Dereckson added a comment.Via ConduitMar 26 2013, 12:24 PM

Adding to tracking bug 37883.

Rezonansowy added a comment.Via ConduitJan 9 2014, 5:30 PM

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

Rezonansowy added a comment.Via ConduitJan 9 2014, 5:32 PM

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

Rezonansowy added a comment.Via ConduitJan 9 2014, 5:34 PM

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

bzimport added a comment.Via ConduitJan 9 2014, 5:49 PM

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.

Rezonansowy added a comment.Via ConduitJan 11 2014, 9:45 AM

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

Rezonansowy added a comment.Via ConduitJan 11 2014, 9:46 AM

(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

bzimport added a comment.Via ConduitJan 11 2014, 2:36 PM

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.

Rezonansowy added a comment.Via ConduitJan 19 2014, 12:35 PM

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

Aklapper added a comment.Via ConduitMar 14 2014, 11:44 AM
  • Bug 19473 has been marked as a duplicate of this bug. ***
cscott added a comment.EditedVia ConduitJun 4 2014, 9:26 PM

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

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:20 PM
Nemo_bis awarded a token.Via WebDec 12 2014, 8:03 AM
Chad removed a subscriber: Chad.Via WebDec 16 2014, 7:57 PM
Tgr added a subscriber: Tgr.Via WebDec 17 2014, 2:23 AM
Nemo_bis added a project: Epic.Via WebJan 2 2015, 7:02 PM
Nemo_bis set Security to None.
Nemo_bis edited the task description. (Show Details)Via WebJan 27 2015, 1:25 PM
Nemo_bis edited the task description. (Show Details)
Arjunaraoc added a subscriber: Arjunaraoc.Via WebThu, Feb 19, 5:24 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.