[annotator-dev] Image annotation

Mon Oct 13 05:58:34 UTC 2014

< 1) The annotations are stored against the URI from which the image was loaded in the browser, so a digital object with its own PID, served from two different delivery layers did not line up. Should have been simple to fix by making the attribute it draws the URI from configurable rather than assuming 'src'... maybe it already is and I missed it?>

It is configurable. You can 'override' the physical src by setting a 'data-original' attribute on the image element. Annotorious will then use this in lieu of src to store the annotations against. This way you can handle cases where you want to identify different (resolution) versions of the same image under a single URI/identifier. 

2) relates (somewhat) to the discussions about DOM manipulations, and the need to listen to DOM change events & reposition the annotation layers, and is simply not fully supported in Annotorious as it stands.

3) is just a different use case, I guess. But could likely be handled in a similar fashion as Annotorious handles images right now (since it just places a canvas in front of the annotated image).

Cheers,
R

---
Sent via mobile

________________________________________
Von: Greg Pendlebury [greg.pendlebury at gmail.com]
Gesendet: Sonntag, 12. Oktober 2014 23:14
An: Simon Rainer
Cc: Nick Stenning; annotator-dev at lists.okfn.org
Betreff: Re: [annotator-dev] Image annotation

"Also, we extended the system to (logically) separate anchors (as the abstract information about where an annotation goes) from the highlight (as the actual "physical" manifestation of an anchor, visible to the user)."

I'm not certain, but does this address the issue of Annotorious annotating the 'src' attribute of the image as though it was a persistent ID?

I could be being unfair in my assessment (apologies if so) because I only looked at Annotorious briefly during our original assessment of Annotator. It had two (maybe three) main problems which prevented uptake here:

 1) The annotations are stored against the URI from which the image was loaded in the browser, so a digital object with its own PID, served from two different delivery layers did not line up. Should have been simple to fix by making the attribute it draws the URI from configurable rather than assuming 'src'... maybe it already is and I missed it?
 2) Numerous display glitches when the image is scrolled off screen at page load or in a non-visible screen region (eg. jQuery UI tab).
 3) This one is unrealistic maybe... but we where trying to find a plugin that could handle non-images... such as a div with scrolling image tiles inside that _look_ like an image to the user, but can't be targeted as an image in the DOM.

Having said that, it was still the closest we found to a functional solution. Staff here really liked the look and feel of the plugin generally and it was filed in our project doco as something we assumed we would used as a starting point when image annotations became required.

Ta,
Greg

On 13 October 2014 05:25, Simon Rainer <Rainer.Simon at ait.ac.at<mailto:Rainer.Simon at ait.ac.at>> wrote:
Sorry - that last one should have said "Hi Nick" (in addition to Hi Randall) of course... argh. All those hasty E-Mails ;-)

---

Hi Randall,

sounds good - and it seems pretty much similar to how Annotorious works internally, too. Creating a new annotation is separated from display of existing ones. The former is handled in something called a "selector" - so that could be turned into the ImageSelector you are talking about. The latter is handled in a component called "viewer" in Annotorious terminology; that would be the highlighter. The viewer/highlighter has Create/Update/Delete methods, just like you describe below. The selector emits "onCreated", "onUpdated"-like events that can be subscribed to.

The only tighter coupling between the two is that the selector also includes the code for rendering a single shape to the Canvas context. The reason for this is that I wanted to keep the selectors pluggable themselves. So new selectors would allow people to draw new types of shapes that the Annotorious core wouldn't need to know about; and the selector plugin would just ship the drawing code for both the selecting and the highlighting. (Although to be fair, there is currently only one official selector - which is the Rectangle selector. A polygon and a freehand selector exist only as "experimental".)

Cheers,
Rainer

________________________________________
Von: annotator-dev [annotator-dev-bounces at lists.okfn.org<mailto:annotator-dev-bounces at lists.okfn.org>]" im Auftrag von "Nick Stenning [nick at whiteink.com<mailto:nick at whiteink.com>]
Gesendet: Sonntag, 12. Oktober 2014 19:50
An: annotator-dev at lists.okfn.org<mailto:annotator-dev at lists.okfn.org>
Betreff: Re: [annotator-dev] Image annotation

On Sun, Oct 12, 2014, at 18:22, Randall Leeds wrote:
> Another potentially useful direction to go would be to separate the steps
> of identifying and highlighting the anchors. It should be possible to use
> the selector implementation to get the image element and bounding box
> information. With OS integration that'd probably be adjusted for zoom and
> pan.

Randall is bang on in regard to how this works in Annotator 2.0.

Selecting an area for annotation and drawing a loaded annotation are
entirely decoupled from one another. The first part is handled by a
piece of the UI called TextSelector:

https://github.com/openannotation/annotator/blob/8d126eb/src/ui/textselector.js

To create a TextSelector, you give it a bounding element within which it
should respond to selections, and a callback to call when a selection is
made:

    var ts = new TextSelector(document.body, {
        onSelection: function (ranges, event) { ... }
    });

I would imagine an image selector being very similar in API.

The Highlighter is a completely separate component, which is given an
element within which to search for and draw highlights, and exposes an
API of draw/undraw/redraw (for create/delete/update respectively) as
well as a "drawAll" method for bulk load:

https://github.com/openannotation/annotator/blob/8d126eb/src/ui/highlighter.js

There is also a plugin which sets up a highlighter to respond to the
appropriate annotation lifecycle hooks:

https://github.com/openannotation/annotator/blob/8d126eb/src/plugin/highlighter.js

But in the default instantiation of Annotator the DefaultUI plugin is
used, which hooks up the TextSelector and Highlighter in the following
lines:

https://github.com/openannotation/annotator/blob/8d126eb/src/plugin/defaultui.js#L132-L144
https://github.com/openannotation/annotator/blob/8d126eb/src/plugin/defaultui.js#L182-L185

It should be possible to build an ImageSelector and ImageHighlighter (or
similar) components that work in much the same way, and which can be
configured to trigger the same adder, editor, and viewer as the rest of
Annotator.

Best,
N
_______________________________________________
annotator-dev mailing list
annotator-dev at lists.okfn.org<mailto:annotator-dev at lists.okfn.org>
https://lists.okfn.org/mailman/listinfo/annotator-dev
Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
_______________________________________________
annotator-dev mailing list
annotator-dev at lists.okfn.org<mailto:annotator-dev at lists.okfn.org>
https://lists.okfn.org/mailman/listinfo/annotator-dev
Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
_______________________________________________
annotator-dev mailing list
annotator-dev at lists.okfn.org<mailto:annotator-dev at lists.okfn.org>
https://lists.okfn.org/mailman/listinfo/annotator-dev
Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev