Accessing annotation state in headless mode

[ferropasha]

I am sorry I am probably missing something very basic but nevertheless here is my problem.
I am experimenting with annotorious-openseadragon in headless mode. How do I get annotation's new coordinates after moving selection to a new position or changing it's shape by dragging one of the corners? Simply using something like the snippet below returns coordinates the annotation was initially loaded with. How do I get updated position?

annotations= anno.getAnnotations()
coords_string = annotations[0].target.selector.value
console.log(coords_string)

[rsimon]

getAnnotations() will return the updated state only after the annotation was 'saved', which is after the user has de-selected it. If you want to track the live state of the current selection:

• The changeSelectionTarget event will fire if the user moves/changes the shape.
• I'd need to double-check myself, but: I believe anno.getSelected() will also return the live state of the current selection.

[ferropasha]

Thank you very much. I am now able to successfully track selection box's current state with changeSelectionTarget event.
Allow me to ask your advice on one more problem. One of the tasks I am trying to accomplish is to prevent users from dragging selection box corners outside of actual image. For that purpose I'm trying to determine a moment when for instance x-axis coordinate for selection's top-left hits zero. To test my idea I attached experimental function (see below) to the event, but it doesn't work, that is I never get expected log output in case my test condition is formulated like this if (parseInt(tl_x)==0), though if I change the condition to if (parseInt(tl_x)<0) it does work. Does it mean that at no point in time the x-coordinate that gets picked up by changeSelectionTarget is actually equal to zero (i.e. the exact moment of crossing the image border can't be determined)?

anno.on("changeSelectionTarget", function(target) {
	coords_string = target.selector.value.replace("xywh=pixel:","")
	coords=coords_string.split(",")
	tl_x=coords[0]
	tl_y=coords[1]
	width=coords[2]
	height=coords[3]
        if (parseInt(tl_x)==0){
	   console.log("Hitting border!")
	 }
 });`

[rsimon]

That's probably because of rounding issues. SVG uses float coordinates, and the coordinate is unlikely to be 0 exactly. You could either compare by <=, or do a Math.round(tl_x).

[ferropasha]

I amended my test code according to your suggestion like this

 anno.on("changeSelectionTarget", function(target) {
		  coords_string = target.selector.value.replace("xywh=pixel:","")
		  coords=coords_string.split(",")
		  tl_x=Math.round(parseInt(coords[0]))
		  tl_y=Math.round(parseInt(coords[1]))
		  width=Math.round(parseInt(coords[2]))
		  height=Math.round(parseInt(coords[3]))
          if (Math.round(parseInt(tl_x))==0){
		  console.log("Hitting border")
		  }
      });    

It still doesn't work as expected, I don't get console output when I drag selection corner across image border. Also there is a discrepancy in annotorious-openseadragon behaviour I can't understand at this point. It turns out that it is already impossible to move selection box outside of image borders if I try to reposition it as a whole with crosshairs cursor (and in that case my test condition actually does get triggered when selection box hits the border), but it is possible to move the box outside the image by changing it's shape, i.e. dragging at the corners. Is it intentional? If so what is the logic behind such discrepancy?

[rsimon]

That's right. Moving the box is constrained to the image area. The feature didn't get fully implemented though. Therefore you can still drag box corners off the image I believe.

[rsimon]

PS: what are you seeing when you just log the coordinates? (Not just log if 0.)

[ferropasha]

Here is what I get logging top-left x-coordinate as I drag the corner to image border. As you can see the value is never equal to zero, 3 being the closest. I guess that's understandable if the annotation's selector.value simply can't update fast enough, though I wonder then how the restriction on whole box movement had been implemented?

[rsimon]

Ah - of course. Yes, that's how mouse events work after all. You'd never get exact (or continuous) values. I should have thought of that...

Here's the code that handles the box constraint:

https://github.com/annotorious/annotorious/blob/2.x/src/tools/rectangle/EditableRect.js#L182-L183