Loading Profile...
How Do I Use OpenZoom with djatoka?
Daniel, I'm trying to get your Djatoka descriptor to work, but I'm running into issues. I'm using the latest flex code from the svn repo.
What I'm seeing is incorrect tiling at low zoom levels, or when zoom=1. When I zoom all the way the maximum for an image, tiling is correct.
Do you have any examples of usage, so I can make sure I'm not just doing something stupid?
Here's the Openzoom example:
http://mars.asu.edu/~cyates/djatokade...
And here's the same image with the Djatoka viewer:
http://african.lanl.gov/adore-djatoka...
Both of these are using the same Dkatoka service and image.
Here's my code:
I've tested the rest of the code with the Gigapan and other descriptors, and it works fine, so I'm fairly sure I'm having an issue with the Djatoka descriptor.
Same code example with a slightly refactored Gigapan descriptor:
http://mars.asu.edu/~cyates/zoomer/Zo...
Thanks Daniel!
-christian
What I'm seeing is incorrect tiling at low zoom levels, or when zoom=1. When I zoom all the way the maximum for an image, tiling is correct.
Do you have any examples of usage, so I can make sure I'm not just doing something stupid?
Here's the Openzoom example:
http://mars.asu.edu/~cyates/djatokade...
And here's the same image with the Djatoka viewer:
http://african.lanl.gov/adore-djatoka...
Both of these are using the same Dkatoka service and image.
Here's my code:
var descriptor:DjatokaDescriptor = new DjatokaDescriptor("http://african.lanl.gov/adore-djatoka/resolver", "http://mars.asu.edu/~cyates/P01_001337_1945_XN_14N065W.jp2", 5056, 11264);
I've tested the rest of the code with the Gigapan and other descriptors, and it works fine, so I'm fairly sure I'm having an issue with the Djatoka descriptor.
Same code example with a slightly refactored Gigapan descriptor:
http://mars.asu.edu/~cyates/zoomer/Zo...
Thanks Daniel!
-christian
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The company marked this question as answered.
The best answers from the company
-
Christian,
Have you made any progress on this issue?
Well, the good news is that I had this itch and finally fixed the DjatokaDescriptor to work with your special image. The bad news, this improvement is only in the neorenderer branch. However, with a bit of copy & paste you can bring this into the old DjatokaDescriptor.
Let me know whether it works for you:
http://code.google.com/p/open-zoom/so...
It basically looks at the dwtLevels property which can either directly be passed into the constructor or be read straight from a djatoka getMetadata response JSON string through the DjatokaDescriptor.fromJSONMetadata(...) method.
Cheers,
Daniel
P.S. Ryan, thanks for all the information regarding the level strangeness :)
The company says
this answers the question
-
Ryan & Christian,
Thank you both for the information. I will have a look at it and see that I can design a correct djatoka descriptor for the OpenZoom SDK.
–Daniel
P.S. Ryan, do you have an explanation for the metadata of the image provided by Christian? It has original dimensions of 5056x11264px but a level count (both dwtLevels and levels) of 5.
Viewer
http://african.lanl.gov/adore-djatoka...
Metadata
http://african.lanl.gov/adore-djatoka...
I'd really like to design the descriptor in a way that it does not depend on the metadata retrieved by the djatoka server. Is that generally even possible for all images?
I’m happy about the collaboration
The company says
this answers the question
-
Inappropriate?Christian,
Don't worry, you're not doing anything stupid. :)
In fact the Djatoka descriptor is very much experimental and I've created it a while ago when I played around with the first version of the djatoka image server that I've installed locally. In the meantime they've released an update and it's apparent the descriptor is not working quite as expected.
Actually, there is an example for the Djatoka descriptor in the OpenZoom repository but it's not particularly good nor working correctly. Forgive me for that.
http://code.google.com/p/open-zoom/so...
I've just started with a new example to test what's going wrong. Obviously, something is wrong in the way the descriptor calculates the image levels and tile boundaries.
Strangely, the image you're working with has weird metadata, e.g.:
http://african.lanl.gov/adore-djatoka...
The metadata says it has 5 levels from the initial dimensions of 5056x11264px. However, this contradicts the documentation which explains how the number of levels is computed:
http://apps.sourceforge.net/mediawiki...
Taking one of the example images from the djatoka project gives us correct results:
http://african.lanl.gov/adore-djatoka...
I am still looking into the problem and let you know if and when I solve it.
–Daniel
P.S. Feel free to join the quest for a fix. Your input is very much appreciated.
1 Comment Add a comment
This answers the question
-
I had a typo in the documentation, the djatoka level logic is based on the number of times an image can be halved from max(w,h) to 96 pixels or less. Sorry. Additionally, the semantics of levels changed from 1.0 to 1.1, this is mostly due to an incorrect representation in the docs. See djatoka wiki for details. -
Inappropriate?Problem seems to be related to the DEFAULT_BASE_LEVEL. Even though that is set correctly for the LANL example images, it doesn't work correctly.
I was unaware of the metadata service from Djatoka, and now that I am, I'm going to see if I can just refactor the DjatokaDescriptor class to query it instead, so I can get the dimensions and zoom levels directly from the service. That way it'll still work even if the image has some strange level encoding like the demo Mars image I'm using.
I'll post a patch if I get this fixed up.
-c
I’m happy
-
Inappropriate?Ryan & Christian,
Thank you both for the information. I will have a look at it and see that I can design a correct djatoka descriptor for the OpenZoom SDK.
–Daniel
P.S. Ryan, do you have an explanation for the metadata of the image provided by Christian? It has original dimensions of 5056x11264px but a level count (both dwtLevels and levels) of 5.
Viewer
http://african.lanl.gov/adore-djatoka...
Metadata
http://african.lanl.gov/adore-djatoka...
I'd really like to design the descriptor in a way that it does not depend on the metadata retrieved by the djatoka server. Is that generally even possible for all images?
I’m happy about the collaboration
The company says
this answers the question
-
Inappropriate?Yes, the number of djatoka levels can not be greater than the number of dwtLevels. I'll add this to the docs. Thanks.
1 person says
this answers the question
-
Inappropriate?Ryan,
Great. Thanks for the update to the documentation. Still, is it possible to determine the dwtLevels parameter without using the metadata service of the djatoka server? If yes, how?
–Daniel
I’m thankful
1 Comment Add a comment
This answers the question
-
Not really. That would assume all images were compressed with the same level logic as djatoka. This was the cause of the necessary semantic shift of level and addition of dwtLevels. Does this clarify the issue?
-
Inappropriate?Well, it appears I'm too much of an AS3 noob to figure out how to do this.
Retrieving and parsing the metadata is easy enough, but I can't figure out how to set up the chain of events such that the metadata is retrieved before the DjatokaDescriptor constructor is executed.
I’m frustrated
-
Inappropriate?Christian,
I purposely did not include any loading logic into the descriptors themselves. As I did with the DZIDescriptor or ZoomifyDescriptor I suggest you to create a special static constructor method that can create a DjatokaDescriptor from the metadata you receive from the server. Frankly, I am heads down into the new rendering engine – which by the way will be awesome – and therefore haven't looked closer at the djatoka stuff yet, sorry.
One thing I still haven't grasped is how to consistently map the metadata to levels and their dimensions. Fair enough, images processed by the djatoka server itself seem to adhere to a certain specification but in the case of the image you've posted as example, I don't get how these levels can be systematically constructed.
Did you have any luck with that? If yes, maybe we put our heads together on this.
–Daniel
I’m sorry
-
Inappropriate?No problem! I've attempted to add a static constructor method, but I keep banging my head on the asynchronous return of data from the djatoka metadata service.
Do you have any examples where data is retrieved remotely i.e. xml describing a deepzoom pyramid? Your examples included in the SDK all have the image description XML hard-coded into the MXML.
As for the level mapping - I'm assuming that if we use the dwtLevels data from metadata service, that should give the correct # of levels for that particular image, regardless of how it was processed. This assumption has not been tested adequately, as my current sample size is two.
I have a number of JP2 images that have been processed with different tools (kdu_convert, GDAL, JasPer, etc.) so as soon as I figure out the remoting issue, I'll tackle some testing to verify my assumption.
-christian -
Inappropriate?Christian,
Yeah, I often times hard code the descriptors to simplify testing. However, to get it to work asynchronously just go old school using URLLoader to load the metadata and in the complete handler create the descriptor.
–Daniel
P.S. Look inside MultiScaleImage, Lines 134ff:
http://code.google.com/p/open-zoom/so...
-
Inappropriate?Christian,
Have you made any progress on this issue?
Well, the good news is that I had this itch and finally fixed the DjatokaDescriptor to work with your special image. The bad news, this improvement is only in the neorenderer branch. However, with a bit of copy & paste you can bring this into the old DjatokaDescriptor.
Let me know whether it works for you:
http://code.google.com/p/open-zoom/so...
It basically looks at the dwtLevels property which can either directly be passed into the constructor or be read straight from a djatoka getMetadata response JSON string through the DjatokaDescriptor.fromJSONMetadata(...) method.
Cheers,
Daniel
P.S. Ryan, thanks for all the information regarding the level strangeness :)
The company says
this answers the question
-
Inappropriate?Daniel,
To tell you the truth, I ended up abandoning Djatoka, as its performance wasn't up to the level we needed and it was difficult to deploy in our environment. I did however use the experience to build a similar JPEG2000 subsetting service in Python, and to create a custom OpenZoom descriptor for it.
I've been handling the metadata issue on the server side for now, but I'll take a look at your improved Djatoka descriptor code and see if that would be a better way to handle my custom descriptor as well.
Once our service is up (in a couple of days, most likely), I'll send you a link.
-christian
I’m happy
3 Comments Add a comment
This answers the question
-
Christian,
Sorry to hear that djatoka wasn't a good fit. Do you have any details on this performance issue you describe? Was the major issue python vs Java/Tomcat? What other factors contributed to your decision? Do you still use the Kakadu binaries? Are you using getRegion service parameter syntax defined by djatoka? Any information you can provide that will help the larger djatoka community would be appreciated.
Thanks,
Ryan -
Ryan,
It wasn't so much that djatoka's performance was bad, it was that it wasn't any better than what we were already working on in most cases. In some cases, it lagged behind. Specifically, when subsetting and scaling large portions of large images (say 4000x32000 of a 5000x54000 pixel image) took 2-3x longer than our existing solution. Smaller subsections fared better, and were sometimes faster to return.
A colleague had already set up a subsetting server using Java for use by our JMARS application, calling the gdal_translate binary from FWTools, which implements the Kakadu libraries in C. It was pretty simple for me to create something similar but more generic in Python. It's not nearly as full-featured as Djatoka.
The other issue was the portability - I did manage to finally get djatoka running under Glassfish, our production app server, but it required extra domain-wide JVM variables to do so.
We were using the getRegion syntax but for some of our needs we needed to use the scale parameter as well - I noticed though that if given percentage rather than pixel values it wouldn't cache output images.
We were really hoping for a JNI solution, but it appears that the Kakadu JNI just isn't up to snuff, as you're the second group that's tried it and reverted back to system calls to external binaries. -
Christian,
Thanks for the follow up. True, for scaling large sections of images you probably pay a price having to go through Java. As with somethings in Java you sometimes pay a performance penalty for portability. I'll look into preventing the need for global variables in the app servers. I'm not quite following the getRegion comments and caching. Also, I was hoping that new similar image extraction services would use service parameter semantics similar to djatoka getRegion, so there will be portability. There's allows the chance we could make a python, etc port of djatoka. And on the topic of Kakadu JNI, it's a synchronization problem, you pay in performance to fix it and JNI is violent when an error occurs, kills the vm.
Ryan -
Inappropriate?Christian,
Great news! Although, too bad that djatoka wasn't the right fit.
Looking forward to seeing what you came up with!
–Daniel
I’m excited
-
Inappropriate?Has anybody ever successfully implemented a working OpenZoom viewer for Djatoka? I am very interested in testing it but since I have no Flash/Flex background it would take me some time to build my own based on the Djatoka descriptor.
I’m hopefull
-
Inappropriate?For access to JPEG2000 images without going through java, the IIPImage project (http://iipimage.sf.net) who provide one of the front-ends for djatoka, now also handle JPEG2000 directly in their server http://iipimage.sourceforge.net/2010/...
Like djatoka, this uses Kakadu, but is entirely written in C++, so no java overhead. As a bonus, the server is compatible with iipmooviewer, deepzoom, zoomify and several other ZUI front-ends, including of course openzoom ;-)
I’m excited
1 person says
this answers the question
1 Comment Add a comment
This answers the question
-
Awesome! Thanks for your contribution, Ruven :)
EMPLOYEE
