Last modified: 2010-07-31 21:31:50 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 9616 - Automatic image watermarking
Automatic image watermarking
Status: RESOLVED DUPLICATE of bug 8298
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal enhancement with 8 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-04-17 15:46 UTC by brianna.laugher
Modified: 2010-07-31 21:31 UTC (History)
4 users (show)

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


Description brianna.laugher 2007-04-17 15:46:47 UTC
example templates: {{DELETION REQUEST}} (watermark should be perhaps a red
copyright (C) symbol with a questionmark, indicating the image has uncertain
copyright status)

{{SUPERSEDED}} (watermark should be... perhaps a large grey cross)

I guess you would make both the trigger template list and corresponding
watermark images customisable.

This would allow better communication of the image management process between
admins and users. At the moment there is no way to see an image in use and
instantly know that is being discouraged from use.
Comment 1 Tim Starling 2007-04-17 16:05:20 UTC
I think it would be technically simpler to place a notification in the HTML
outside the image rather than to change the image itself.
Comment 2 Larry Pieniazek 2007-04-17 16:21:08 UTC
That is true, Tim, but I believe the motivation for the request is the same as
that of any other watermarking... to do something TO the image that makes it
clear what the story of the image is itself, which cannot be easily removed.
However, if there is a way to make the appearance of the image (on any page)
show this information, that cannot be circumvented in wikimarkup, that doesn't
require modifying the image itself, perhaps that's preferrable?
Comment 3 Gregory Maxwell 2007-04-17 16:47:49 UTC
Just a note, on enwiki we've wanted something like this for a while so we could
mark non-free images with a reader visible mark. It might make sense to do this
local feature first.

If the implementation resulted in something in HTML it would have the side
effect of making it possible to suppress it with a preference or with user-css..
which some may like.

One challenge is that if the mark is overlayed there is no one location which
will not be really bad for some images.  Instead the image size could be
increased and the mark left outside the image, or the thumb could be decreased
to make room for it.
Comment 4 Platonides 2007-04-17 17:50:46 UTC
A similar (broader) proposal was given out some weeks ago.
Comment 5 Sherool 2007-04-20 00:08:01 UTC
I proposed a generic system to implement some magic word on image pages that 
would cause a CSS class to be applied to the image in articles. Then it's just 
a matter of editing the global stylesheet/JavaScript to make images with 
scertain classes appear the way we want them to in articles (red borders 
overlayed watermarks, whatever). See Bug 8298 for details.
Comment 6 Judson (enwiki:cohesion) 2007-04-20 02:31:02 UTC
I am more in favor of Sherool's generic system, it could do everything in this
proposal also, but in a more extensible way.
Comment 7 Gregory Maxwell 2007-05-01 02:40:17 UTC
So, what we'll have is a column added to the image table called img_class
(varchar(255)), and a magic word {{MEDIACLASS:css_classname_here}}, when this
magic word ends up on an image page (either via a template or directly) the
image table will be updated to set img_class to css_classname_here. XSS and
other weird stuff will be prevented by some sanity checking on the classname. 
When a thumbnail is  displayed we use the provided class name (taking it from
the cache or the database if it is not in the cache).

I don't think there would be any performance impact from this change and it
should be easy to make it work across the commons/localwiki boundry.  As a
matter of policy we can define a standard naming convention for classes, but
mediawiki doesn't need to know about the policy, it only provides the mechanism.

If people are okay with this, I'll see that it gets coded. 
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-01 02:53:13 UTC
Would a CSS class be sufficient?  It would be difficult to impossible to have
scaling watermarks, for instance; they'd have to be tiled.  That's unless people
toss in JS.
Comment 9 Gregory Maxwell 2007-05-01 02:56:13 UTC
an alternative operation would be something like, at parse time the img_class
column is built up additvely from multiple {{MEDIACLASS:}} statements. 

For example if an image page (and its templates) contained
{{MEDIACLASS:nonfree}}... {{MEDIACLASS:commonsdelete}}... {{MEDIACLASS:nudity}}
...  the resulting img_class column would be "img_nonfree_commonsdelete_nudity"
and this value would be set on the images for local/user css/js to act on as it
sees fit (it would have to iterate over all images checking their classes
against patterns).

This adds a little complexity to what was proposed above, and moves a little of
the policy (all begin with img_) into mediawiki, but I think it would work
better with the way that an image's description is build up additively from
Comment 10 Gregory Maxwell 2007-05-01 02:57:34 UTC
I don't know.. how much do we want to avoid JS for these applications? I think
that JS is fine (and my last comment would pretty much require JS to do anything
at all).
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-01 03:01:59 UTC
Yeah, maybe.  It doesn't seem to me that concatenation is the way to go,
incidentally.  Classes are space-separated, so best to use that: just have
class="nonfree commonsdelete nudity".  I'd let different wikis establish their
own conventions for the class names, too, not force any special prefix.  (In
particular, it seems likely that foreign-language wikis might want localized
prefixes.  Remember that any Unicode character except some reserved ASCII marks
and maybe a few insane ones can appear in class names.)
Comment 12 Sager 2007-05-12 02:30:28 UTC
I for one love the idea of a watermark the site could customize.
I cater to the satellite industry, and have already been told by other site
admin they want to steal my pictures.
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-13 01:01:41 UTC
Watermarks as discussed here would not affect the image source.  The relevant 
images could still be downloaded easily, probably just by right-clicking and 
selecting "Save".  The idea is certainly not to encourage possessiveness of 
images used on the wiki; for that you'll want to come up with an extension 
Comment 14 Judson (enwiki:cohesion) 2007-08-02 21:56:48 UTC
Space separated class names sent from perhaps multiple instances of the magic word {{MEDIACLASS:foo}} on the image page (both directly and via transcluded templates) seems ideal. This way you may have multiple templates on the image page, with each individual template having the least required number of {{MEDIACLASS:}} mentions for its use, but from the article page you would get the informative benefit of all of them. This system would be exceptionally useful by the way.
Comment 15 Guillaume Paumier 2009-12-30 21:51:57 UTC
Does this try to address the same issue as bug 8298 ?
Comment 16 Judson (enwiki:cohesion) 2009-12-30 22:34:34 UTC
I believe so, yes.
Comment 17 Guillaume Paumier 2009-12-30 23:44:41 UTC

*** This bug has been marked as a duplicate of bug 8298 ***

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