On 6/18/06, Brion Vibber brion@pobox.com wrote:
When the primary file storage is migrated to the hash-based filestore, that will decouple physical filenames from logical filenames and make that feasible.
I do want to make sure it's done before the end of the year, but it's not a top priority (and we want to be damn sure migration will work correctly when it happens; we'll have near half a terabyte of data to migrate when the time comes!) so it won't be tomorrow.
Brion,
When you work on the hash store for primary storage you'll have to address thumbnails. When you do this, please keep in mind the ability to create thumbs with multiple parameters beyond size, I'm not suggesting that such extensions need be implemented today, I just want us to avoid a redesign should we decide to implement them in the future.
Here are three examples where additional parameters would be very useful: 1) Cropping. Right now there are cases where people will upload multiple cropped versions of an image to place parts at reasonable sizes throughout the article. This complicates tagging and copyright matters, is generally wasteful, and can not be fluidly edited. A syntax such as [[Image:foo.jpg|crop:100x100+20+80|50px]] would solve this. Cropping should be possible without loading the entire image in memory, but imagemagick doesn't currently do this as far as I can tell. 2) Sharpening. Many images lose too much [[accutance]] when downsampled with quality filtering, and appear blurry as a result. This has caused some cases of people uploading thumbed and sharpened images rather than using mediawiki syntax. Syntax would be something like [[Image:foo.jpg|thumb|sharpen_high]]. Sharpening should be possible without completely loading the image in memory, but imagemagick doesn't do this as far as I can tell. 3) SVG parameters. For translations and other applications it would be useful to do basic variable replacement in SVGs, for example [[Image:heart.svg|250px|options=title:The human heart,la:Left auricular,rv:Right ventricle]]. Perhaps positioning issues will make that non-useful without a full XSLT engine (which can be done in bound memory and cpu...) but that would be a much larger issue.
I hope you can see from these examples that it is possible that someday we will decide that having more options offsets the additional storage and missrate of having more thumbnail flavors.
It's also possible that some would like to provide a jpeg quality switch, because our current setting create visible artifacts on some images... but I think this would be better solved by increasing our jpeg quality setting globally.
On 6/19/06, Gregory Maxwell gmaxwell@gmail.com wrote:
When you work on the hash store for primary storage you'll have to address thumbnails. When you do this, please keep in mind the ability to create thumbs with multiple parameters beyond size, I'm not suggesting that such extensions need be implemented today, I just want us to avoid a redesign should we decide to implement them in the future.
These first two suggestions would be good, as a good thumbnail is rarely the same thing as "reduce X and Y dimensions by 80%" for instance. It would probably be even more helpful to be able to store thumbnail metadata on the image itself, so that any time it was used as a thumbnail, the right portion of the image was automatically used.
A sharper thumbnail would, in general, be useful - not sure whether a parameter is specifically required.
Steve
On 6/19/06, Steve Bennett stevage@gmail.com wrote: [snip]
A sharper thumbnail would, in general, be useful - not sure whether a parameter is specifically required.
Unfortunately the appreciate amount of sharpening is highly content dependant (and to some extent a matter of taste). I have absolutely zero hope of a single always on sharping setting giving better results overall than none at all... I do hope that a small number of user specified settings (none,low,high) would suffice. If someone is aware of any papers on automagically selecting appropriate sharpening, I'd love to hear about it. ... but this is just getting off topic.
I'm glad to hear that other people think such features would be useful.
On Mon, Jun 19, 2006 at 02:08:57PM -0400, Gregory Maxwell wrote:
I'm glad to hear that other people think such features would be useful.
I hadn't gotten to chime in, but yes, by all means, I think that user-specifiable crop and zoom parameters would be a useful addition to MediaWiki.
Cheers, -- jra
Jay R. Ashworth wrote:
On Mon, Jun 19, 2006 at 02:08:57PM -0400, Gregory Maxwell wrote:
I'm glad to hear that other people think such features would be useful.
I hadn't gotten to chime in, but yes, by all means, I think that user-specifiable crop and zoom parameters would be a useful addition to MediaWiki.
Apropos of the thumbnailing issue, it might actually be a huge advantage to be able to crop and zoom.
Consider the case where we have a historical photograph showing several notable people. We have the option of simply showing the same image against each of those people, or uploading multiple cropped fragments showing each person in turn.
Imagine the possibilities of uploading a single image showing all those people and then being able to show just the appropriate face in the article, linking through to the main image for context.
HTH HAND
On 6/20/06, Phil Boswell phil.boswell@gmail.com wrote:
Consider the case where we have a historical photograph showing several notable people. We have the option of simply showing the same image against each of those people, or uploading multiple cropped fragments showing each person in turn.
Imagine the possibilities of uploading a single image showing all those people and then being able to show just the appropriate face in the article, linking through to the main image for context.
Yep. Look, while we're at it, some more requests: In-place modifications of the following types: - increase/decrease contrast - increase/decrease brightness - rotate arbitrary angle
I very frequently come across images which are less than perfect in very easily fixable ways. A small number of these make it to WP:FPC where they tend to get fixed. The rest don't, because it's too much work to download the image, modify it, save it, and re-upload. If I had to do nothing more than add {{IMAGE-STRAIGHTEN:-4.5}} to an image description page, I would do it much more frequently.
Totally in accordance with the wiki principle too: one person takes a happysnap and uploads it - the smallest effort possible. Someone else discovers its imperfections, adds a straighten. Someone else increases the contrast. Someone else defines a good thumbnail. Each person contributes a small, atomic action, with the lowest cost of effort possible.
Steve
On 6/20/06, Steve Bennett stevage@gmail.com wrote:
Yep. Look, while we're at it, some more requests: In-place modifications of the following types:
- increase/decrease contrast
- increase/decrease brightness
That thought of this makes me uncomfortable. Many people have uncalibrated monitors and weird tastes in brightness and contrast, it's hard to be objective about such changes.. please see the miniessay on the last bullet of my commons userpage (http://commons.wikimedia.org/wiki/User:Gmaxwell). Such knobs would also encourage shed painting and create an unneccessary proliferation of additional versions.
- rotate arbitrary angle
I don't think this can be done without loading the entire uncompressed image into memory which pretty much makes it a non-starter.
[snip]
Totally in accordance with the wiki principle too: one person takes a happysnap and uploads it - the smallest effort possible. Someone else discovers its imperfections, adds a straighten. Someone else increases the contrast. Someone else defines a good thumbnail. Each person contributes a small, atomic action, with the lowest cost of effort possible.
It doesn't always play out so rosey... Sometimes someone spends hours getting a photograph just right (because unlike wikitext, even in the best case 98% of the work must be done by a single photographer) and they are proud of their work. Then along comes a self appointed wiki-photo expert... who goofs up the image to fit his tastes on his uncalibrated display and insists that it's better. Perhaps the new version is more contrasty, with over pumped saturation and sharpness.... At first glance it's more eye catching, so other passers by support the changed version, but it's lost it's depth, lost detail in the shadow, or just lost it's ability to captivate for more than a moment. Perhaps it's cropped to place the subject dead center, destroying the careful balence achieved in the photo which guides the eye...
We've had photographers leave in digust over this.
Wikinews permits unfree images (CC-BY-ND) as a result of this.
So I'm a bit hesitant to suggest we provided technical tools which may encourage bad aspects of our behavior. But this has gone wayyyy off-topic now. :) Once someone impliments some of this stuff we can debate the merits of turning it on.
On 6/20/06, Gregory Maxwell gmaxwell@gmail.com wrote:
On 6/20/06, Steve Bennett stevage@gmail.com wrote:
Yep. Look, while we're at it, some more requests: In-place modifications of the following types:
- increase/decrease contrast
- increase/decrease brightness
That thought of this makes me uncomfortable. Many people have uncalibrated monitors and weird tastes in brightness and contrast, it's hard to be objective about such changes.. please see the
Sure, but give people *some* credit. Also, all these things are available now, they just take a while to carry out. We don't want to prevent the 90% of times when this would be useful just to stop the 10% when it would be a pain?
miniessay on the last bullet of my commons userpage (http://commons.wikimedia.org/wiki/User:Gmaxwell). Such knobs would also encourage shed painting and create an unneccessary proliferation of additional versions.
What is "shed painting", and why would there be "additional versions" exactly? I'm proposing either: - parameters in [[Image: .... which would only be taken into account when it's shown (do you mean the extra versions which would have to be stored internally - is there a disk space problem?) - parameters on the image page, which would be taken into account everywhere it's used - only one version.
The current situation is the one that risks proliferating extra versions, as you have to upload new files each time...
- rotate arbitrary angle
I don't think this can be done without loading the entire uncompressed image into memory which pretty much makes it a non-starter.
Is this not the case for any of the other edits? I was kind of presuming this would be the sort of thing where the first time the tag was encountered, the image would be rotated then cached. But I don't know much about how it works behind the scenes.
It doesn't always play out so rosey... Sometimes someone spends hours getting a photograph just right (because unlike wikitext, even in the best case 98% of the work must be done by a single photographer) and they are proud of their work. Then along comes a self appointed
We have a name for those: Featured Pictures. The vast majority of user-created photos are happy snaps taken fairly quickly to illustrate the topic. If someone chooses to post-process my photos, so much the better!
wiki-photo expert... who goofs up the image to fit his tastes on his uncalibrated display and insists that it's better. Perhaps the new version is more contrasty, with over pumped saturation and sharpness.... At first glance it's more eye catching, so other passers
Ok, again, I think your scenario where suddenly Wikipedia is overrun with well-meaning, but tasteless editors destroying beautiful artwork is demeaning, unkind, and just not accurate.
by support the changed version, but it's lost it's depth, lost detail in the shadow, or just lost it's ability to captivate for more than a moment. Perhaps it's cropped to place the subject dead center,
Are we trying to captivate for much more than a moment? Sharp, bright, high contrast images suit our encyclopaedic mission better.
destroying the careful balence achieved in the photo which guides the eye...
Yep, I would probably crop photos to leave the subject dead centre, maximising the encyclopaedic value of the photo for a given number of pixels. Totally against the rule of two-thirds, but we're an encyclopaedia, not an art school.
Don't forget, the original creator can always come back and undo the changes, perhaps leaving a note to "please" not crop his image.
We've had photographers leave in digust over this.
That sounds like a totally separate problem. It's already possble to over-write each others' images, sounds like social solutions are needed to that particular social problem.
So I'm a bit hesitant to suggest we provided technical tools which may encourage bad aspects of our behavior. But this has gone wayyyy off-topic now. :) Once someone impliments some of this stuff we can debate the merits of turning it on.
IMHO, debating the merits of a proposed feature is perfectly on-topic. I think some of your objections are a bit spurious, but that doesn't make them off-topic...:)
Steve
On 6/20/06, Steve Bennett stevage@gmail.com wrote:
That thought of this makes me uncomfortable. Many people have uncalibrated monitors and weird tastes in brightness and contrast, it's hard to be objective about such changes.. please see the
Sure, but give people *some* credit. Also, all these things are available now, they just take a while to carry out. We don't want to prevent the 90% of times when this would be useful just to stop the 10% when it would be a pain?
The work curve today discourages casual modification.. it's both good and bad. If I spend four hours preparing an image, I'd feel better if the next person in line spend more than four seconds considering his changes. :)
miniessay on the last bullet of my commons userpage (http://commons.wikimedia.org/wiki/User:Gmaxwell). Such knobs would also encourage shed painting and create an unneccessary proliferation of additional versions.
What is "shed painting", and why would there be "additional versions" exactly? I'm proposing either:
It's hyperlinked! Follow the link.
- parameters in [[Image: .... which would only be taken into account
when it's shown (do you mean the extra versions which would have to be stored internally - is there a disk space problem?)
- parameters on the image page, which would be taken into account
everywhere it's used - only one version.
Extra parameters in [[Image:]] create scaling problems. If we have a million images, then we'll have at a minimum of around a million thumbs. If people tend to use two sizes, two million thumbs. If they tend ti have two different rotations four million thumbs. It's not so much a disk space issue as it is an ability for the operating system and other software to scale to handling tens of millions of small files.
It can be permitted, of course, if the feature is important enough... the whole reason I started this thread was to remind the folks working on the next gen system (Brion :) ) that there is a justified need for some additional parameters beyond image width. What features those are, I'm not sure.. I made a few examples that I would support.
Settings one per image avoid the issue...
The current situation is the one that risks proliferating extra versions, as you have to upload new files each time...
Would you actually have multiple rotations though? If not, and you were indeed making a correction you overwrite the original.
- rotate arbitrary angle
I don't think this can be done without loading the entire uncompressed image into memory which pretty much makes it a non-starter.
Is this not the case for any of the other edits? I was kind of presuming this would be the sort of thing where the first time the tag was encountered, the image would be rotated then cached. But I don't know much about how it works behind the scenes.
All the other changes could pretty simply be done without decompressing the entire image. (We don't fully decompress jpegs for resizing today, but we do PNGs.. which is why PNGs have tighter size constraints.. people were running the servers out of ram with huge PNG maps)... Rotation OTOH would be much harder to accomplish incrementally.
It doesn't always play out so rosey... Sometimes someone spends hours getting a photograph just right (because unlike wikitext, even in the best case 98% of the work must be done by a single photographer) and they are proud of their work. Then along comes a self appointed
We have a name for those: Featured Pictures. The vast majority of user-created photos are happy snaps taken fairly quickly to illustrate the topic. If someone chooses to post-process my photos, so much the better!
Fair enough... although the shed painting is sometimes the worst on Featured Pictures... Most people don't care to correct your happy snapshots.
wiki-photo expert... who goofs up the image to fit his tastes on his uncalibrated display and insists that it's better. Perhaps the new version is more contrasty, with over pumped saturation and sharpness.... At first glance it's more eye catching, so other passers
Ok, again, I think your scenario where suddenly Wikipedia is overrun with well-meaning, but tasteless editors destroying beautiful artwork is demeaning, unkind, and just not accurate.
It's cost us good photographers. Wikipedia isn't overrun by goons, but we're desperately short of real photographers.
by support the changed version, but it's lost it's depth, lost detail in the shadow, or just lost it's ability to captivate for more than a moment. Perhaps it's cropped to place the subject dead center,
Are we trying to captivate for much more than a moment? Sharp, bright, high contrast images suit our encyclopaedic mission better.
No, we're trying to be tasteful, professional, and most of all informative. If we were just trying to push people's attention buttons we could make all the images flash, and make the text red on yellow.
destroying the careful balence achieved in the photo which guides the eye...
Yep, I would probably crop photos to leave the subject dead centre, maximising the encyclopaedic value of the photo for a given number of pixels. Totally against the rule of two-thirds, but we're an encyclopaedia, not an art school.
How does placing the subject dead center maximizes the encyclopedic value of an image? Yes, perhaps you could see a few more hairs in someones eyebrow with a tighter composition, but if someone needs to see that they can click for the full screen version... Worse, by overcropping you distort perspective and create an unnatural balance which is potentially distracting.
If we wrote our text in some sort of compressed always machine parsable English we could probably express more ideas in a given number of words... but thats not what we do because the value to the reader is increased through brilliant prose.
Don't forget, the original creator can always come back and undo the changes, perhaps leaving a note to "please" not crop his image.
And they are reminded that it's a collaborative project not an exclusive photo publishing ground (unless we're talking about wikinews)... And, of course, thats quite right. A balance is required, and far too often people simple change without asking.
We've had photographers leave in digust over this.
That sounds like a totally separate problem. It's already possble to over-write each others' images, sounds like social solutions are needed to that particular social problem.
I'm a big advocate of socal soutions to social problems... but I'd prefer that the technoligy not make things worse while we're trying to figure things out. :) Perhaps that would happen, perhaps it wouldn't.. I'm not sure.
I don't know how to solve it... We have very few real photographers participating... a majority of our photo involved folks are primarly finding free images on the web, or just skimming their snapshot collections, so the culture of image alteration is very different from what it would be if more people were photographers.
On solution (as seen on Wikinews) was to compromise the Wikimedia foundation's goal of distributing free content... I'd hate to see that same compromise appear elsewhere.
So I'm a bit hesitant to suggest we provided technical tools which may encourage bad aspects of our behavior. But this has gone wayyyy off-topic now. :) Once someone impliments some of this stuff we can debate the merits of turning it on.
IMHO, debating the merits of a proposed feature is perfectly on-topic. I think some of your objections are a bit spurious, but that doesn't make them off-topic...:)
Well, it's off-topic until someone codes it... :) I think that everything you suggested would be desirable features in *MediaWiki* if not on the wikimedia wikis, someone should probably solve them for the zillions of small wikis out there that could use them, and then we can debate if the solutions are suitable (technically and socially) for use on the wikimedia wikis.
On 6/20/06, Gregory Maxwell gmaxwell@gmail.com wrote:
The work curve today discourages casual modification.. it's both good and bad. If I spend four hours preparing an image, I'd feel better if the next person in line spend more than four seconds considering his changes. :)
It's a social problem. We can come up with a "please don't edit this unless you're willing to face the consequences" template. Easily.
What is "shed painting", and why would there be "additional versions" exactly? I'm proposing either:
It's hyperlinked! Follow the link.
Oh that. Parkinson's law.
Extra parameters in [[Image:]] create scaling problems. If we have a million images, then we'll have at a minimum of around a million thumbs. If people tend to use two sizes, two million thumbs. If they tend ti have two different rotations four million thumbs. It's not so much a disk space issue as it is an ability for the operating system and other software to scale to handling tens of millions of small files.
Isn't this currently the case? Or are thumbnails currently dynamically generated?
The current situation is the one that risks proliferating extra versions, as you have to upload new files each time...
Would you actually have multiple rotations though? If not, and you were indeed making a correction you overwrite the original.
Uh, this is a wiki. Unless I'm mistaken, we currently store old revisions of images, and this is not a problem. I'm not sure why it should suddenly become a problem because we allow a new way of modifying (that is, creating new revisions of) images.
All the other changes could pretty simply be done without decompressing the entire image. (We don't fully decompress jpegs for resizing today, but we do PNGs.. which is why PNGs have tighter size constraints.. people were running the servers out of ram with huge PNG maps)... Rotation OTOH would be much harder to accomplish incrementally.
Incrementally? I'll leave that one to the image manipulation specialists.
Fair enough... although the shed painting is sometimes the worst on Featured Pictures... Most people don't care to correct your happy snapshots.
Precisely. It's too much hard work for too little benefit. If all they had to do was click the image, drag two scrollbars and click "save", then maybe they would. Well, I would.
It's cost us good photographers. Wikipedia isn't overrun by goons, but we're desperately short of real photographers.
Again, social problem. Hell, protect these wonderful photographers' precious artworks if it will help keep them in the project. This is a very minor portion of the total number of photos, and not worth stressing over.
Are we trying to captivate for much more than a moment? Sharp, bright, high contrast images suit our encyclopaedic mission better.
No, we're trying to be tasteful, professional, and most of all informative. If we were just trying to push people's attention buttons we could make all the images flash, and make the text red on yellow.
Ok, you're being silly.
How does placing the subject dead center maximizes the encyclopedic value of an image? Yes, perhaps you could see a few more hairs in
Depends what the subject is. But fairly evidently, the more stuff in the thumbnail (and we are talking about the thumbnail that appears in the article here - the full picture is still accessible) that is relevant to the article, the better. Our thumbnails are already small, like 200x150. If 100x150 of that is empty space caused by artistic positioning, then we've lost a lot of possible informational content. There are times and places for it - but small images that illustrate an article are not them.
someones eyebrow with a tighter composition, but if someone needs to see that they can click for the full screen version... Worse, by overcropping you distort perspective and create an unnatural balance which is potentially distracting.
So don't overcrop.
If we wrote our text in some sort of compressed always machine parsable English we could probably express more ideas in a given number of words... but thats not what we do because the value to the reader is increased through brilliant prose.
Your example is good - we *do* cut waffle, and we *do* cut all the background discussion that you need to understand the article, or we put it down the bottom of the article, out of the way. Our lead paragraphs are idea-rich, information-dense text exactly comparable to cropping and increasing contrast in our thumbnails. Your example of "compressed always machine parsable English" might be comparable with "overcropping" - taking the idea too far and losing context.
And they are reminded that it's a collaborative project not an exclusive photo publishing ground (unless we're talking about wikinews)... And, of course, thats quite right. A balance is required, and far too often people simple change without asking.
Far too often people modify each others' images?? Thoroughly disagree - far too often, people are not bold, hence why most of our images look as though they came straight out of the digital camera, without passing the photoshop square, and without collecting $200.
I'm a big advocate of socal soutions to social problems... but I'd prefer that the technoligy not make things worse while we're trying to figure things out. :) Perhaps that would happen, perhaps it wouldn't.. I'm not sure.
Just remember that Wikipedia couldn't possibly work.
I don't know how to solve it... We have very few real photographers participating... a majority of our photo involved folks are primarly finding free images on the web, or just skimming their snapshot collections, so the culture of image alteration is very different from what it would be if more people were photographers.
And better image manipulation tools would discourage real photographers?
Steve
On Tue, Jun 20, 2006 at 07:58:30PM +0200, Steve Bennett wrote:
All the other changes could pretty simply be done without decompressing the entire image. (We don't fully decompress jpegs for resizing today, but we do PNGs.. which is why PNGs have tighter size constraints.. people were running the servers out of ram with huge PNG maps)... Rotation OTOH would be much harder to accomplish incrementally.
Incrementally? I'll leave that one to the image manipulation specialists.
He's correct; if you want multiple rotations of an image, do them all from the original.
How does placing the subject dead center maximizes the encyclopedic value of an image? Yes, perhaps you could see a few more hairs in
Depends what the subject is. But fairly evidently, the more stuff in the thumbnail (and we are talking about the thumbnail that appears in the article here - the full picture is still accessible) that is relevant to the article, the better. Our thumbnails are already small, like 200x150. If 100x150 of that is empty space caused by artistic positioning, then we've lost a lot of possible informational content. There are times and places for it - but small images that illustrate an article are not them.
Correct. Pictures (can be for) art. Thumbnails are for *information*. I, personally, am always quite favorably impressed when I click through someone's thumbnail of a closeup of a person, and discover that it's a full-sized picture, in which that face merely happens to appear. Good choice in cropping the thumbnail appeals to my sense of aesthetics.
If we wrote our text in some sort of compressed always machine parsable English we could probably express more ideas in a given number of words... but thats not what we do because the value to the reader is increased through brilliant prose.
Your example is good - we *do* cut waffle, and we *do* cut all the background discussion that you need to understand the article, or we put it down the bottom of the article, out of the way. Our lead paragraphs are idea-rich, information-dense text exactly comparable to cropping and increasing contrast in our thumbnails. Your example of "compressed always machine parsable English" might be comparable with "overcropping" - taking the idea too far and losing context.
Very nice metaphor, yes.
I'm a big advocate of socal soutions to social problems... but I'd prefer that the technoligy not make things worse while we're trying to figure things out. :) Perhaps that would happen, perhaps it wouldn't.. I'm not sure.
Just remember that Wikipedia couldn't possibly work.
Hee.
I don't know how to solve it... We have very few real photographers participating... a majority of our photo involved folks are primarly finding free images on the web, or just skimming their snapshot collections, so the culture of image alteration is very different from what it would be if more people were photographers.
And better image manipulation tools would discourage real photographers?
And, remember, folks, since I think we've taken our eyes off the prize; the original discussion here, AIUI, was "knobs that can be applied to a thumbnail".
Cheers, -- jra
Gregory Maxwell wrote:
Extra parameters in [[Image:]] create scaling problems. If we have a million images, then we'll have at a minimum of around a million thumbs. If people tend to use two sizes, two million thumbs. If they tend ti have two different rotations four million thumbs. It's not so much a disk space issue as it is an ability for the operating system and other software to scale to handling tens of millions of small files.
I don't think this would make things any worse than they are now. In my experience, whenever an image is used on more than one page (counting use in a template as one use), more often than not each page already has it in a different size.
It doesn't always play out so rosey... Sometimes someone spends hours getting a photograph just right (because unlike wikitext, even in the best case 98% of the work must be done by a single photographer) and they are proud of their work. Then along comes a self appointed wiki-photo expert... who goofs up the image to fit his tastes on his uncalibrated display and insists that it's better. Perhaps the new version is more contrasty, with over pumped saturation and sharpness.... At first glance it's more eye catching, so other passers by support the changed version, but it's lost it's depth, lost detail in the shadow, or just lost it's ability to captivate for more than a moment. Perhaps it's cropped to place the subject dead center, destroying the careful balence achieved in the photo which guides the eye...
We've had photographers leave in digust over this.
Wikinews permits unfree images (CC-BY-ND) as a result of this.
wha....?!?!?!! I can't believe it! How disappointing. According to http://en.wikinews.org/wiki/Wikinews:Image_use_policy they also allow NC images! Is that not the very definition of nonfreeness for Wikimedia... is it really that they allow these because of photography quality concerns, or something else?
FWIW I agree on the point of image-editing. I think the best approach is, when the original uploader is offended at "improvements" to an image, revert to their version and upload the edited version as a separate file. Then the community can argue about which they prefer and the original uploader doesn't feel their work is being "mauled" (even if everyone else has incredible bad taste).
Brianna
On 6/20/06, Brianna Laugher brianna.laugher@gmail.com wrote:
Wikinews permits unfree images (CC-BY-ND) as a result of this.
wha....?!?!?!! I can't believe it! How disappointing. According to http://en.wikinews.org/wiki/Wikinews:Image_use_policy they also allow NC images! Is that not the very definition of nonfreeness for Wikimedia... is it really that they allow these because of photography quality concerns, or something else?
I was shocked too. I think it's a mix of factors.
The real photographers have significant and largely reality-based concerns about modification and unfair commercial exploitation. This has provided folks who wish to see Wikimedia distributing pseudo-free content a chance to claim pragmatism as an excuse...
I don't see fairuse images on as the same as NC/ND, because fair use images don't pretend to be free, they are annoying enough that they will and are replaced, and at least when they are used correctly they are used where there is no alternative possible. The argument made, I believe, is that the images aren't really part of the content and thus don't have to be free content if it helps us make better news. I think this is ridiculous because if the images weren't part of the content, then why do we bother having them at all... But not everyone agrees...
Of course, the concerns of photographers could be addressed in other ways...
Concerns over modification could be largely ameliorated through a combination of healthy social norms (don't shed paint) and photographer education (if someone mucks up your image than distributes it in a way which implies that it's your doing we call that fraud, you don't need annoying copyright terms to protect you from fraud)... and perhaps somewhat through copyleft licenses which require history preservation.
Concerns over unfair commercial exploitation could be significantly reduced through education and the support of aggressive copyleft licenses like the GFDL which require a copy of the license terms to be included, thus making sure the recipient knows exactly what he's getting and creating an incentive for commercial users to separately negotiate more favorable and traditional terms with the photographers. Unfortunately some self-professed visionaries involved with some of our projects have come out strongly in opposition to the GFDL, making decidedly non-reality-based claims about it (like the preposterous claim that it's a violation to transmit GFDL content over an SSL connection, or store your own copy on an encrypted disk).
FWIW I agree on the point of image-editing. I think the best approach is, when the original uploader is offended at "improvements" to an image, revert to their version and upload the edited version as a separate file. Then the community can argue about which they prefer and the original uploader doesn't feel their work is being "mauled" (even if everyone else has incredible bad taste).
The challenge is that if their version sits orphaned it might as well not exist. I don't believe that we should let prima donnas prevent us from having high quality content... But when someone did a awesome job with 98% of a picture (subject, composition, lighting, image quality, etc) and there is 2% which is highly subjective/viewer dependant which remains debatable (altered saturation, contrast, sharpening)... we should probably trust the person who got the 98% right to make the call on the rest, given our input. That it also keeps the photographer happy contributing is a secondary, but critical, effect.
I'm now managing to turn this thread into my own personal soap box... It really has gone OT. please forgive me, .. it's so hard not to reply on all this stuff that I care about. :)
On 6/20/06, Gregory Maxwell gmaxwell@gmail.com wrote:
The challenge is that if their version sits orphaned it might as well not exist. I don't believe that we should let prima donnas prevent us from having high quality content... But when someone did a awesome job with 98% of a picture (subject, composition, lighting, image quality, etc) and there is 2% which is highly subjective/viewer dependant which remains debatable (altered saturation, contrast, sharpening)... we should probably trust the person who got the 98% right to make the call on the rest, given our input. That it also keeps the photographer happy contributing is a secondary, but critical, effect.
Where is all this coming from? Wikipedia is a collaborative project. Take a look at WP:FPC on en, and you will see that almost every user-submitted image gets one or more edits applied to it to boost its quality, then we vote on our favourite. Generally, this collaborative image-manipulation process works quite well. If there are some photographers who prefer not to take part in that, that's fine, and I'm sure people would respect their requests if they were made clearly on their image pages.
This really is an abnormal scenario though.
Steve
Wikinews has never really allowed NC images. That policy disagrees with our practice. NC only images are frequently deleted, as they should be. I have removed the non-commercial images portion from Wikinews:Image use policy and nominated the NC image tag for deletion. There were only two images in the NC category, both qualified as very clear examples of fair use, and were recategorized. Craig
Brianna Laugher wrote:
It doesn't always play out so rosey... Sometimes someone spends hours getting a photograph just right (because unlike wikitext, even in the best case 98% of the work must be done by a single photographer) and they are proud of their work. Then along comes a self appointed wiki-photo expert... who goofs up the image to fit his tastes on his uncalibrated display and insists that it's better. Perhaps the new version is more contrasty, with over pumped saturation and sharpness.... At first glance it's more eye catching, so other passers by support the changed version, but it's lost it's depth, lost detail in the shadow, or just lost it's ability to captivate for more than a moment. Perhaps it's cropped to place the subject dead center, destroying the careful balence achieved in the photo which guides the eye...
We've had photographers leave in digust over this.
Wikinews permits unfree images (CC-BY-ND) as a result of this.
wha....?!?!?!! I can't believe it! How disappointing. According to http://en.wikinews.org/wiki/Wikinews:Image_use_policy they also allow NC images! Is that not the very definition of nonfreeness for Wikimedia... is it really that they allow these because of photography quality concerns, or something else?
FWIW I agree on the point of image-editing. I think the best approach is, when the original uploader is offended at "improvements" to an image, revert to their version and upload the edited version as a separate file. Then the community can argue about which they prefer and the original uploader doesn't feel their work is being "mauled" (even if everyone else has incredible bad taste).
Brianna _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 6/20/06, Craig Spurrier craig@craigweb.net wrote:
Wikinews has never really allowed NC images. That policy disagrees with our practice. NC only images are frequently deleted, as they should be. I have removed the non-commercial images portion from Wikinews:Image use policy and nominated the NC image tag for deletion. There were only two images in the NC category, both qualified as very clear examples of fair use, and were recategorized. Craig
The same is not true for ND images.
Re: "crop" and "zoom" - seems like it would have very undesirable "suprise" consequences if the original file was replaced (and changed dimensions - for example if it itself was cropped).
Sharpness could be good though. See http://commons.wikimedia.org/wiki/Commons:Village_pump#Low_sharpness for a striking example.
cheers, Brianna
On 6/20/06, Brianna Laugher brianna.laugher@gmail.com wrote:
Re: "crop" and "zoom" - seems like it would have very undesirable "suprise" consequences if the original file was replaced (and changed dimensions - for example if it itself was cropped).
Sharpness could be good though. See http://commons.wikimedia.org/wiki/Commons:Village_pump#Low_sharpness for a striking example.
From that discussion, the issue seems to be the file size of the
generated thumbnail: smaller file size (lower quality JPEG compression) produces fuzzier images.
This is closely related to the basic divide that exists: Camp A: Thumbnails exist only to be clicked on, to show the real image related to the page Camp B: Thumbnails are a fundamental part of the layout of the page, and should be made as big and pretty as necessary to achieve a pleasing and effective page design.
Those in camp A tend to believe that thumbnails should have a small file size (15kb maximum), should not have a size imposed on them (respect users' preferences), and should probably be all laid out in a vertical column. Those in camp B tend to believe that thumbnails should have larger file sizes (30-50kb), should be resized as necessary, and should definitely not be laid in a vertical column.
Camp B here.
Steve
On 6/20/06, Brianna Laugher brianna.laugher@gmail.com wrote:
Re: "crop" and "zoom" - seems like it would have very undesirable "suprise" consequences if the original file was replaced (and changed dimensions - for example if it itself was cropped).
Post upload cropping would become a discouraged behavior if such a feature were implemented. But I do see your point, ultimately it's the uploaders responsibility to check where a file is used. One time I had a picture of a firing xenon strob replaced with a video game character.... (flash.gif DOH) :)
Sharpness could be good though. See http://commons.wikimedia.org/wiki/Commons:Village_pump#Low_sharpness for a striking example.
Ha. I hadn't seen that one. I think the photoimpact version is too sharp, and I'd prefer something a little more in between. The folks in the thread are off in space however... This problem has nothing to do with our JPEG size (although I strongly believe that our jpeg quality setting should be increased somewhat as well).
I've added another example, which is prepared with imagemagick (same software as Mediawiki). It's the same file size as the Mediawiki jpeg thumb, but it looks pretty much just like the png.
On 6/19/06, Gregory Maxwell gmaxwell@gmail.com wrote:
Unfortunately the appreciate amount of sharpening is highly content dependant (and to some extent a matter of taste). I have absolutely zero hope of a single always on sharping setting giving better results overall than none at all... I do hope that a small number of user specified settings (none,low,high) would suffice. If someone is aware of any papers on automagically selecting appropriate sharpening, I'd love to hear about it. ... but this is just getting off topic.
In that case, it sounds like the relevant parameter should also be stored on the image, rather than on the call to the image. It seems unlikely to me that one would want to downscale using one method on one page, and using a different method on another page. In extreme cases (like, wanting to demonstrate pixelation), people can use the current fallback method.
Steve
On 6/19/06, Steve Bennett stevage@gmail.com wrote:
In that case, it sounds like the relevant parameter should also be stored on the image, rather than on the call to the image. It seems unlikely to me that one would want to downscale using one method on one page, and using a different method on another page. In extreme cases (like, wanting to demonstrate pixelation), people can use the current fallback method.
The amount of sharpening is size dependant.. I suppose you could attach a sharpening list to the image, which provides a list of thumb reduction ratios (rather than thumb sizes, so that it does the same WRT cropping) well with and the correct sharpening for each. This is a good idea because it would prevent the bloat of maintaining multiple versions. I like this... okay, so my point 2 is dead. Thanks for pointing this out. :) This also would allow the users to fully specify the sharpening parameters, which would be much better than the few fixed settings I'd envisioned.
Cropping still applies, however.
On 6/19/06, Gregory Maxwell gmaxwell@gmail.com wrote:
Cropping still applies, however.
Yes, but with caution - one of the main uses of cropping would probably be cutting faces out of CD covers and stuff, in violation of fair use.
What might be nice: defining a default "thumbnail" for an image, with cropping and sharpening parameters, say. Then, if a user specifies just [[image:image|thumb]], that's what gets used. Taking it further, if a user specifies [[image:image|thumb:200px]] and there exists a thumbnail profile for 200px, *those* parameters could be used.
Dunno how much it would all be used, of course.
Steve
On Mon, Jun 19, 2006 at 08:52:10PM +0200, Steve Bennett wrote:
What might be nice: defining a default "thumbnail" for an image, with cropping and sharpening parameters, say. Then, if a user specifies just [[image:image|thumb]], that's what gets used. Taking it further, if a user specifies [[image:image|thumb:200px]] and there exists a thumbnail profile for 200px, *those* parameters could be used.
Indeed; if one's going to enable cropping, it would be real handy to be able to specify a default per-image crop set.
Cheers, -- jra
On Mon, Jun 19, 2006 at 02:37:02PM -0400, Gregory Maxwell wrote:
On 6/19/06, Steve Bennett stevage@gmail.com wrote:
In that case, it sounds like the relevant parameter should also be stored on the image, rather than on the call to the image. It seems unlikely to me that one would want to downscale using one method on one page, and using a different method on another page. In extreme cases (like, wanting to demonstrate pixelation), people can use the current fallback method.
The amount of sharpening is size dependant..
Specifically, the amount of sharpening one might want is proportional to both the original *and* the cropped size of the image.
Cheers, -- jra
Can i remember http://bugzilla.wikimedia.org/show_bug.cgi?id=5763 ? It seems to be the time of file-hashing added to the FileStore (in fact, there's a hashing performed) and preparing it to general files.
"Gregory Maxwell" wrote:
On 6/18/06, Brion Vibber wrote:
When the primary file storage is migrated to the hash-based filestore, that will decouple physical filenames from logical filenames and make that feasible.
I do want to make sure it's done before the end of the year, but it's not a top priority (and we want to be damn sure migration will work correctly when it happens; we'll have near half a terabyte of data to migrate when the time comes!) so it won't be tomorrow.
Brion,
When you work on the hash store for primary storage you'll have to address thumbnails. When you do this, please keep in mind the ability to create thumbs with multiple parameters beyond size, I'm not suggesting that such extensions need be implemented today, I just want us to avoid a redesign should we decide to implement them in the future.
.......
- SVG parameters. For translations and other applications it would be
useful to do basic variable replacement in SVGs, for example [[Image:heart.svg|250px|options=title:The human heart,la:Left auricular,rv:Right ventricle]]. Perhaps positioning issues will make that non-useful without a full XSLT engine (which can be done in bound memory and cpu...) but that would be a much larger issue.
I'd add this with a ''changed'' output style, similar to our ?action=raw but with templates trancluded, Maybe action=substed ?
wikitech-l@lists.wikimedia.org