An open-source, web-based viewer for zoomable images, implemented in pure JavaScript.
@iangilman I can't make it work unfortunately. Looking at the examples here: https://openseadragon.github.io/examples/ui-overlays/ I tried first to do something like this: http://differenthood.duckdns.org/rhythm/configuratorosd-ex1.html with overlays specified for each tilesource (which is what I'm trying to achieve). But it doesn't load dzis at all.
Then I tried to have common overlays for the tilesouces just to see if it works: http://differenthood.duckdns.org/rhythm/configuratorosd-ex2.html With this simpler notation dzis get loaded and also overlay on the first page load. However, overlays disappear once you change image in the sequence and never reappear without reloading page.
Then I tried to have common overlays for the tilesouces just to see if it works: http://differenthood.duckdns.org/rhythm/configuratorosd-ex2.html With this simpler notation dzis get loaded and also overlay on the first page load. However, overlays disappear once you change image in the sequence and never reappear without reloading page.
@iangilman it seems that if you want to specify tileSources as objects (which you need to do in order to have different overlays per tileSource) you are not able to pass a dzi as tilesource. But maybe I'm missing something..
@sickrandir Good point! We should probably come up with a better mechanism for that. For one thing, I've been thinking the overlay should be outside of the tileSource not a property of it. In fact there's even a to do for that: https://github.com/openseadragon/openseadragon/blob/master/src/viewer.js#L612
@sickrandir If you're up for it, you could make a patch to that effect
Meanwhile, given how it currently is, you could make it work like so:
var tileSources = [];
var tileSource = new OpenSeadragon.TileSource({ url: ... });
tileSource.overlay = ...;
tileSources.push(tileSource);
... or by watching page events and manipulating the overlays.
thanx a lot for the fast solution! will look into the TODO to make a patch in the next days
Awesome :)
I'm thinking we need to still support the overlay property being on tile source for backwards compatibility, but we can add support for it at the image spec level as well and document that as the primary path
ok. one question however: how do you think we can link overlays to a particular tileSource in sequence mode in this scenario?
The image spec scenario? It would still be per image...
Like so:
OpenSeadragon({
...,
tileSources: [
{
tileSource: ...,
overlay: ...
},
{
tileSource: ...,
overlay: ...
}
]
});
Is that what you're asking?
ok, now it's clear
Cool. That tileSources property is overloaded with so many possibilities it can be confusing!
@iangilman: if you can tell me if you are ok with my suggestion on #888, I will start working on it right now.
@avandecreme :thumbsup:
@iangilman @avandecreme I'm not sure if my response to the github email went out, but have a siggestion WRT placement:
Serializing overlay placement is something that I am planning on doing and seems like it would be a common requirement. I don’t know about current uses. Couldn’t you just assign the indicated values to the placement objects, as in:
18, 36, 24, 12, 10, 9, 11, 21, 22 for CENTER through LEFT and then add functions to the placement object, as in isLeft(placement), isHorizontallyCentered(placement), isRight(... These functions could use a simple bitwise and to return the desired binary result.
That way you can easily serialze the overlay placement value and also get your binary values. You could also put a quick check for the old values before the “bitwise and” so that those functions could also handle the old values 0-8.
@dwrogers thanks for your input
I replied on github
@avandecreme Funny. I still don't see my message in my github email feed - I guess messages do not get echoed to the author on github?
maybe, I avoid using the email directly because the formatting get pretty bad.
@dwrogers So any pointer on how you would choose the values and the bitwise operations?
@avandecreme I took your advice and switched to using github directly.
:+1:
@avandecreme It's not quite right... sorry. let me review it.
@dwrogers yeah I think it would need to get rid of isHorizontallyCentered/isVerticallyCentered because that the same as ~isLeft & ~isRight
and ~isTop & ~isBottom
(at least in the masks, the methods can be added of course)
@avandecreme You could do that. It would change all of the values for and'ing.
might even be more complicated because you can't be top and bottom at the same time
I don't really mind what the values are as long as they are not 0.
@avandecreme what about quantum pixels? ;-)
@iangilman any thought on this? Do you prefer using masks or boolean like before?
@dwrogers maybe for OSD 3 :)
Looking...
I prefer keeping the backwards compatibility with the old placement values.
I don't know that the bitwise operations buy us anything beyond slightly smaller code
(over having each property explicitly defined for each enum)
@iangilman So you are suggesting leaving the OverlayPlacement as is with 0-8, and adding the functions to provide the booleans?
... but I don't feel strongly about it
Yeah, like so: http://stijndewitt.com/2014/01/26/enums-in-javascript/
@avandecreme has already built that table after all
On the other hand, the table could be a bunch of packed bitwise values if we prefer
I guess part of my hesitation with the bitwise values is that they're harder to maintain... less obvious to look at them and know if they are correct
I have to agree on that point :D
what about CENTER being 0?
I suppose they could be built up like so to make it more clear:
LEFT = placementMask.isLeft + placementMask.isVerticalCenter
That seems clearer...
ok, I will try that then
I agree that when CENTER was first created it would have been better to go with 1, but at this point I don't know that it's a big deal. The code has to change from
placement | | LEFT to placement === undefined ? LEFT : placement.
alright, keeping everything then :D
I figure if @dwrogers is serializing these values, we should assume other people have already done so, so we at least need some sort of way to deal with the old values
So if we switched to new values, we at least need to be able to accept the old ones
Cool... funny how much goes into these little details!
Wandering off to lunch now...
Seems good to me! What do you think @dwrogers ?
My very "green" opinion is that it looks good to me. Evvverybody's happy! :-)
Excellent. Assuming @avandecreme is ready, I'll land it in a bit
Not ready, I am adding the constructor with fitBounds
Cool, forgot about that. No rush here :)
@avandecreme @iangilman I keep trying to find a way to replace the property names of the properties object to be text. Something like "this.CENTER: " rather than "0:", but I don't think that this is a valid use of "this".
Yeah, maybe next time we build something like this
should be ready now
I did not handle using fitBounds if the image is clipped though
i.e. It doesn't compensate for the clip? Seems like a fine thing to save for later
I'll check it out in a bit
@iangilman correct. I can take a look at it
probably tomorrow
Cool