Can Loris support autogenerating a watermark? about loris HOT 1 OPEN

Use case?

Some thoughts in the meantime:

• The libraries with which Loris is built could easily do a transparent overlay on an image.

• The IIIF image API does not address this feature (should it? probably--almost definitely--not).

• The logic for when to apply a watermark would have to be entirely server-side, because if the URI for the derivative was, say:

  http://{server}/loris/{id}/full/full/0/native.jpg?watermark=true
  

  then it wouldn't be tough to figure out what

  http://{server}/loris/{id}/full/full/0/native.jpg?watermark=false
  

  is likely to do. Sure there could be something more opaque baked into the identifier, but that would be ugly.

• Assuming whether or not the image needs to be watermarked or not (and how) could be determined as part of the resolution step (i.e. where we take the ID in the URI and turn it into a file system path...by default this is just string concatenation but it could be made more complex to query a repository system), one approach would be to add watermark_id or something like that as an optional parameter that the resolver can return, and when it's present, get that overlay (from the app? from the repository?) and revise the transformation scenario to take an optional path to the overlay to apply.

• Should the image have the same URI with and without watermarks? This would make caching more difficult, especially if you wanted to allow some users to see the images without the watermark, say, if they were within an IP range. Put another way, is the image, when viewed through the server, always or conditionally watermarked?

So, the devil is in the details...let me know more.

Amendment
I'd forgotten about the Djatoka watermark plugin. Is this anything like what you're after? We never used it here, but it looks like it makes the assumption that all (or none) of the images from the server will be watermarked; I'd want to be more flexible.

from loris.