[annotator-dev] Image annotation

[Randall Leeds]

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.

The main issue with integrating with our other libraries is not that the
DOM is manipulated, but that it's manipulated implicitly as a side effect
of loading annotations. If the main application can own that part it can
coordinate the interaction with other components that need to be notified
of those changes.

I think this sort of separation, where plugins are extremely light weight
adapters between the event-driven annotator core and a clean API for some
component, is the way Annotator 2 is going. In that model, Annotoriuos
would want to expose a useful API and not simply hook itself to Annotator
events when loaded as a plugin.
On Oct 12, 2014 1:03 AM, "Simon Rainer" <Rainer.Simon at ait.ac.at> wrote:

> Hi Kristof,
>
> there may be a way around some of the nastier DOM manipulations. The
> Annotorious components could be added as absolutely positioned elements at
> the end of the body. That's potentially less intrusive.
>
> I did that initially, but it failed in cases where images are moved around
> via JS (typical scenario: image carousels). Hence the 'wrapping' that now
> occors. I think that browsers now issue 'DOM change' events, however, which
> could be used to reposition annotation overlays. So this may be worth a
> try. (Probably won't work in IE though ;-)
>
> Cheers,
> R
>
> ---
> Sent via mobile
>
>
> ________________________________________
> Von: annotator-dev [annotator-dev-bounces at lists.okfn.org]" im
> Auftrag von "Kristof Csillag [csillag at hypothes.is]
> Gesendet: Samstag, 11. Oktober 2014 14:50
> An: annotator-dev at lists.okfn.org
> Betreff: Re: [annotator-dev] Image annotation
>
> Dear all,
>
> Here is a very short summary of what we have done in H's form of Annotator.
>
>  * First, we have moved from the current annotation data format to one
> closer to the OA model: instead of ranges, we have targets, and those
> targets are described by selectors.
>  * We have defined a bunch of selectors for text (again, the same ones
> used in OA), and defined one (or two) selectors for describing image
> fragments, as described by Annotorious
>  * Extended the annotation anchoring mechanism, so that the available
> anchoring algorithms can be shipped in plugins, and registered with the
> code. When a target needs to be anchored, all the registered anchoring
> algorithms are asked if they can handle it.
>  * 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).
>  * We have extended the system to support different types of anchors and
> different types of highlights. (And we have implemented the corresponding
> types for image.)
>  * We created an image annotation plugin for Annotator, which bridged
> Annotorious with the framework in Annotator core.
>
> Actually, most of this work is independent of Image annotations, but
> considered in necessary, in order to do it the right way.
>
> In the end, we never really deployed the image annotation code, because
> Annotorious has a nasty habit of changing the DOM in various haphazard
> ways, and one of our other libraries (d-t-m, used for fuzzy text maching)
> was not quite up to the task of dealing with this, but we have a fix for
> that in the pipe, too.
>
> Now, this is all on our Annotator fork, and we plan to port it back to
> upstream Annotator 2.0.
>
> The latest plan to do so looks like this:
>  * We will release the framework (for handling multiple types of
> selectors, algorithms, anchor types, highlights, etc) as a separate
> library, with glue code for various versions of Annotator (A1.2.x, A2.0,
> our fork)
>  * We will release separate libraries that contain the various pieces of
> functionality which we implemented on top of this framework (fuzzy
> anchoring for text, image anchoring, annotator running over pdf.js, etc.)
>
> Does this look good to you all?
>
>    Kristof
>
>
> On 2014-10-10 20:24, Jamie M Folsom wrote:
>
> Hi Folks,
>
> We have a developer working with us this fall who is interested in helping
> with image annotation, so I thought we’d reach out and see what work has
> and has not been done on that in the Annotator ecosystem.
>
> Gergely mentioned back in May that there was some work done on h. We’d be
> glad to pitch in and work on a plugin that others could use, but I don’t
> want to duplicate effort if there’s something else underway.
>
> Thanks!
>
> Jamie
>
>
>
>
>
> _______________________________________________
> 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
> https://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20141012/cc935524/attachment-0004.html>