I thought the point of watermarking is to prevent people from using your images without your branding, but if it's done on the client side, it's easy to circumvent:
I guess it depends on the person. For example, I release all my photography as CC-BY-SA. So I'm okay with anyone either
(a) using my watermarked images as-is, without needing to write a credit separately, since the watermark is effectively an attribution
OR
(b) using my unwatermarked images for whatever CC-BY-SA compliant derivative works, and display attribution in some other appropriate fashion.
So I display watermarked images in the browser by default, primarily for convenient sharing without worrying about attribution, but make the unwatermarked images available for download if someone needs it for (b).
You are correct. This would serve the purpose for many users who don't know how to go digging around for urls in JS, but more importantly its a tool for generating them on the client so a server doesn't have to - say for a CMS?
That's all fine until Googlebot-Image comes along, collects up all your unwatermarked images, and displays them in search results for the world to use.
I can see this being useful for running as a batch process in Node/IO.js and uploading to, say, S3.
Well what if you batch it in the browser? It is quite possible to use file inputs to generate watermarked images without ever storing the image you are watermarking, and then upload the result.
Not only can this be circumvented with extreme ease[1], but it also:
(a) Make the website quite heavier. Especially for mobile devices, old computers, etc.
(b) Stops breaking with noscript.
(c) Search engines won't find your watermarked photos. In order to get credit for your stuff, people need to find it to re-use it first.
I am seeing the same arguments made :) - Watermarking an on-page element does allow the original image to be access quite easily.
However, I will reiterate it is pretty useful to watermark from a user upload. You can watermark an image from the user's local machine - upload it, then display it. All from the client. I don't believe there is any easy in circumventing this method - if there is I would love to see it :)
I can see how it might be counterproductive to do this live in the browser, as someone with an ounce of technical skills can find your un-watermarked images.
But using this to generate a watermark and upload it to somewhere like S3, to then display on pages is pretty sweet.
For instance, this might be utilized by a CMS plugin to support uploading images, watermarking them, and shipping them off to the cloud.
If there is a way of saving the result and posting it to the server (caveat: I have no idea if there currently is, there almost certainly isn't in a "95 of web users will have a compatible client" sort of way) then you could use this to remove some CPU load when accepting images that you want to watermark before presenting to other users. If it is your image being watermarked you are unlikely to circumvent the process.
Yes. Absolutely. The library includes a blob() function for converting a watermarked image to a blob for use with FormData. The site has a demo that does just this for uploading to S3. Any browser supporting File API, FormData, and typed arrays should have no problems. IE 10 is the earliest IE that supports these APIs out of the box, but there are polyfills for IE9. The other modern browsers have supported these APIs for a while now.
Interesting. I didn't realise those things had progressed so far into "generally stable and usable" territory client-side - an occupational hazard due to most of our clients being stuck on IE8 so I only play with less ancient "standards" when I find time for projects outside the day-job. I really need to try arrange some proper play time for myself soon!
How so? Being able to generate watermarks in the browser is one less thing a server has to do right? Especially if that server is in a shared environment without image libraries or lacks tools for uploading things concurrently.
Anything that happens client-side is out of your hands.
An potential image thief could just make his browser not run the watermarking function if he wanted. What we are essentially doing here is handing the image thief an image, and then handing him a watermark, and then telling him to watermark the image himself (with no guarantee that he will actually do so).
Watermarking by urls or existing images would leave the non-watermarked image open - you are correct. This case is still fine for most users, but watermark.js also allows the use of file inputs. You can grab an image from a file input, then watermark, then upload it. This would leave the non-watermarked image closed off to anyone else. This would be handy if you need to generate watermarks in a CMS backend or some other administrative tool
I think the point is to create watermarked images in the browser for later use. Once that's done, you only show users the watermarked version. This is for administrative use, not end-user presentation.
The only real use case for this is as a watermarking tool that the end user uses to place his own watermark on his own images and as has been mentioned could provide a pre-composited file generated on the client to the server for later public consumption.
Of course, this doesn't prevent the user uploading an image that they don't have the rights to and watermarking it as if it was their own... that's a whole other subject.
But it's a good demonstration of the capabilities available in modern browsers :)
Would be more useful on the server. I don't know how it is impplemented, I guess it uses canvas, fortunately there a few serverside canvas implementations available.
I think this library could defer altering the window object until it is certain it is in a browser context. The original design goal was for a browser, but the issue has already come up on leveraging node-canvas to make it useful on the server as well:
http://brianium.github.io/watermarkjs/img/shepherd.jpg