Admittedly, I'm a Flickr noob and only recently made an account for myself. I'm not entirely pleased with the interface because frankly, it's too busy and inconsistent for my liking. However, I just stumbled across Picnik. From their FAQ:
What is Picnik?
Picnik is photo editing awesomeness, online, in your browser. It's the easiest way on the Web to fix underexposed photos, remove red-eye, or apply effects to your photos.
Not only that, it is well hooked into Flickr, Facebook and a number of other sites. What struck me about one of the features in their somewhat hidden tools are Firefox and Internet Explorer extensions. Now, extensions in Firefox are relatively easy to construct, but Internet Explorer extensions are a bit of a pain. So, I was curious to see what they did. It is a registry hack that contains the following:
Windows Registry Editor Version 5.00; See http://msdn.microsoft.com/workshop/browser/ext/tutorials/context.asp for details
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt\Edit in &Picnik] @="http://www.picnik.com/extensions/ie-import.html"
"Contexts"=dword:00000002
That hack installs an option in the right-click context menu within Internet Explorer. When the hack is installed, you may right-click any image on a web page and choose "Edit in Picnik". I tried it and of course, the URL to the image is seamlessly grabbed and the image is immeditalely available in Picnik for editing using its rich array of very easy to use tools.Being naturally curious, I pointed the URL in that above registry hack to http://www.picnik.com/extensions/ie-import.html and was presented with a web page alert whose source was the following:
<html><body>
<script>
// See http://msdn.microsoft.com/workshop/browser/ext/tutorials/context.asp for details
try {
var wndParent = external.menuArguments;
var strImportURL = wndParent.event.srcElement.src;
wndParent.location = "http://www.picnik.com/?import=" + strImportURL;
} catch (ex) {
alert("Unable to import image. Let us know at feedback@picnik.com");
}
</script>
Edit in Picnik for Internet Explorer
</body></html>
So, it seems the registry hack merely calls the URL to an image and feeds it as a querystring parameter into Picnik. Pretty slick. But there's more...
You can grab any image like this, edit it in Picnik, then seamlessly send it to your Flickr account using the behind-the-scenes Flickr API. Technically, you never have to interface with the busy Flickr site. Almost everything can be done within Picnik from grabbing either a local image from your hard drive, web site, etc., editing it using its fully online, smooth and easy to use image editing tools, then you can push the result out to Flickr or Facebbok, send it via email, save it back to your hard drive, plus a number of other export options. Wow.
Grabbing images like this off a web page & then sending it off to Flickr certainly has some serious copyright issues and speaks volumes about the sociology of the web culture. This is exactly the kind of content ownership issues that seem not to phase other emerging application developers like those behind Zude or ZCubes. Where's the justice? Do Creative Commons licenses make a whole hill of beans worth of difference when there are tools like these? I tried to get this notion across to the participants & contributors in/to BugGuide (see discussion) as encouragement to think about an API to propagate their great work in other resources like the Encyclopedia of Life. There are lots of synergistic reasons for building a simple API. BugGuide is a rich, longstanding, community-driven resource for people to post their images of NA arthropods, author guide pages, discuss issues in a forum, among other really useful functions. Getting nomenclatural data from an Encyclopedia of Life API would be one simple example of potential information flow back to BugGuide.
One of the shortcomings of Picnik, Zude, and ZCubes is that there is no way to retain any accreditation other than the host domain for where the image was "ripped". It also means that MediaRSS extensions for RSS 2.0 or the FOAF and Dublin Core vocabularies for RSS 1.0 are entirely useless in this context because they aren't being used even if the data were available. What I think Picnik, Zude, and ZCubes (& Flickr too for that matter) ought to consider is an embedded meta data reader/writer for images. If this is so commonly done with MP3 music files, why is this taking so long for image files?
4 comments:
Very interesting, Dave. I don't see that this sort of application changes things all that fundamentally--it has always been easy to grab an image off of the web--right-click and copy image. (Flickr may cover with a clear gif, but one can just do a screenshot.) I do see how the ease of upload is going to tempt some people to say, populate their Flickr account with the images of others. I guess there is nothing other than community standards to prevent that. I have a Flickr account and enjoy it very much, especially interaction with other nature nuts. If I started uploading somebody else's images, I would certainly get some questions from my peers. Now if somebody wants to violate copyright wholesale, there is really nothing to prevent them from doing so, but what do they gain?
I will add that editing a low-resolution JPEG usually gets you into trouble rather quickly--artifacts crop up upon saving. So that is one rather built-in copyright protection of web image. Any serious work requires going back to the original image--RAW format or a high-resolution JPEG. (Some people post original high-resolution JPEGs on the web, but not most serious photographers.)
The apps mentioned seems like they just play on the flexibility of HTML rather than getting into the copyright issues. I think ZCubes (maybe Pageflakes, Netvibes, Goowy and Zude too) works this way. Instead of having the image be copied to another server, it retains the original link so that if there is a copyright concern by the original author, they can just cut the link or deny access.
The fact is most images on the open internet, is not intended to have copyright issues, since they are directly accessible by any browser with their URL. It is when an image is copied into another server that there can be lack of control by the original author/poster. There are several techniques (like "Remote Linking Forbidden") messages that one can use to avoid remote linking if not acceptable.
With the newer trends in sharing, maybe the standard copyright laws intended to protect works of art may also need to evolve so as not to feed the legal eagles - and instead create more intellectual sharing and growth.
In Zude, right-clicking on anything dragged-in or pasted from the web brings up a menu that includes "Source" -- as in: where did this originate from. Clicking on this option takes the user directly to the originating site. An alternative display (for complex compound objects) shows the Zude tracking information, current user identification, and links to copyright rules and regulations. For copyright holders, Zude provides real-time information regarding distribution of their materials within Zude and can disable unauthorized use. Zude takes this issue very seriously and will continue to refine and enhance its processes to the benefit of all.
Patrick -
Happy to hear it may just be me who harbors unnecessary paranoia. Indeed, you are correct. The act of importing others' photos into Flickr, copy it to one's hard drive (& consequently forget where it came from), is ultimately something the individual has to decide. My concern is the ease with which this can now be done. I think what would be a step in the right direction is if digital camera manufacturers bundled a little application inside a "free" memory card that, when run on the desktop, allows an individual to write their name, contact information, etc. that can be written back onto the camera's internal memory chip. When photos are taken, that metadata can be embedded into all photos taken. We have EXIF already for specifics, why not extend this a bit?
Steve -
Thanks for stopping by. I have been keeping my eye on Zude and have watched several videos of you guys in action.
I think maintaining the source is a great start, but I'd like to see this evolve quite a bit more. The source of the image may not necessarily provide adequate accreditation, especially with sites like BugGuide where it's the individual who needs to be credited. This is why I'd like to see image metadata evolve beyond EXIF. There are certainly other metadata standards that can fit the bill, but I'd like to see digital camera manufacturers start making use of them.
Post a Comment