Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    aneuroo
    @aneuroo
    I want to add a polygon to my view, what does the polygon look like in the JSON file to genetrate the elements onto the openseadragon viewer
    Rainer Simon
    @rsimon
    @aneuroo Annotorious uses the W3C Web Annotation format. You can find an example for a rectangle and a polygon here:
    https://recogito.github.io/annotorious/getting-started/web-annotation/
    aneuroo
    @aneuroo
    Yeah thats got it Thanks!!
    Garet-Jax
    @Garet-Jax

    For those interested, I needed to "hack" annotorious to get the dropdown to open automatically. The change was simple. Inside of Autocomplete.jsx:
    const onFocus = evt => {
    if (!isOpen) {
    this.setState({ inputItems: this.props.vocabulary }); // Show all options on focus
    openMenu()
    } // if
    } // onFocus

    and I needed to add onFocus to the Input tag:
    <input {...getInputProps({ onKeyUp, onFocus })} placeholder={this.props.placeholder} />

    Garet-Jax
    @Garet-Jax
    I am now trying to save and close the annotation when the user selects one of the pre-defined tags. That way they don't have to click the OK button. The vast majority of our annotations will only ever have one tag. I have tried many things, but the body of the tag is not being saved no matter where I trigger the saveSelection() API. Given the name of the save API, will it ever be able to save the body? If so, any suggestions on how to achieve this functionality? I have even triggered the onOk method from the Editor.jsx. It seems like the events I can subscribe to or have access to are not late enough to include the body.
    Rainer Simon
    @rsimon
    @Garet-Jax I'd need to test this more thoroughly. But, in principle, .saveSelected is a programmatic way to hit the Ok button on the currently selected annotation. My guess is that the body isn't added to the annotation yet when you call .saveSelected.
    Internally, this part of the app is written in React. Adding the body is an async operation. If you add the body in your modified autocomplete, and immediately call saveSelected, then the body update would likely not yet have happened.
    To test: could you wait for a few ms before calling saveSelected? I.e. a setTimeout with a bit of delay? At least that way you could test my hypothesis :-) (If it's right, the save should store the body then )
    Garet-Jax
    @Garet-Jax

    @rsimon Yeah that is my guess too. I have tried to listen to various events and trigger the save at the last possible chance in those events. That makes sense. I was thinking of adding a custom event that gets fired when the body is added. That way I can trigger save from that event.

    I have actually tried a setTimeout (think I waited for 5 seconds) before triggering save. That didn't work either.

    @rsimon Thanks for a great piece of software and additional thoughts here.
    Rainer Simon
    @rsimon
    FWIW that kind of "save immediately" functionality sounds pretty useful, generally. I'll look into making this available as callback option perhaps. (Eg. in addition to onAppendBody an onAppendBodyAndOk or sighting.)
    Damn... 5 seconds should be enough even fit React ;-) I'll try to dig into this myself when I get the chance.
    "fit" -> "for"
    Rainer Simon
    @rsimon
    @Garet-Jax ok checked now, and indeed - saveSelected() works only in conjunction with headless mode. It not possible to use it with the editor enabled. (Since only the editor is aware of the currently edited annotation state. .saveSelected sits one level "higher up" in the hierarchy, since it was originally designed for usage without editor.)
    I think the cleaner way might indeed be to extend the editor/plugin API with a "addBodyAndSave" callback. I'll try to think through this soon-ish, so perhaps can add this to the next release. This way you should be able to create a plugin that closes the editor right after user action, without the need for complicated hacks.
    Alexander Hagerman
    @n0mn0m
    Screen Shot 2021-06-16 at 9.31.47 AM.png
    Hi, I was hoping to get some feedback and ideas on positioning the editor. I've stepped through the editor functions and found my way to setPosition where the editor position is set dynamically. Most of the time this works great. I have received feedback though that sometimes this makes resizing the annotation difficult because the editor covers the top handles and blocks using those for resizing. Any thoughts on increasing the margin when this is positioned at the top so that the editor never blocks annotation handles? Happy to work on a PR for this, or implement it higher up if there is something I can do custom for the editor position with styling, but wanted to see what ideas exist for this. I recreated the behavior with the Getting Started page to help visualize the behavior.
    Garet-Jax
    @Garet-Jax
    @rsimon - any feedback you can provide would be much appreciated. The onAppendBody and onUpdateBody methods from Editor.jsx are triggered very early in the click tag process. I put a listener into the onStateChange method in Autocomplete.jsx and type 17 was the last one triggered during the course of a normal click tag sequence. Even when I tried to execute something after onStateChange type 17 was received, it still wasn't late enough. Will keep looking.
    Rainer Simon
    @rsimon
    @n0mn0m I've been thinking about this myself and still didn't come to a conclusion. I agree it's a problem that the editor sometimes gets in the way (or covers - as you show in your image) the handles. Personally, what I think I'd like to do as a user is, maybe, simply grab the editor and move it to some other place manually. And it would stay there until the annotation gets saved/deselected. (After which, the auto-position would kick in like normal.)
    Really a matter of taste though - I'm interested in hearing differing opinions!
    @Garet-Jax the problem is that .saveSelected() really just works in headless mode. (Sorry for this - I completely forgot about this myself, and only realized when I re-read the code yesterday.) At minimum, the function should be renamed. Ideally, the code needs rewriting so that .saveSelected() would be aware of the current draft annotation state in the editor, if Annotorious is not in headless mode.
    It's a bit tricky though, because it breaks the React state hierarchy a bit. (The editor keeps its own state, .saveSelected() is handled one component further up, which doesn't know the state.) This would need changing before I can change the behavior of .saveSelected().
    2 replies
    Alexander Hagerman
    @n0mn0m
    @rsimon we had actually talked about looking into the ability to have the editor float/be moved. I personally think that's a great solution long term, because then most edge cases are handled by being able to just move the box wherever you want it. One piece of feedback that I got was that it would be nice if the editor never opened inside the annotation boundary even if that mean scrolling to see the editor that way it would never obscure the view of the annotated area.
    Rainer Simon
    @rsimon
    @n0mn0m hm, I'm not sure about always keeping it outside. It's really tricky with all the possible edge case. Right now the editor aims to stay fully inside the viewport. Bascially assuming that obscuring the annotation is better than pushing the editor outside the viewport, where it's not (or only partially) visible - which is a user feedback that I got :-) But in any case, +1 from me for manual moving. It's probably not hugely difficult I guess.
    4 replies
    Rainer Simon
    @rsimon
    I can try to hack a proof of concept with react-draggable on the weekend. (Looks a bit oversized with 270kB. But it would probably help to build something quickly.)
    Alexander Hagerman
    @n0mn0m
    Cool, I was going to ask if you had any tips or pointers for digging into moving the editor based on mouse events.
    Rainer Simon
    @rsimon
    react-draggable was really just the first thing I googled just now. I think once its working with some (any) library, and the interaction looks good, it's always possible to dig further and perhaps find a more lightweight solution.
    Alexander Hagerman
    @n0mn0m
    @rsimon I got some time to hack on this today actually. And when I say hack, I mean hack. It's not pretty. For some context right now the project has been setup with javascript scripts embedded in SSR templates (no babel, webpack etc). Over time plan to work on that, but for now it's what I'm working with. I can move the editor using this I wrap the annotation area with an element where the id is annotationContainer and can move the editor when it's available. The catch here is that when you click a handle the editor returns to the previous position based on the event handler and component lifecycle. Any ideas on how to disable that update? May not be possible, but thought I would ask since this solves things short term.
    Rainer Simon
    @rsimon
    @n0mn0m nice! Yes, that should be most of what's needed. You can't disable the update from the outside. (At least I can't think of a way that wouldn't involve changing code inside setPosition). But setPosition is exactly the place where your code would need to hook into. I'll try to take a stab at this on the weekend.
    Alexander Hagerman
    @n0mn0m
    :thumbsup: sounds good. Thanks for confirming that!
    Rainer Simon
    @rsimon
    @n0mn0m I got it working! Used react-draggable, and it was remarkably easy. It also looks like it doesn't add significantly to the bundle size, so I might stick with that.
    Peek 2021-06-17 20-55.gif
    2 replies
    Here's the commit, for info. I'm keeping it in a separate branch for now. Will check whether anything can be optimized in terms of bundle size. But after that, I think, I'll make it a feature in the next release. recogito/recogito-client-core@48c5919
    David Rusu
    @davidrusu

    Do you remember why naturalWidth/Height is used here: https://github.com/recogito/annotorious/blob/main/src/AnnotationLayer.js#L22 ?

    (as opposed to using the width/height attributes)

    I'm debugging some issues with <img>'s where the source is an SVG.

    On firefox, the img tag will have a naturalWidth/Height of 0

    Rainer Simon
    @rsimon
    @davidrusu yes, it's to support responsive images. The annotations need to use naturalWidth/naturalHeight, in order to stay aligned with the original image size. If the image is resized, the annotation shrink/grow with it. width/height on the other hand will only give you the size of the image element.
    I never tried using Annotorious with SVG. Indeed that might not work...
    Not sure if there's a good workaround.
    David Rusu
    @davidrusu

    I'm attempting to add annotations to some handwritten websites, you can see an example here:

    https://marker.network/@david

    I'll try to hack annotorious into working with SVG's, maybe I can contribute a patch
    Rainer Simon
    @rsimon
    @davidrusu I think it might be sufficient to monkey-patch the SVG image element and attach naturalWidth and naturalHeight props manually. E.g. el.naturalWidth = el.naturalWidth || el.width or something like that. This way, the width would serve as a default if the el doesn't have naturalWidth already (or naturalWidth of 0).
    Umesh Timalsina
    @umesh-timalsina
    Hello @rsimon, I have worked on a feature that add events in OSDAnnotorious when the viewer is in sequence mode and there's a page change event. The diff is here and local testing seems to work correctly. Example in index.html. Would you be willing to accept a PR for this?
    Rainer Simon
    @rsimon
    Hi @umesh-timalsina, this is great - many many thanks! I think I'd like to refactor two things just a little bit (actually three):
    • I don't think Annotorious needs to fire an event for the page change. The client app should probably listen to the OSD viewer for this event (since it's an OSD concern)
    • I think the call to re-init the annotation layer in response to a page change can happen entirely inside OSDAnnotationLayer class. Right now, there's an event that goes from OSDAnnotationLayer up to OpenSeadragonAnnotator, and then OpenSeadragonAnnotator calls back down to OSDAnnotationLayer to re-init. That's probably not necessary?
    • Minor thing: I think it would be better to have a separate demo page for sequence mode, i.e. not the normal index.html, but maybe a sequence-mode.html right next to it?
    AlaEmrani
    @AlaEmrani
    Hello @rsimon
    I'm so glad to see you revised the circle annotation code and merged it. I tested it and it works perfectly, but why it can't be used in OSD version? I updated the OSD version but its used Annotorious version isn't contained circle annotation
    and my other question is I want to add a point annotation, is it ok to do it like circle annotation creation or according to your new changes i should do something else?
    Hero-Solutions
    @Hero-Solutions
    @AlaEmrani The CircleFragmentSelector is not compliant to the W3C annotation model. My guess would be that he didn't want to include it in the official release on npm yet because of this reason (although I can't be sure). He's currently refactoring the codebase to make the circle selection tool standard compliant and to provide a better framework to add other shapes. Please keep in mind that because of this currently ongoing refactoring process, any circle shapes made with the current codebase will break on the next release of Annotorious.
    Once he's done with the refactoring, I will also include an ellipse selector. FYI, I also need these to work in OSD because that's what I'm using for my current project.
    Rainer Simon
    @rsimon
    Hi @AlaEmrani + thanks @Hero-Solutions, yes that's right - I wanted to fix the standards issue first. That's done now 🎉. I still want to refactor into a plugin before the next release, rather than bundle it into the core codebase. But that won't take very long anymore, and the plugin will be compatible with both Annotorious standard and AnnotoriousOSD.
    @AlaEmrani, yes a point annotation would be great. I actually created a ticket for this a few days ago, but did't start to work on anything yet. recogito/annotorious#128 Therefore: if you want to help out, that would be awesome. Again, I think we need to figure out how the WebAnno standard would deal with this. I can do some research and add the info to the issue ticket.