There is a new tool called PicNik that allows on-web touching up of photos: all basic tools like contrast, cropping, sharpness, conversion to greyscale etc. This is something that Wikipedia in particular has really been lacking: an easy way to improve the quality of a lot of the fairly tacky travel happy snaps that get uploaded. It's definitely not free software, but a lot of the uses of it are free. They don't host your images: you upload an image, work on it for a bit, then download it again. They have integration with facebook, flickr and a few other sites.
So I asked them about MediaWiki integration. There are apparently two ways we can achive this: either we extend MediaWiki to make use of their API, or we implement an API directly to allow them to retrieve an image (obviously pretty simple), then upload the updated version (credit and authentication issues). Could someone give me an idea of how much work would be involved? I might be interested in attempting some of the coding, especially if someone else is interested and can give me some guidance.
We have an API that any third-party site can use to pass a photo over
to Picnik for editing and when the user is done editing Picnik saves the result back to the site. It looks like MediaWiki has an extension mechanism, maybe that would be a good place to start.
How could we do this? Extend the image page to have a link to Picnik, then provide a mechanism whereby Picnik can call MediaWiki with a certain URL. Picnik seems pretty flexible on this point. The URL for info about the API is as follows: http://www.picnik.com/info/api
We can also add "integration bridges" to Picnik. Integration bridges
use a third-party API to access the photos on that site. The pages in Picnik that show thumbnails from Flickr and Picasa Web and can save to them are examples of integration bridges. Does MediaWiki have an API for accessing the photo content stored in a wiki, and updating it?
I don't know the answer to that question. Obviously it's easy to retrieve the content of one image, but allowing higher level (bulk) manipulation and organisation of images would be pretty cool if that was possible. Also, are there any other ways of getting an image back into MediaWiki besides special:upload ?
Any other comments about this idea are very welcome. Particularly if there are any objections to linking to such a site. I really think the potential benefits are very significant, so hopefully those objections can be overcome.
Steve
Seems doable. They can get the file from Special:Filepath/Imagename and tehn provide you a post data for Special:Upload (not really transparent as -for security- you must tell mediawiki you really want to uplaod it). Plus whatever the extension adds :)
On 8/13/07, Platonides Platonides@gmail.com wrote:
Seems doable. They can get the file from Special:Filepath/Imagename and tehn provide you a post data for Special:Upload (not really transparent as -for security- you must tell mediawiki you really want to uplaod it). Plus whatever the extension adds :)
Does MediaWiki support uploading from a URL? The Picnik API makes it easy to get the image source as a URL. If the image data itself has to be posted, that would be less good, particularly for people with slow uplinks.
Steve
On 8/12/07, Steve Bennett stevagewp@gmail.com wrote:
Does MediaWiki support uploading from a URL?
Yes. I believe it's restricted in some way by default, though, to discourage uploads from random websites.
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/12/07, Steve Bennett stevagewp@gmail.com wrote:
Does MediaWiki support uploading from a URL?
Yes. I believe it's restricted in some way by default, though, to discourage uploads from random websites.
Does that mean it's restricted on Wikipedia/Commons? Is there a whitelist?
Steve
On 8/12/07, Steve Bennett stevagewp@gmail.com wrote:
Does that mean it's restricted on Wikipedia/Commons? Is there a whitelist?
By default, the 'upload_by_url' permission is allowed to sysops only. As far as I know, the permission works exactly as you'd expect, but I'm not sure.
You also need to set this to true: http://www.mediawiki.org/wiki/Manual:%24wgAllowCopyUploads
On 13/08/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/12/07, Steve Bennett stevagewp@gmail.com wrote:
Does that mean it's restricted on Wikipedia/Commons? Is there a whitelist?
By default, the 'upload_by_url' permission is allowed to sysops only. As far as I know, the permission works exactly as you'd expect, but I'm not sure.
Whoa. this is news to me. :) so is it actually enabled or not?
cheers Brianna
On 8/12/07, Brianna Laugher brianna.laugher@gmail.com wrote:
You also need to set this to true: http://www.mediawiki.org/wiki/Manual:%24wgAllowCopyUploads
Ah, yes, so you do.
Whoa. this is news to me. :) so is it actually enabled or not?
Seemingly not, testing on mediawiki.org (where I'm a sysop). But it could be enabled.
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/12/07, Brianna Laugher brianna.laugher@gmail.com wrote:
You also need to set this to true: http://www.mediawiki.org/wiki/Manual:%24wgAllowCopyUploads
Ah, yes, so you do.
Whoa. this is news to me. :) so is it actually enabled or not?
Seemingly not, testing on mediawiki.org (where I'm a sysop). But it could be enabled.
How hard would it be to put a whitelist in place? That is, allowing anyone (logged in) to copy-upload files, as long as they came from a certain site. Allowing only admins to copy-upload doesn't really help with picnik integration.
Steve
Hoi, Improving of the 'quality' of pictures is not in and of itself something that is not without controversy. There have been fierce fights in the past over exactly this subject and there are a great many people that do not upload to Commons as a result.
The notion that there is software that allows you to improve pictures needs to be handled with caution. I have seen tragic attempts of improvement that were anything but. It is nice to have tools that allow you to work on pictures, it needs judgement to know when to do this. Giving the possibility to overwrite existing pictures to everyone is imho NOT a good idea.
Thanks, GerardM
On 8/13/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/12/07, Brianna Laugher brianna.laugher@gmail.com wrote:
You also need to set this to true: http://www.mediawiki.org/wiki/Manual:%24wgAllowCopyUploads
Ah, yes, so you do.
Whoa. this is news to me. :) so is it actually enabled or not?
Seemingly not, testing on mediawiki.org (where I'm a sysop). But it could be enabled.
How hard would it be to put a whitelist in place? That is, allowing anyone (logged in) to copy-upload files, as long as they came from a certain site. Allowing only admins to copy-upload doesn't really help with picnik integration.
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 13/08/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, Improving of the 'quality' of pictures is not in and of itself something that is not without controversy. There have been fierce fights in the past over exactly this subject and there are a great many people that do not upload to Commons as a result.
The notion that there is software that allows you to improve pictures needs to be handled with caution. I have seen tragic attempts of improvement that were anything but. It is nice to have tools that allow you to work on pictures, it needs judgement to know when to do this. Giving the possibility to overwrite existing pictures to everyone is imho NOT a good idea.
Everyone (account > 4 days) already has this possibility. It's just now they have to do it manually, by downloading the file, editing up, and uploading it again.
Brianna
Hoi, We were discussing making the uploading from Picnic and making it something that would be available to everyone. I am sure some bright light will create a bot to "improve" pictures with a bot.. by making the uploading from Picnic available to everyone, it will just happen and the results will not be good because of the escalation to the existing controversy that it will bring. Thanks, Gerard
On 8/13/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 13/08/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, Improving of the 'quality' of pictures is not in and of itself something that is not without controversy. There have been fierce fights in the
past
over exactly this subject and there are a great many people that do not upload to Commons as a result.
The notion that there is software that allows you to improve pictures
needs
to be handled with caution. I have seen tragic attempts of improvement
that
were anything but. It is nice to have tools that allow you to work on pictures, it needs judgement to know when to do this. Giving the
possibility
to overwrite existing pictures to everyone is imho NOT a good idea.
Everyone (account > 4 days) already has this possibility. It's just now they have to do it manually, by downloading the file, editing up, and uploading it again.
Brianna
-- They've just been waiting in a mountain for the right moment: http://modernthings.org/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/13/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, Improving of the 'quality' of pictures is not in and of itself something that is not without controversy. There have been fierce fights in the past over exactly this subject and there are a great many people that do not upload to Commons as a result.
Well at least the changes proposed aren't the sort which would enable some of the true horrors I've seen on commons.
For example, someone decided that a 3/4 view of a camera wasn't as good as a full front view. They twisted the image electronically to make it look kinda like a frontal view, but this left part of the camera body missing. So they painted it in. I'd take less issue with the fact that their paintjob looked poor were it not for the fact that they got the shape of the camera body quite wrong. :( So the EnWikipedia (at least) article had a inaccurate hack job of an image for a few weeks for that particular camera before I noticed it and reverted the image on commons. :(
Compared to that I'm not too worried about brightness/color/cropping.. etc.. but I think that using an external site for this is completely wrong. Dynamic crops should be a native feature of our repository, you should be able to upload a single image then define alternative views which are on the fly generated crops. Other really simple alterations (like most of the ones offered by that site) could be offered this way.
I played with the site (on a friends computer, it requires flash), the interface is snazzy no doubt, but all the manipulations it offers save red-eye are things that Imagemagic could provide... I could pretty easily setup a basic ajax interface that offered those filters and let you tweak their settings in real time.
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
For example, someone decided that a 3/4 view of a camera wasn't as good as a full front view. They twisted the image electronically to make it look kinda like a frontal view, but this left part of the camera body missing. So they painted it in. I'd take less issue with the fact that their paintjob looked poor were it not for the fact that they got the shape of the camera body quite wrong. :( So the EnWikipedia (at least) article had a inaccurate hack job of an image for a few weeks for that particular camera before I noticed it and reverted the image on commons. :(
Yeah. Sounds like a good-faith edit that went horribly wrong.
Compared to that I'm not too worried about brightness/color/cropping.. etc.. but I think that using an external site for this is completely wrong. Dynamic crops should be a native feature of our repository, you should be able to upload a single image then define alternative views which are on the fly generated crops. Other really simple alterations (like most of the ones offered by that site) could be offered this way.
We've discussed this in the past, but it's a fair bit of work, and nothing came of it. I'm not sure if a formal proposal was made anywhere, but there were discussions to allow attributes, like [[image:foo.jpg|cropx=15,150|brightness=+3]]. Obviously that would have readability problems.
It looks like you're suggesting having a dynamic view on another image, though, something like: [[Image:foo2.jpg]] which contains text like #IMAGEVIEW [[Image:foo.jpg]] with other tags indicating what kinds of tweaks to apply.
That could be good too. I don't think the two proposals are mutually exclusive. Could I also suggest making it easy to display a particular revision of an image. Then you would never be affected by someone else editing the image later on.
I played with the site (on a friends computer, it requires flash), the interface is snazzy no doubt, but all the manipulations it offers save red-eye are things that Imagemagic could provide... I could pretty easily setup a basic ajax interface that offered those filters and let you tweak their settings in real time.
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
Steve
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
I think his point was that it would prevent having to depend on a third-party. There's something to be said for keeping it all "in house"
-- Jim R. Wilson (jimbojw)
On 8/13/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
For example, someone decided that a 3/4 view of a camera wasn't as good as a full front view. They twisted the image electronically to make it look kinda like a frontal view, but this left part of the camera body missing. So they painted it in. I'd take less issue with the fact that their paintjob looked poor were it not for the fact that they got the shape of the camera body quite wrong. :( So the EnWikipedia (at least) article had a inaccurate hack job of an image for a few weeks for that particular camera before I noticed it and reverted the image on commons. :(
Yeah. Sounds like a good-faith edit that went horribly wrong.
Compared to that I'm not too worried about brightness/color/cropping.. etc.. but I think that using an external site for this is completely wrong. Dynamic crops should be a native feature of our repository, you should be able to upload a single image then define alternative views which are on the fly generated crops. Other really simple alterations (like most of the ones offered by that site) could be offered this way.
We've discussed this in the past, but it's a fair bit of work, and nothing came of it. I'm not sure if a formal proposal was made anywhere, but there were discussions to allow attributes, like [[image:foo.jpg|cropx=15,150|brightness=+3]]. Obviously that would have readability problems.
It looks like you're suggesting having a dynamic view on another image, though, something like: [[Image:foo2.jpg]] which contains text like #IMAGEVIEW [[Image:foo.jpg]] with other tags indicating what kinds of tweaks to apply.
That could be good too. I don't think the two proposals are mutually exclusive. Could I also suggest making it easy to display a particular revision of an image. Then you would never be affected by someone else editing the image later on.
I played with the site (on a friends computer, it requires flash), the interface is snazzy no doubt, but all the manipulations it offers save red-eye are things that Imagemagic could provide... I could pretty easily setup a basic ajax interface that offered those filters and let you tweak their settings in real time.
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/13/07, Jim Wilson wilson.jim.r@gmail.com wrote:
I think his point was that it would prevent having to depend on a third-party. There's something to be said for keeping it all "in house"
I agree, but what, exactly? And how much is that worth? Do we have a policy of preferring only integration with open-source tools? We have some loose integration with Google maps (and competitors), with libraries and online bookstores...what's the policy on this?
Steve
Hoi, This is what they call the "not invented here" syndrome... There are good reasons to make use of functionality that was developed elsewhere. For one, it works and it works now.
Given that we have a problem in getting functionality life, important functionality like Single User Logon, it is not smart to think that we can do it all, should do it all. We have proven conclusively that we cannot do it. Thanks, GerardM
On 8/13/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
I think his point was that it would prevent having to depend on a third-party. There's something to be said for keeping it all "in house"
-- Jim R. Wilson (jimbojw)
On 8/13/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
For example, someone decided that a 3/4 view of a camera wasn't as good as a full front view. They twisted the image electronically to make it look kinda like a frontal view, but this left part of the camera body missing. So they painted it in. I'd take less issue with the fact that their paintjob looked poor were it not for the fact that they got the shape of the camera body quite wrong. :( So the EnWikipedia (at least) article had a inaccurate hack job of an image for a few weeks for that particular camera before I noticed it and reverted the image on commons. :(
Yeah. Sounds like a good-faith edit that went horribly wrong.
Compared to that I'm not too worried about brightness/color/cropping.. etc.. but I think that using an external site for this is completely wrong. Dynamic crops should be a native feature of our repository, you should be able to upload a single image then define alternative views which are on the fly generated crops. Other really simple alterations (like most of the ones offered by that site) could be offered this way.
We've discussed this in the past, but it's a fair bit of work, and nothing came of it. I'm not sure if a formal proposal was made anywhere, but there were discussions to allow attributes, like [[image:foo.jpg|cropx=15,150|brightness=+3]]. Obviously that would have readability problems.
It looks like you're suggesting having a dynamic view on another image, though, something like: [[Image:foo2.jpg]] which contains text like #IMAGEVIEW [[Image:foo.jpg]] with other tags indicating what kinds of tweaks to apply.
That could be good too. I don't think the two proposals are mutually exclusive. Could I also suggest making it easy to display a particular revision of an image. Then you would never be affected by someone else editing the image later on.
I played with the site (on a friends computer, it requires flash), the interface is snazzy no doubt, but all the manipulations it offers save red-eye are things that Imagemagic could provide... I could pretty easily setup a basic ajax interface that offered those filters and let you tweak their settings in real time.
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Steve Bennett said:
We have some loose integration with Google maps (and competitors), with libraries and online bookstores
I'm not an expert on how Wikipedia is set up, however to my knowledge, these additions are not tied to the functionality of the site. That is, if one of those services went down, wikipedia would continue to operate as normal, just with some broken pages.
Tying actual modification functionality to a third party is a different matter (IMO). If that photo-edit site went down for a period, then that functionality would be unavailable for that duration (however long it may be). Whether this is acceptable is a question for people with policy setting power.
GerardM said:
This is what they call the "not invented here" syndrome
According to wikpdedia [1] (emphasis mine), "Not Invented Here (NIH) is a term used to describe a persistent sociological, corporate or institutional culture that avoids using already existing products, research or knowledge because of its different origins."
I don't feel that NIH applies to this case as there are actual technical and political considerations, not simply who happened to write the code.
[1] http://en.wikipedia.org/wiki/Not_invented_here
-- Jim
On 8/13/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, This is what they call the "not invented here" syndrome... There are good reasons to make use of functionality that was developed elsewhere. For one, it works and it works now.
Given that we have a problem in getting functionality life, important functionality like Single User Logon, it is not smart to think that we can do it all, should do it all. We have proven conclusively that we cannot do it. Thanks, GerardM
On 8/13/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
I think his point was that it would prevent having to depend on a third-party. There's something to be said for keeping it all "in house"
-- Jim R. Wilson (jimbojw)
On 8/13/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
For example, someone decided that a 3/4 view of a camera wasn't as good as a full front view. They twisted the image electronically to make it look kinda like a frontal view, but this left part of the camera body missing. So they painted it in. I'd take less issue with the fact that their paintjob looked poor were it not for the fact
that
they got the shape of the camera body quite wrong. :( So the EnWikipedia (at least) article had a inaccurate hack job of an image for a few weeks for that particular camera before I noticed it and reverted the image on commons. :(
Yeah. Sounds like a good-faith edit that went horribly wrong.
Compared to that I'm not too worried about
brightness/color/cropping..
etc.. but I think that using an external site for this is
completely
wrong. Dynamic crops should be a native feature of our repository, you should be able to upload a single image then define alternative views which are on the fly generated crops. Other really simple alterations (like most of the ones offered by that site) could be offered this way.
We've discussed this in the past, but it's a fair bit of work, and nothing came of it. I'm not sure if a formal proposal was made anywhere, but there were discussions to allow attributes, like [[image:foo.jpg|cropx=15,150|brightness=+3]]. Obviously that would have readability problems.
It looks like you're suggesting having a dynamic view on another image, though, something like: [[Image:foo2.jpg]] which contains text like #IMAGEVIEW [[Image:foo.jpg]] with other tags indicating what kinds of tweaks to apply.
That could be good too. I don't think the two proposals are mutually exclusive. Could I also suggest making it easy to display a particular revision of an image. Then you would never be affected by someone else editing the image later on.
I played with the site (on a friends computer, it requires flash),
the
interface is snazzy no doubt, but all the manipulations it offers
save
red-eye are things that Imagemagic could provide... I could pretty easily setup a basic ajax interface that offered those filters and
let
you tweak their settings in real time.
Mmmmm...but why? There's an awesome interface that would do everything we want. Why code from scratch a "basic...interface"?
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, Obviously .. then again you rationalise why it is not the NIH syndrome and you forget about the other arguments why it would be a good thing NOT to write the same functionality again. A good way of providing arguments why it is NIH after all. Thanks, GerardM
On 8/13/07, Jim Wilson wilson.jim.r@gmail.com wrote:
GerardM said:
This is what they call the "not invented here" syndrome
According to wikpdedia [1] (emphasis mine), "Not Invented Here (NIH) is a term used to describe a persistent sociological, corporate or institutional culture that avoids using already existing products, research or knowledge because of its different origins."
I don't feel that NIH applies to this case as there are actual technical and political considerations, not simply who happened to write the code.
On 8/13/07, Jim Wilson wilson.jim.r@gmail.com wrote:
I'm not an expert on how Wikipedia is set up, however to my knowledge, these additions are not tied to the functionality of the site. That is, if one of those services went down, wikipedia would continue to operate as normal, just with some broken pages.
Tying actual modification functionality to a third party is a different matter (IMO). If that photo-edit site went down for a period, then that functionality would be unavailable for that duration (however long it may be). Whether this is acceptable is a question for people with policy setting power.
The point you're making may be too subtle for me.
Before: a) Wikipedia had no way of displaying the locations of things on maps b) Wikipedia had no way of providing extended book information based on an ISBN c) Wikipedia had no way of editing photos on the site
But it had workarounds: a) You could manually go to some other site or an atlas and look up the GPS coordinates b) You could search google for that ISBN number c) You could download the image, edit it and upload it again
Then we integrated (or are considering integration) with some third party: a) You click a link and you see a map of the location b) You click a link and see extended book information c) You click a link and edit a photo before saving it back to Wikipedia
But if that third party site goes down: a) You go back to the workaround, or use one of the other mapping services b) You click a different link c) You go back to the workaround.
Pretty similar. The real difference is actually that the map and ISBN integration are tools for *readers*, whereas Picnik integration is a tool for *editors*. Not sure if that difference is significant though.
So the objection so far seems to boil down to: It would be even better if MediaWiki natively had this functionality. I agree. Is that a reason not to make use of a third party site in the meantime? Are there other objections?
Steve
GerardM said:
then again you rationalise why it is not the NIH syndrome and you forget about the other arguments why it would be a good thing NOT to write the same functionality again
Please understand, I have not forgotten about those arguments - I have no opinion on whether Wikipedia should implement integration with this service. I'm sorry if there was nay confusion, I am merely hoping to help enumerate the pros and cons - the pros having already been covered quite well by others :)
Steve Bennett said:
whereas Picnik integration is a tool for *editors*. Not sure if that difference is significant though.
Right. I'm not sure either - I'm just hoping to bring that difference to the discussion. IMO, the distinction is significant enough to at least consider as part of the dialog.
So the objection so far seems to boil down to: It would be even better if MediaWiki natively had this functionality. I agree. Is that a reason not to make use of a third party site in the meantime?
Well, the first thing that would need to occur is for someone to create a MediaWiki extension to encapsulate this functionality. That work can be initiated immediately, regardless of whether it ever gets used on Wikipedia or other WMF projects.
I agree that even if WP never adopts the third-party integrated solution, it would be a nice thing to have this available for other users of the MediaWiki platform.
Cheers!
-- Jim
On 8/13/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/13/07, Jim Wilson wilson.jim.r@gmail.com wrote:
I'm not an expert on how Wikipedia is set up, however to my knowledge,
these
additions are not tied to the functionality of the site. That is, if
one of
those services went down, wikipedia would continue to operate as normal, just with some broken pages.
Tying actual modification functionality to a third party is a different matter (IMO). If that photo-edit site went down for a period, then that functionality would be unavailable for that duration (however long it
may
be). Whether this is acceptable is a question for people with policy setting power.
The point you're making may be too subtle for me.
Before: a) Wikipedia had no way of displaying the locations of things on maps b) Wikipedia had no way of providing extended book information based on an ISBN c) Wikipedia had no way of editing photos on the site
But it had workarounds: a) You could manually go to some other site or an atlas and look up the GPS coordinates b) You could search google for that ISBN number c) You could download the image, edit it and upload it again
Then we integrated (or are considering integration) with some third party: a) You click a link and you see a map of the location b) You click a link and see extended book information c) You click a link and edit a photo before saving it back to Wikipedia
But if that third party site goes down: a) You go back to the workaround, or use one of the other mapping services b) You click a different link c) You go back to the workaround.
Pretty similar. The real difference is actually that the map and ISBN integration are tools for *readers*, whereas Picnik integration is a tool for *editors*. Not sure if that difference is significant though.
So the objection so far seems to boil down to: It would be even better if MediaWiki natively had this functionality. I agree. Is that a reason not to make use of a third party site in the meantime? Are there other objections?
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 13/08/07, GerardM gerard.meijssen@gmail.com wrote:
Given that we have a problem in getting functionality life, important functionality like Single User Logon, it is not smart to think that we can do it all, should do it all. We have proven conclusively that we cannot do
"We", Gerard? I don't see you developing any software.
Rob Church
On 8/13/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, This is what they call the "not invented here" syndrome... There are good reasons to make use of functionality that was developed elsewhere. For one, it works and it works now.
It still requires effort for us to work into the interface. And it's going (as far as I understand) to require users to go to a different site, when we could with not too much more difficulty implement much of the same functionality ourselves. Plus yes, we do indeed have a bias against using proprietary software with Wikipedia, if we can avoid it. In the case of databases of real-world information, the only good sources are in many cases commercial and proprietary (for now), so we don't have much of a choice. But for software, why should we settle for closed-source when we can without too much more difficulty use an open-source alternative?
Given that we have a problem in getting functionality life, important functionality like Single User Logon, it is not smart to think that we can do it all, should do it all. We have proven conclusively that we cannot do it.
Since Brion is the one working on SUL and no one's suggested that he work on this, that's a rather irrelevant example.
On 8/13/07, Rob Church robchur@gmail.com wrote:
"We", Gerard? I don't see you developing any software.
The institutional "we", Rob. I don't plan on doing anything with this feature, but used "we" above, as in "we who are working (to whatever extent, and in whatever capacity) to make MediaWiki and Wikimedia projects better".
On 13/08/07, Simetrical Simetrical+wikilist@gmail.com wrote:
avoid it. In the case of databases of real-world information, the only good sources are in many cases commercial and proprietary (for now), so we don't have much of a choice. But for software, why should
Well, databases of real world information sounds like the sort of thing that's in our (institutional our) scope - Wikipedia, Wiktionary, Wikibooks, Wikisource...we don't have a free-content map project at the moment, but that may be due to the prohibitive pricing of launching the Wikimedia satellite.
Rob Church
On 8/13/07, Rob Church robchur@gmail.com wrote:
Well, databases of real world information sounds like the sort of thing that's in our (institutional our) scope - Wikipedia, Wiktionary, Wikibooks, Wikisource...
Well, bookstores aren't really in our scope. Wikimaps, maybe, but Google has quite a head-start.
we don't have a free-content map project at the moment, but that may be due to the prohibitive pricing of launching the Wikimedia satellite.
Conveniently, the good old US of A lets us use their satellite images if we like.
On 13/08/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Conveniently, the good old US of A lets us use their satellite images if we like.
If they let us use their satellite-based weaponry, I'll take back everything negative I've ever said about the US government...
Rob Church
On 8/13/07, Rob Church robchur@gmail.com wrote:
Well, databases of real world information sounds like the sort of thing that's in our (institutional our) scope - Wikipedia, Wiktionary, Wikibooks, Wikisource...we don't have a free-content map project at the moment, but that may be due to the prohibitive pricing of launching the Wikimedia satellite.
Thankfully the US government has done a lot of the work for us.
Check this out: http://tools.wikimedia.de/~dschwen/wikiminiatlas/
(click on the globe)
Try zooming in.
Okay, not as cool as google earth. But it's free, it's by one of us so we can integrate it and customize it, and it's full of our data.
On 13/08/07, Gregory Maxwell gmaxwell@gmail.com wrote:
Okay, not as cool as google earth. But it's free, it's by one of us so we can integrate it and customize it, and it's full of our data.
Indeed. Don't we have co-ordinates templates on a lot of pages? Do we link to this tool through them? Seems like something we could work towards.
Rob Church
On 8/13/07, Rob Church robchur@gmail.com wrote:
On 13/08/07, Gregory Maxwell gmaxwell@gmail.com wrote:
Okay, not as cool as google earth. But it's free, it's by one of us so we can integrate it and customize it, and it's full of our data.
Indeed. Don't we have co-ordinates templates on a lot of pages? Do we link to this tool through them? Seems like something we could work towards.
So, a commons version of this tool which display overlaid images is enabled live on commons. Anytime there is a coordinate template a link is added. For example: http://commons.wikimedia.org/wiki/Image:Wolf_Trap_%28national_park%29_meadow... (click on the blue ball)
Pt and It wikis have turned on the tool globally.
For other projects, you can turn it on in your User JS, instructions at: http://en.wikipedia.org/wiki/User:Dschwen/WikiMiniAtlas
Bringing this back on topic, Does anyone see a reason why it would be unreasonable to add a feature to mediawiki which would enable something like:
[[javascript:foo|something||arg1]] which gets converted to <a href="#" onclick="javascript:MW_UI_event_foo('arg1');;return false;">something</a>.
(and ditto for clickable image maps).
Right now tools like the popup media player and wikiminiatlas scan all anchor tags on load in order to add startup hooks, this causes a fair bit of wasted effort.
On 13/08/07, Gregory Maxwell gmaxwell@gmail.com wrote:
So, a commons version of this tool which display overlaid images is enabled live on commons. Anytime there is a coordinate template a link is added. For example: http://commons.wikimedia.org/wiki/Image:Wolf_Trap_%28national_park%29_meadow... (click on the blue ball)
Pt and It wikis have turned on the tool globally.
Any reason we shouldn't consider enabling it everywhere?
Bringing this back on topic, Does anyone see a reason why it would be unreasonable to add a feature to mediawiki which would enable something like:
[[javascript:foo|something||arg1]] which gets converted to <a href="#" onclick="javascript:MW_UI_event_foo('arg1');;return false;">something</a>.
(and ditto for clickable image maps).
Something like that seems reasonable, yes.
Rob Church
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
Bringing this back on topic, Does anyone see a reason why it would be unreasonable to add a feature to mediawiki which would enable something like:
[[javascript:foo|something||arg1]] which gets converted to <a href="#" onclick="javascript:MW_UI_event_foo('arg1');;return false;">something</a>.
(and ditto for clickable image maps).
Right now tools like the popup media player and wikiminiatlas scan all anchor tags on load in order to add startup hooks, this causes a fair bit of wasted effort.
JavaScript URLs are usually viewed as a Bad Thing. Is there a demonstrable performance problem with adding the hooks dynamically?
Simetrical wrote:
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
Bringing this back on topic, Does anyone see a reason why it would be unreasonable to add a feature to mediawiki which would enable something like:
[[javascript:foo|something||arg1]] which gets converted to <a href="#" onclick="javascript:MW_UI_event_foo('arg1');;return false;">something</a>.
(and ditto for clickable image maps).
Right now tools like the popup media player and wikiminiatlas scan all anchor tags on load in order to add startup hooks, this causes a fair bit of wasted effort.
JavaScript URLs are usually viewed as a Bad Thing. Is there a demonstrable performance problem with adding the hooks dynamically?
More to the point, that's just wrong -- remove the 'javascript:' from the onclick attribute. :)
The practical problems with href="javascript:blah" are: 1) The link is 100% useless when JS is disabled 2) You can't get anything useful out of an 'open in new window' or other sort of right-click fun stuff 3) JavaScript code appears in the browser status bar, which sucks.
Additionally there's the ideological objection: 4) Code is mixed with presentation.
That last one applies to inline definitions of event handlers like onclick="blah()" but isn't _that_ big a deal really.
-- brion vibber (brion @ wikimedia.org)
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
More to the point, that's just wrong -- remove the 'javascript:' from the onclick attribute. :)
Pshaw. It's what I mean not what I say that counts! :)
The practical problems with href="javascript:blah" are:
- The link is 100% useless when JS is disabled
- You can't get anything useful out of an 'open in new window' or other
sort of right-click fun stuff
Right well I left room to fix that in the syntax:
[[javascript:foo|something|http://wikimedia.org/functionally_equal_to_foo.php%7Carg1]] becomes: <a href="http://wikimedia.org/functionally_equal_to_foo.php?arguments=arg1" onclick="MW_UI_event_foo('arg1');return false;">something</a>
Now you nicely fall back to the link if JS is disabled.
Although I would intend and hope that this functionality only be used for things which JustCantWorkWithoutJavaScript(tm), like the clickable/draggable map thing.
Obviously, the proliferation of avoidable JS dependencies is bad and should be avoided.
- JavaScript code appears in the browser status bar, which sucks.
Under what conditions? It will appear if you do a href="javascript crud" but I don't think it will if you confine the JS to an onclick. It certainly doesn't in the really dumb test case I just created: http://tools.wikimedia.de/~gmaxwell/jstest.html
Additionally there's the ideological objection: 4) Code is mixed with presentation.
That last one applies to inline definitions of event handlers like onclick="blah()" but isn't _that_ big a deal really.
I would expect the actual use to be abstracted via templates. So the user might say {{location|23|-80}} which does some things and ends up displaying the location along with a link to bring up the map.
Doing this preserves the separation of code and presentation in practice.
If we wanted to be especially ideologically pure I suppose we could create something like a MediaWiki:LinkHandlerList which would have items like *[[Special:Mapper/mappopup]] Popupmap(), http://alternative/foo.
Then use it by just adding links of the form [[Special:Mapper/mappopup/argument]], but that seems like needless indirection to me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
More to the point, that's just wrong -- remove the 'javascript:' from the onclick attribute. :)
Pshaw. It's what I mean not what I say that counts! :)
The practical problems with href="javascript:blah" are:
- The link is 100% useless when JS is disabled
- You can't get anything useful out of an 'open in new window' or other
sort of right-click fun stuff
Right well I left room to fix that in the syntax:
[[javascript:foo|something|http://wikimedia.org/functionally_equal_to_foo.php%7Carg1]] becomes: <a href="http://wikimedia.org/functionally_equal_to_foo.php?arguments=arg1" onclick="MW_UI_event_foo('arg1');return false;">something</a>
Now you nicely fall back to the link if JS is disabled.
Although I would intend and hope that this functionality only be used for things which JustCantWorkWithoutJavaScript(tm), like the clickable/draggable map thing.
Obviously, the proliferation of avoidable JS dependencies is bad and should be avoided.
The part that always seems hard to do right is making things fall back in a clean way when JS is unavailable. Some UI elements just don't have a sensible fallback, so the best thing may be to construct them in JS itself.
I know we have issues with this now with for instance the character buttons in the edittools boxes.
- JavaScript code appears in the browser status bar, which sucks.
Under what conditions? It will appear if you do a href="javascript crud" but I don't think it will if you confine the JS to an onclick.
That's kind of why I said it only applies to href="javascript:crud", dude. :)
Additionally there's the ideological objection: 4) Code is mixed with presentation.
That last one applies to inline definitions of event handlers like onclick="blah()" but isn't _that_ big a deal really.
I would expect the actual use to be abstracted via templates. So the user might say {{location|23|-80}} which does some things and ends up displaying the location along with a link to bring up the map.
Doing this preserves the separation of code and presentation in practice.
*nod*
- -- brion vibber (brion @ wikimedia.org)
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
JavaScript URLs are usually viewed as a Bad Thing. Is there a demonstrable performance problem with adding the hooks dynamically?
I didn't mean to cast my example as a JavaScript URL. Rather, it's intended to be an onclick event attached to a null (or optionally, user specified) anchor tag.
My understanding is that doing so is not considered evil at least in so far as using JS at all is not considered evil.
Right now the performance impact of scanning anchors is below the bound I can normally measure on typical pages. But if you bring up an unusual page with many thousands of external links it does produces a measurable and notable decrease in speed.
It also seems rather inelegant to me to scan the document just to insert hooks like that which could just as easily be provided explicitly.
On 8/13/07, Gregory Maxwell gmaxwell@gmail.com wrote:
I didn't mean to cast my example as a JavaScript URL. Rather, it's intended to be an onclick event attached to a null (or optionally, user specified) anchor tag.
My understanding is that doing so is not considered evil at least in so far as using JS at all is not considered evil.
Your syntax confused me, sleepy-headed that I am. In fact, onclick and the like are also usually considered evil, for the same reasons Brion stated (except #3). If there is in fact a performance decrease in more extreme but not ridiculous cases, then of course it should be fixed even if the result is a bit ugly.
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote: [snip]
If there is in fact a performance decrease in more extreme but not ridiculous cases, then of course it should be fixed even if the result is a bit ugly.
Not doing anything on this front doesn't bother me.
I've been able to create a noticeable performance reduction of the anchor scanning approach but only in a contrived test case. Then again I am testing on fairly fast client hardware.
I will, however, be calling on your defense should someone reject some nifty tool in the basis that scanning anchor tags might theoretically be slow. ;)
(Iteration through DOM objects matching classes was cited as a performance concern for the DIV order randomization hack I made for boardvote on meta.)
On 8/14/07, Simetrical Simetrical+wikilist@gmail.com wrote:
It still requires effort for us to work into the interface. And it's going (as far as I understand) to require users to go to a different
Picnik actually recommends that you make it a frame or otherwise embed the Picnik bit inside the host site (Mediawiki).
site, when we could with not too much more difficulty implement much of the same functionality ourselves. Plus yes, we do indeed have a
I'm not convinced of that. Designing good user interfaces is hard. You really think we can produce anything close to Picnik?
bias against using proprietary software with Wikipedia, if we can avoid it. In the case of databases of real-world information, the only good sources are in many cases commercial and proprietary (for now), so we don't have much of a choice. But for software, why should we settle for closed-source when we can without too much more difficulty use an open-source alternative?
Ok, if our two choices are: Picnik or native solution, you (and probably most of us) prefer native solution. If our two choices are Picnik or nothing, I say, let's get to work.
And of course, when I say "let's", I mean me. :) With a bit of help.
Steve
On 8/13/07, Steve Bennett stevagewp@gmail.com wrote:
I'm not convinced of that. Designing good user interfaces is hard. You really think we can produce anything close to Picnik?
I'm sorry to buck the groupthink here, but I think the picnik interface isn't impressive from a "good user interface" perspective.
It's flashy, no arguments... It's fairly easy to use, but it doesn't do much: It supports cropping and resizing, and a couple of image adjustments which map to a 1d slider or two.
A braindead ajax wrapper around imagemagick offering the same features would have the same effective user interface, thought it might lack the pretty shaded buttons and the fade in loading screen. Even the smooth zoom in function should be fairly easy to implement if you don't mind making the app dependant on the browser supporting SVG.
Flashyness is not, itself, evidence of a good user interface. Picnik does have a good interface, but this is more of a product of doing very little than any user interface brillance.
On 8/14/07, Gregory Maxwell gmaxwell@gmail.com wrote:
I'm sorry to buck the groupthink here, but I think the picnik interface isn't impressive from a "good user interface" perspective.
What would be better?
It's flashy, no arguments... It's fairly easy to use, but it doesn't do much: It supports cropping and resizing, and a couple of image adjustments which map to a 1d slider or two.
Crop, rotate, resize, exposure, colour balance, sharpen, red eye, soften - what's missing that would be useful to us? Noise reduction maybe. What else?
A braindead ajax wrapper around imagemagick offering the same features would have the same effective user interface, thought it might lack the pretty shaded buttons and the fade in loading screen. Even the smooth zoom in function should be fairly easy to implement if you don't mind making the app dependant on the browser supporting SVG.
Sure. Is anyone going to implement this?
Flashyness is not, itself, evidence of a good user interface. Picnik does have a good interface, but this is more of a product of doing very little than any user interface brillance.
It does something we need, and it does it well. That's good enough for me.
Steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Steve Bennett wrote:
Ok, if our two choices are: Picnik or native solution, you (and probably most of us) prefer native solution. If our two choices are Picnik or nothing, I say, let's get to work.
If by "let's get to work" you mean "let's create a free/open solution", then great! :)
If you mean "let's integrate the proprietary, non-free tool", then I have to disagree. Relying on non-free resources to fill in gaps in the free resource universe leads to complacency and damages the motivation to create a more widely useful free resource.
That goes for software just as much as it goes for encyclopedia articles and photographs.
- -- brion vibber (brion @ wikimedia.org)
Brion said:
If by "let's get to work" you mean "let's create a free/open solution", then great! :)
I'd like to add that an OSS PHP + ImageMagik + Ajax library for image manipulation would be fantastically useful in a wide range of apps - from blogs to wikis to CMS.
Just a thought in case anyone reading this wants to fill a void and get some street cred in the PHP OSS community.
-- Jim R. Wilson (jimbojw)
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Steve Bennett wrote:
Ok, if our two choices are: Picnik or native solution, you (and probably most of us) prefer native solution. If our two choices are Picnik or nothing, I say, let's get to work.
If by "let's get to work" you mean "let's create a free/open solution", then great! :)
If you mean "let's integrate the proprietary, non-free tool", then I have to disagree. Relying on non-free resources to fill in gaps in the free resource universe leads to complacency and damages the motivation to create a more widely useful free resource.
That goes for software just as much as it goes for encyclopedia articles and photographs.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGwa1dwRnhpk1wk44RAkNvAKDD0x3H5JlKarzYnM9VApdbUU0gJwCfUgaS f+SZ0cvO3WBHqbalD14FsSw= =hrTr -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
If by "let's get to work" you mean "let's create a free/open solution", then great! :)
If you mean "let's integrate the proprietary, non-free tool", then I have to disagree. Relying on non-free resources to fill in gaps in the free resource universe leads to complacency and damages the motivation to create a more widely useful free resource.
I'm not really in a position to build an AJAX based image-editing suite from scratch. I don't have enough experience in javascript, PHP etc. OTOH, I think I can probably, possibly with a bit of help, hack some sort of integration with the 3rd party site.
So, if someone is really enthusiastic about building image editing into MediaWiki, and is willing to lead the project, then I'd love to help. I'm skeptical that the result will be as good as Picnik, but it will probably be good enough. Obviously I prefer the creation of open source software.
However, if this is just kind of idle campfire speculation, like which would be better, given no constraints, then I would rather get started on an achievable solution. There is very little work involved in the Picnik integration, presuming that we can make web-to-wikipedia uploads work.
Also, given that the relative amounts of work required for the two solutions are probably more than 10 to 1, it wouldn't be a terrible thing if we started with the Picnik integration, saw how useful it was, then used that to motivate people to write a native solution.
So, who's putting their hand up to do some coding? Or alternatively, can sketch out a plan for what needs to be done and is willing to answer questions about how MediaWiki works etc?
Steve
On 8/15/07, Steve Bennett stevagewp@gmail.com wrote:
I'm not really in a position to build an AJAX based image-editing suite from scratch. I don't have enough experience in javascript, PHP etc. OTOH, I think I can probably, possibly with a bit of help, hack some sort of integration with the 3rd party site.
[snip]
So, who's putting their hand up to do some coding? Or alternatively, can sketch out a plan for what needs to be done and is willing to answer questions about how MediaWiki works etc?
If someone gets as far as making a imagemagick wrapper where you can move sliders then hit submit and get a new image with the sliders in effect, I'll gladly write the JS needed to update the screen on the fly.
AJAX is pretty straight forward. You run a timer, or hook an event via Javascript, and when something has changed you fire off a http request to get the new output and register chunk of JS to handle the reply. The reply comes in, your handler then does something with it such as replacing part of the page with it.
On 8/15/07, Gregory Maxwell gmaxwell@gmail.com wrote:
If someone gets as far as making a imagemagick wrapper where you can move sliders then hit submit and get a new image with the sliders in effect, I'll gladly write the JS needed to update the screen on the fly.
Architecture-wise I guess you're going to have something like this:
1. Copy source image to session folder/image1.jpg 2. User specifies what changes they want 3. Call imagemagick to generate image2.jpg 4. Display image2.jpg 5. If not done yet, go to 2. Or rollback if undo requested. 6. Save imagex.jpg "over" the original image (or to some new image name), wiping the session images.
AJAX is pretty straight forward. You run a timer, or hook an event via Javascript, and when something has changed you fire off a http request to get the new output and register chunk of JS to handle the reply. The reply comes in, your handler then does something with it such as replacing part of the page with it.
What if the triggering event is server-side? Eg, the image has finished rendering, now show it? Though most of the image processing will be pretty quick, I imagine.
Steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Steve Bennett wrote:
What if the triggering event is server-side? Eg, the image has finished rendering, now show it? Though most of the image processing will be pretty quick, I imagine.
A couple ways offhand:
* Wait and poll for status repeatedly until it's done (eww!)
* Make a request which delays completing on the server end until it's done, then returns. When you get the event for completion of that load, you confirm that it returned a 'you're done' status. (If there was a timeout or other breakage, then check again.)
- -- brion vibber (brion @ wikimedia.org)
If someone gets as far as making a imagemagick wrapper where you can move sliders then hit submit and get a new image with the sliders in effect, I'll gladly write the JS needed to update the screen on the fly.
This already exists. Search for "MagickStudio" of check http://magick.net4tv.com/MagickStudio/scripts/MagickStudio.cgi for an example installation.
This is the closest thing I found to a project homepage http://studio.imagemagick.org/magick/viewforum.php?f=5
Dschwen wrote:
This already exists. Search for "MagickStudio" of check http://magick.net4tv.com/MagickStudio/scripts/MagickStudio.cgi for an example installation.
As predicted this beats the heck out of the proprietary thing, at least in terms of features. It's lacking in gloss, but that could be added.
-mark
On 8/27/07, Mark mark@geekhive.net wrote:
Dschwen wrote:
This already exists. Search for "MagickStudio" of check http://magick.net4tv.com/MagickStudio/scripts/MagickStudio.cgi for an example installation.
As predicted this beats the heck out of the proprietary thing, at least in terms of features. It's lacking in gloss, but that could be added.
It has more features, but the user interface is crappy - choosing a "Parameter" of "1.6" then selecting "Contrast-stretch" then clicking "enhance"...ugh.
You may think that the GUI is the trivial bit of the job and the image processing is the important bit, but I see it as being the other way around. Most of us have powerful image processing software on our computers. If we're going to bother with an online GUI at all, the entire point is to make the user experience faster and more pleasant than downloading the image, processing it, and uploading it again.
Everything you can do with this tool seems to require guesswork to manually enter a number. Straightening, you have to guess the right number of degrees, then undo if you get it wrong. I don't even think there is a way to crop - and if there was, it certainly wouldn't be as easy as drawing a rectangle.
Would you honestly use this kind of tool? Wouldn't you just download the image, modify it in GIMP and upload it again?
Steve
On 29/08/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/27/07, Mark mark@geekhive.net wrote:
Dschwen wrote:
This already exists. Search for "MagickStudio" of check http://magick.net4tv.com/MagickStudio/scripts/MagickStudio.cgi for an example installation.
As predicted this beats the heck out of the proprietary thing, at least in terms of features. It's lacking in gloss, but that could be added.
It has more features, but the user interface is crappy - choosing a "Parameter" of "1.6" then selecting "Contrast-stretch" then clicking "enhance"...ugh.
[snip righteous grumbling]
I think the point Mark was making was that a wrapper around ImageMagick is capable of doing all these things. We don't have to integrate this at all. Picnic's solution is horrible and proprietary, and not something we want to commit ourselves to implement support for, not least of all because the MediaWiki community as a whole will roundly reject it.
When it comes down to it, some clever person can write a nice UI that exposes this functionality and makes it comfortable for the end user. There are almost certainly people who are experienced enough with MediaWiki development who can make this sort of thing happen.
Rob Church
On 8/29/07, Rob Church robchur@gmail.com wrote:
I think the point Mark was making was that a wrapper around ImageMagick is capable of doing all these things.
Definitely.
We don't have to integrate this at all.
True.
Picnic's solution is horrible and proprietary,
It's "proprietary", yes, and closed source at that. What's "horrible" about it, though? It's a lot nicer than the GUI we were just comparing it to.
and not something we want to commit ourselves to implement support for,
Who is "we" and "ourselves"? If someone wrote an integration patch for it, would that be accepted into the mainline? Would it be enabled for Wikipedia?
not least of all because the MediaWiki community as a whole will roundly reject it.
Why would they do that? Do we have a rule against integration with proprietary software?
When it comes down to it, some clever person can write a nice UI that exposes this functionality and makes it comfortable for the end user. There are almost certainly people who are experienced enough with MediaWiki development who can make this sort of thing happen.
Examples of great GUIs written for free and released as open source are not numerous. I don't doubt that someone could hack a front end onto ImageMagick. I think producing an elegant WYSIWYG GUI would be a major undertaking, and no one has yet volunteered to make it happen.
So, as before, our choices aren't really between integrating with Picnik or doing it ourselves, because the latter option is unlikely to actually happen. The more feasible choice is between integrating with Picnik or doing nothing at all, and having no online image manipulation. Which do you think is preferable?
Steve
On 29/08/07, Steve Bennett stevagewp@gmail.com wrote:
On 8/29/07, Rob Church robchur@gmail.com wrote:
I think the point Mark was making was that a wrapper around ImageMagick is capable of doing all these things.
Definitely.
We don't have to integrate this at all.
True.
Picnic's solution is horrible and proprietary,
It's "proprietary", yes, and closed source at that. What's "horrible" about it, though? It's a lot nicer than the GUI we were just comparing it to.
The fact that it's proprietary.
and not something we want to commit ourselves to implement support for,
Who is "we" and "ourselves"? If someone wrote an integration patch for it, would that be accepted into the mainline? Would it be enabled for Wikipedia?
The lead developer has, I believe, previously commented on the issue, and expressed an opinion that an open-source solution is far preferable, so the answer is "probably not".
An integration patch for this almost certainly wouldn't be accepted into the core software.
not least of all because the MediaWiki community as a whole will roundly reject it.
Why would they do that? Do we have a rule against integration with proprietary software?
Because the community to which I am referring is one of those great "open source" communities, which thrives on sharing techniques, code, extensions - I'm talking about everyone else who uses MediaWiki, excluding Wikimedia.
So, as before, our choices aren't really between integrating with Picnik or doing it ourselves, because the latter option is unlikely to actually happen. The more feasible choice is between integrating with Picnik or doing nothing at all, and having no online image manipulation. Which do you think is preferable?
Which do *I* (and, if I may be so arrogant as to presume, a good many others) find preferable? Rolling our own solution.
Rob Church
On 8/29/07, Rob Church robchur@gmail.com wrote:
Picnic's solution is horrible and proprietary,
It's "proprietary", yes, and closed source at that. What's "horrible" about it, though? It's a lot nicer than the GUI we were just comparing it to.
The fact that it's proprietary.
Ok, "horrible and proprietary" was a tautology. I should have guessed.
The lead developer has, I believe, previously commented on the issue, and expressed an opinion that an open-source solution is far preferable, so the answer is "probably not".
I also agreed that such a solution is preferable. Someone buying you a beer is preferable to you buying yourself a beer. But if no one's shouting you, that's not going to stop you drinking, is it?
A is better than B. B is better than C. If A isn't going to happen, why shouldn't B?
Because the community to which I am referring is one of those great "open source" communities, which thrives on sharing techniques, code, extensions - I'm talking about everyone else who uses MediaWiki, excluding Wikimedia.
Yay. Integration of open source projects with closed source software is a fact of life. MediaWiki runs on Windows. It almost certainly has workarounds to make sure that it renders ok on IE.
So, as before, our choices aren't really between integrating with Picnik or doing it ourselves, because the latter option is unlikely to actually happen. The more feasible choice is between integrating with Picnik or doing nothing at all, and having no online image manipulation. Which do you think is preferable?
Which do *I* (and, if I may be so arrogant as to presume, a good many others) find preferable? Rolling our own solution.
So given a choice between B and C, you continue to choose A. We're in agreement that a home-made, open source solution with a high quality GUI is the best outcome. No argument whatsoever. But no one is volunteering to make that happen - or, to continue my analogy from above, buying you the beer. Is option B (integration with a third-party site) really worse than option C (nothing)?
Clearly this discussion is going nowhere. Bah.
Steve
On 8/28/07, Steve Bennett stevagewp@gmail.com wrote:
Who is "we" and "ourselves"? If someone wrote an integration patch for it, would that be accepted into the mainline? Would it be enabled for Wikipedia?
Almost certainly not (although it would surely be accepted as an extension). If someone wrote open-source code to do the same thing, it definitely would be accepted and enabled on Wikipedia, assuming it worked.
Why would they do that? Do we have a rule against integration with proprietary software?
I could easily be wrong, but I think the only proprietary software currently used throughout the entire process of serving pages to users is Linksys routers. Non-free software is not used unless there's a really compelling reason, such as no reasonable possibility to create a free equivalent.
So, as before, our choices aren't really between integrating with Picnik or doing it ourselves, because the latter option is unlikely to actually happen.
I don't see anyone stepping forward to do the former either. You've mentioned that maybe you'd be happy to do the integration, but Gregory has said he's working on an open-source solution.
Regardless, whether or not the latter is likely to happen, the former is not going to happen. Integrating with a proprietary solution will discourage anyone from ever bothering to make a free one.
On 8/29/07, Simetrical Simetrical+wikilist@gmail.com wrote:
is not going to happen. Integrating with a proprietary solution will discourage anyone from ever bothering to make a free one.
Citation needed.
I suspect that if there actually was integration with a third party site for image manipulation, soon people would be complaining about what features that third party site lacks. That would spur people to actually implement an alternative, because they could see that it's useful, visualise a solution, and have some clear problems to solve. The bar would also be set high: the open source solution would have to be at least as good as the proprietary one. Whereas currently people seem to think that a crappy form-based ImageMagick frontend is an acceptable substitute.
Steve
On 29/08/07, Steve Bennett stevagewp@gmail.com wrote:
be at least as good as the proprietary one. Whereas currently people seem to think that a crappy form-based ImageMagick frontend is an acceptable substitute.
"Citation needed."
No one's said that the frontend demonstrated thus far is a direct substitute; it's a proof-of-concept and a base to work on, if desired.
Rob Church
On 8/29/07, Steve Bennett stevagewp@gmail.com wrote:
I suspect that if there actually was integration with a third party site for image manipulation, soon people would be complaining about what features that third party site lacks. That would spur people to actually implement an alternative, because they could see that it's useful, visualise a solution, and have some clear problems to solve.
They would also have to start from scratch to even achieve feature parity. No, if you want to spur open-source work, put up a shoddy form-based one-day job. *Then* people will want to submit patches to fix the suckiness, with every patch motivated by the fact that it will directly improve a lousy interface that wastes their time. I think you'd get a good collaborative base done in not too much time at all.
So who wants to integrate the cruddy form-based MagickStudio or whatever, or something of our own, and see if anyone contributes improvements?
Simetrical wrote:
They would also have to start from scratch to even achieve feature parity. No, if you want to spur open-source work, put up a shoddy form-based one-day job. *Then* people will want to submit patches to fix the suckiness, with every patch motivated by the fact that it will directly improve a lousy interface that wastes their time. I think you'd get a good collaborative base done in not too much time at all.
I think that would probably get the job done.
So who wants to integrate the cruddy form-based MagickStudio or whatever, or something of our own, and see if anyone contributes improvements?
I'm really tempted.
Simetrical wrote:
So who wants to integrate the cruddy form-based MagickStudio or whatever, or something of our own, and see if anyone contributes improvements?
There's also this: http://www.ajaxprogrammer.com/?p=9
It's LGPL, and based on GD rather than ImageMagick, but it also looks like a nice jumping-off point. I suppose that one could port it.
-mark
Gregory Maxwell wrote:
I played with the site (on a friends computer, it requires flash), the interface is snazzy no doubt, but all the manipulations it offers save red-eye are things that Imagemagic could provide... I could pretty easily setup a basic ajax interface that offered those filters and let you tweak their settings in real time.
Some days ago (on the PSF uploads), i had the idea of using imageboxes.js for marking sections to crop, then run an imagemagick bot for all of them. Then i got a bug on imageboxes. Maybe i should give it another try now it's fixed.
On 8/13/07, GerardM gerard.meijssen@gmail.com wrote:
Improving of the 'quality' of pictures is not in and of itself something that is not without controversy. There have been fierce fights in the past over exactly this subject and there are a great many people that do not upload to Commons as a result.
I'm glad someone has tackled the issue of "do we actually want this integration". I think that problems *could* arise, but there is a huge amount of value in being able to quickly tweak images. You're really talking about a question of etiquette, rather than a problem of technology there. Don't forget that it's also trivial to undo any undesired changes to an image, if necessary.
Could I suggest the use of some sort of template or text that indicates how the uploader of the image feels about the image being edited and replaced:
"The uploader of this image requests that you do NOT edit and replace it. If you wish to modify it, please save the copy under a new name."
Giving the possibility to overwrite existing pictures to everyone is
imho NOT a good idea.
They already have that.
Steve
Current MW API allows users to get info about any image, including the proper URL to download it from. See http://mediawiki.org/wiki/API prop=imageinfo. The ability to upload images through the API has been planned and should be available fairly soon.
On 8/12/07, Steve Bennett stevagewp@gmail.com wrote:
There is a new tool called PicNik that allows on-web touching up of photos: all basic tools like contrast, cropping, sharpness, conversion to greyscale etc. This is something that Wikipedia in particular has really been lacking: an easy way to improve the quality of a lot of the fairly tacky travel happy snaps that get uploaded. It's definitely not free software, but a lot of the uses of it are free. They don't host your images: you upload an image, work on it for a bit, then download it again. They have integration with facebook, flickr and a few other sites.
So I asked them about MediaWiki integration. There are apparently two ways we can achive this: either we extend MediaWiki to make use of their API, or we implement an API directly to allow them to retrieve an image (obviously pretty simple), then upload the updated version (credit and authentication issues). Could someone give me an idea of how much work would be involved? I might be interested in attempting some of the coding, especially if someone else is interested and can give me some guidance.
We have an API that any third-party site can use to pass a photo over
to Picnik for editing and when the user is done editing Picnik saves the result back to the site. It looks like MediaWiki has an extension mechanism, maybe that would be a good place to start.
How could we do this? Extend the image page to have a link to Picnik, then provide a mechanism whereby Picnik can call MediaWiki with a certain URL. Picnik seems pretty flexible on this point. The URL for info about the API is as follows: http://www.picnik.com/info/api
We can also add "integration bridges" to Picnik. Integration bridges
use a third-party API to access the photos on that site. The pages in Picnik that show thumbnails from Flickr and Picasa Web and can save to them are examples of integration bridges. Does MediaWiki have an API for accessing the photo content stored in a wiki, and updating it?
I don't know the answer to that question. Obviously it's easy to retrieve the content of one image, but allowing higher level (bulk) manipulation and organisation of images would be pretty cool if that was possible. Also, are there any other ways of getting an image back into MediaWiki besides special:upload ?
Any other comments about this idea are very welcome. Particularly if there are any objections to linking to such a site. I really think the potential benefits are very significant, so hopefully those objections can be overcome.
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org