Loading Profile...
Java Deep Zoom Tools
My preferred server technology is Java and I wish to use it to automate the process of creating the image pyramids, possibly in Deep Zoom format, but any other format compatible with OpenZoom would be fine.
Do you know of any libraries to support creation of Deep Zoom (or similar) pyramids from high-res JPEGs using Java?
How hard is it to do from scratch? I suspect it's more than just rendering to a canvas, then chopping out the tiles. I imagine that the biggest problem would be making the JPEG tiles seamless with each other since they would be each subject to separate compression artefacts. Then again, maybe it's easier than I think.
Do you know of any libraries to support creation of Deep Zoom (or similar) pyramids from high-res JPEGs using Java?
How hard is it to do from scratch? I suspect it's more than just rendering to a canvas, then chopping out the tiles. I imagine that the biggest problem would be making the JPEG tiles seamless with each other since they would be each subject to separate compression artefacts. Then again, maybe it's easier than I think.
I’m unsure
3
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company implemented this idea.
The best points from the company
-
darwinjob,
Slow down... let's take a step back here: You're obviously confusing file formats and presentation technologies which allow you to view them.
Pick any image pyramid file format and you'll discover that there's nothing proprietary about them, it's usually just a tiny XML file and a huge pile of image tiles in JPG or PNG. As you may know XML is a standard sanctioned by the W3C and so are JPG and PNG within other standards bodies.
Therefore the Deep Zoom Image file format is cerainly not a M$ proprietary format. Having said that, the huge advantage of the Deep Zoom Image file format is its simplicity and reach:
1.) It's very well documented, as in here, here and here
2.) It's used by:
- Photosynth
- Pivot
- Seadragon Mobile (iPhone)
- Silverlight Deep Zoom
- Seadragon Ajax (open source)
- OpenZoom (open source)
The fact that there currently are two open source implementations of presentation technologies for the Deep Zoom Image file format speaks for itself.
Other benefits of the file format are that many implementations for creating it exist, e.g. for Python, .NET, Ruby, now Java and PHP coming soon:
http://openzoom.org
Additionally, there is Deep Zoom Composer which gives laymen the chance to publish to the file format.
Please don't misunderstand me, the OpenZoom Description Format was created as a way to encapsulate older file formats and describe legacy image pyramids. It's just a description format and therefore does not really compete with the Deep Zoom Image file format. I believe it's time for me to add this disclaimer to the original blog post.
I hope this addresses your concerns and I'd be happy to clarify any further uncertainties.
Cheers,
Daniel
I’m confident
The company thinks
this is one of the best points
-
Glenn,
Congratulations! I just had a quick look and it looks fantastic. You might have guessed by now but the reason why it's such a good time for having Deep Zoom Tools for all different languages/platforms is our release of Pivot. Check out the developer section or watch the video
You will find out what an important part the Deep Zoom file format plays.
Once again, thanks for contributing.
Yours,
Daniel
P.S. Tweet shoutout: http://twitter.com/OpenZoom/status/59...
I’m thankful
The company thinks
this is one of the best points
-
Glenn,
The definitive answer to rounding:
http://problog.jamespritz.com/2009/03...
Open Source
I'd recommend you first clean up your code, add a license, a small README, possibly an example, and then blog about it and make the source available.
For hosting the library, there's many options, e.g. GitHub (recommended), Google Code or just your blog.
Please ask here if you have further questions. I'd love to help you get this out there! :)
Cheers,
Daniel
I’m excited
The company thinks
this is one of the best points
-
Glenn,
I've used that algorithm for a while and it seems to work fine. I believe I first saw it used by Kapil's slicer tool. Feel free to test it against Microsoft Deep Zoom Composer output – that's what I did. If you'd like I could maybe verify this with one of my Seadragon peers.
In terms of memory, I'm not sure how far you can go but it seems to work fine for serious DSLR output, e.g. 10–15MP. If you want to go further than that, there's the netpbm library which should make this whole process less dependent on memory.
If you need further inspiration, Sascha Hanssen developed an implementation in Ruby:
http://www.meso.net/deep_zoom_slicer
How's your work on the Java implementation doing?
If you'd like to give your Java port more exposure, I could set you up with a project on GitHub under the OpenZoom project – just let me know.
Cheers,
Daniel
The company thinks
this is one of the best points
-
Inappropriate?Wedgie,
Unfortunately, I don't know of any Java library for converting images into the Deep Zoom file format.
> How hard is it do from scratch?
Not taking into account optimizations and wanting to convert gigapixel imagery, I'd say not very hard. I've done it with the open source implementation for Python, deepzoom.py
http://github.com/openzoom/deepzoom.py
The time-consuming part was to study the file format and come up with the algorithms for calculating the image pyramid properties:
http://gasi.ch/blog/inside-deep-zoom-2/
Now that this is done and open source, porting it to Java shouldn't take more than a couple of days, considering Java has a robust imaging library. I highly encourage you do take on this task and I'd love to see you release it as open source as well. Someone is already working on a port to PHP and it will probably be hosted as part of the OpenZoom project once it's done.
I'd suggest you get started by having a look at the code of deepzoom.py and begin with the single image conversion, e.g. ImageCreator:
http://github.com/openzoom/deepzoom.p...
Let me know if you run into trouble, I'd love to help!
Cheers,
Daniel
I’m excited
-
Inappropriate?Thanks Daniel, I've just about got something done and yes, I'll be glad to share it as open-source.
I can't find any definitive reference on the scaling algorithm. It looks like your Python code calculates the size for each level based on the base 2 logarithmic scale applied to the original width and height. Did you find a Microsoft reference that told you that?
I'm not sure but looking at what is produced by the MS Deep Zoom Composer it looks like it might be calculated by working from largest to smallest and getting the next by simply dividing the previous image size by two. If you allow the size to be rounded up to the nearest integer each time you could sometimes get a different result compared to your method. Maybe it doesn't matter, but it would be good to use the same algorithm as MS if possible.
You mention problems with handling gigabit images, presumably because the method you use (as does mine) loads the images into memory to process them. What sort of upper limit do you think we could expect with our simple method?
Cheers,
Glenn (AKA Wedgie)
I’m confident
-
Inappropriate?Glenn,
I've used that algorithm for a while and it seems to work fine. I believe I first saw it used by Kapil's slicer tool. Feel free to test it against Microsoft Deep Zoom Composer output – that's what I did. If you'd like I could maybe verify this with one of my Seadragon peers.
In terms of memory, I'm not sure how far you can go but it seems to work fine for serious DSLR output, e.g. 10–15MP. If you want to go further than that, there's the netpbm library which should make this whole process less dependent on memory.
If you need further inspiration, Sascha Hanssen developed an implementation in Ruby:
http://www.meso.net/deep_zoom_slicer
How's your work on the Java implementation doing?
If you'd like to give your Java port more exposure, I could set you up with a project on GitHub under the OpenZoom project – just let me know.
Cheers,
Daniel
The company thinks
this is one of the best points
-
Inappropriate?Thanks Daniel,
it would be good to get a definitive answer about whether to round or not to round after each division. Maybe it doesn't make a difference.
How do you recommend I go about making my Java tool available as Open Source?
Cheers,
Glenn -
Inappropriate?Glenn,
The definitive answer to rounding:
http://problog.jamespritz.com/2009/03...
Open Source
I'd recommend you first clean up your code, add a license, a small README, possibly an example, and then blog about it and make the source available.
For hosting the library, there's many options, e.g. GitHub (recommended), Google Code or just your blog.
Please ask here if you have further questions. I'd love to help you get this out there! :)
Cheers,
Daniel
I’m excited
The company thinks
this is one of the best points
-
-
Inappropriate?I've been somewhat distracted by paid work, but knowing there is somebody that actually wants to use the code motivates me to do something about publishing it. In the meantime if you can figure out a way to send me your email address without it getting spam harvested I'd be happy to send you a copy.
-
Inappropriate?Glenn,
How's your Java library coming along? If you have something working, even with some bugs, choose a license and stick it onto GitHub (or similar) and let me know. If you haven't gotten to collection support yet I might work on it on a weekend.
Cheers,
Daniel
I’m excited
-
Inappropriate?Thanks for the encouragement Daniel!
I reckon I'll just use the same licenses you use for OpenZoom.
I was thinking of first just releasing a standalone Java app to do the conversion - a bit like your Python tools. The code would be easy to adapt into a library. And you're right, I haven't done the collection support yet, but I'll release it without for now.
I think I'll use GoogleCode with svn since I haven't (yet) got my head around Git. Your message has prompted me to create a project there called deepjzoom. I just need to figure out how to upload the code now.
Cheers,
Glenn (aka Wedgie)
-
Inappropriate?Ok - I've tidied up the code to work as standalone application, added command line parsing for various options etc. and checked the code into GoogleCode.
You can access the code here: http://code.google.com/p/deepjzoom/up...
Let me know if you think I need to do something else to make the code more available,
Thanks once again for the encouragement!5 Comments Add a comment
This is one of the best points
-
Hi
I have modified your code a little to make use of JAI and can confirm that the converter works even with 51200x108544 TIFF compression scheme 7 file.
http://folk.uio.no/dmitrd/bin-debug/o...
Let me know if you need the code.
PS. The problem was that ImageIO.read(file) loads whole image into memory which is not acceptable in a case like 51200x108544. -
Nice! I'd suggest to open a project on GitHub which is a better place to collaborate on open source software. I'd encourage you to signup, post your code, send me your username, and I'll move it under the OpenZoom project umbrella at: http://github.com/openzoom
-
Well done! I'd be happy to put your code into DeepJZoom as well if you like.
-
@Wedgie: I sent you the code by email I found in your code.
@Daniel: This "better place to collaborate" makes me mad with all these keys... I mean I have tried but failed to publish the code. -
Thanks - I just got your email. It looks good and I will incorporate it but am wondering whether we need any special build and deployment instructions for folks to use this with JAI
-
Inappropriate?Glenn,
Congratulations! I just had a quick look and it looks fantastic. You might have guessed by now but the reason why it's such a good time for having Deep Zoom Tools for all different languages/platforms is our release of Pivot. Check out the developer section or watch the video
You will find out what an important part the Deep Zoom file format plays.
Once again, thanks for contributing.
Yours,
Daniel
P.S. Tweet shoutout: http://twitter.com/OpenZoom/status/59...
I’m thankful
The company thinks
this is one of the best points
-
Inappropriate?Congratulations!
But as far as I understand this is DeepZoom, not OpenZoom. What do you think, how much work would it be to make OpenZoom implementation? I would prefer not to mess with M$ proprietary formats...
PS. Is there any other format description document except this one : http://gasi.ch/blog/openzoom-descript... ?
PPS. Why is this youtube guy posted twice? :)
-
Inappropriate?darwinjob,
Slow down... let's take a step back here: You're obviously confusing file formats and presentation technologies which allow you to view them.
Pick any image pyramid file format and you'll discover that there's nothing proprietary about them, it's usually just a tiny XML file and a huge pile of image tiles in JPG or PNG. As you may know XML is a standard sanctioned by the W3C and so are JPG and PNG within other standards bodies.
Therefore the Deep Zoom Image file format is cerainly not a M$ proprietary format. Having said that, the huge advantage of the Deep Zoom Image file format is its simplicity and reach:
1.) It's very well documented, as in here, here and here
2.) It's used by:
- Photosynth
- Pivot
- Seadragon Mobile (iPhone)
- Silverlight Deep Zoom
- Seadragon Ajax (open source)
- OpenZoom (open source)
The fact that there currently are two open source implementations of presentation technologies for the Deep Zoom Image file format speaks for itself.
Other benefits of the file format are that many implementations for creating it exist, e.g. for Python, .NET, Ruby, now Java and PHP coming soon:
http://openzoom.org
Additionally, there is Deep Zoom Composer which gives laymen the chance to publish to the file format.
Please don't misunderstand me, the OpenZoom Description Format was created as a way to encapsulate older file formats and describe legacy image pyramids. It's just a description format and therefore does not really compete with the Deep Zoom Image file format. I believe it's time for me to add this disclaimer to the original blog post.
I hope this addresses your concerns and I'd be happy to clarify any further uncertainties.
Cheers,
Daniel
I’m confident
The company thinks
this is one of the best points
EMPLOYEE
