Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can Loris support autogenerating a watermark? #46

Open
tomcramer opened this issue Dec 2, 2013 · 1 comment
Open

Can Loris support autogenerating a watermark? #46

tomcramer opened this issue Dec 2, 2013 · 1 comment

Comments

@tomcramer
Copy link

As an image repository, I'm interested in giving donors a sense of control of their images once posted on the website. For downloading or printing any image above a certain resolution, I'd like to add a watermark that provides attribution and/or discourages unlicensed exploitation of the image.

@jpstroop
Copy link
Member

jpstroop commented Dec 3, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants