new module - Zoomify
|
etiennesky
Joined: 2005-09-28
Posts: 39 |
Posted: Fri, 2006-10-13 17:18
|
|
I would like to develop a new module, which would add support for Zoomify into Gallery2. Basically Zoomify allows viewing hi-res images without downloading the full file, with a free flash viewer available at http://www.zoomify.com and a free python generator (ZoomifyImage) at http://sourceforge.net/projects/zoomifyimage. There is a demo at http://www.zoomify.com/ez/ and one I made at http://www.tourigny.ca/test/zoom/Template2.htm. The issue has been briefly discused at http://gallery.menalto.com/node/49260 with no follow-up. Here are my ideas expressed there: ---- - use ZoomifyImage, a python script to generate the tiles from the base image Options could be: ZoomifyImage available at http://sourceforge.net/projects/zoomifyimage I tested the ZoomifyImage script on a linux server with PIL as graphics backend, and it works great (but takes about 8 seconds for a 6 MP, 2.5 MB image). I would need some input from devs as to where to put the tiles, and perhaps which module I could start from to make this module. Does anyone want to participate? So is there anyone interested into working with me on this project or helping out so I can get started on the right track? Etienne |
|
Posts: 32509
@Where to store the tile files:
The "thumbnail" module is another module that stores files. The thumbnail sets a specific jpg file which the user specifies (uploads) as the thumbnail for a Gallery album or item. Useful if you don't have a graphics toolkit that automatically generates thumbnails on the server. etc.
It stores the custom thumbnails in g2data/plugin_data/modules/thumbnail/, see modules/thumbnail/classes/ThumbnailImage.class as an example. I'd svn update, since it has changed recently.
@Python:
It'd be great if it works in pure-php as well.
@non-free software:
Is there a GPL version of zoomify? I remember to have seen an alternative to zoomify which did a good job as well. basically the same concept of incremental downloads, surely other code. But i couldn't find the topic with the search function.
Posts: 39
@Where to store the tile files:
So the logic would be to store the tiles in g2data/plugin_data/modules/zoomify/<g2id> ?
How about putting them in g2data/cache/derivative , along with the normal thumnails and resizes (I presume)?
@Python:
the ZoomifyImage contains a contrib app that uses bash and netpbm. Perhaps this could be ported to php? In a first step I would prefer to use what is already existing, and allow for different backends.
In fact ZoomifyImage can be used with PIL, Imagemagick or netpbm, this could be customizable.
@non-free software:
Are you are refereing to the Zoomify Viewer SWF? In deed it does have a restrictive licence (nonexclusive, royalty-free, right to use the SOFTWARE) but it doesn't need to be GPL to use it since we don't have access to the code. The generator(ZoomifyImage) is indeed GPL so it's OK to use it.
I found a similar project, using Javascript for viewing and Python for generating. It's called GSV and available at http://mike.teczno.com/giant/pan/. However, it's not currently compatible with Zoomify. And it isn't as good-looking as Zoomify Viewer SWF, but it doesn't require flash for viewing.
The project you are refering to, was it related to Gallery2 or something else?
Posts: 39
can someone point me to how I could replace the default display on the image itself, so that I display the ZoomifyViewer when a Zoomified version exists?
Right now how I see it, is that I modify the theme file photo.tpl so that if a zoomified version exists, show that instead of {g->image}. I also need to modify PhotoSizes.tpl (I put a copy in my /modules/zoomify/templates/block/) folder to be able to select either the normal resized and the zoomified.
But this approach isn't great because you have to change all the themes to support this module. How can I override the behaviour of {g->image} and PhotoSizes.tpl from within the module itself?
Posts: 32509
1. develop against G2.2 (snapshots or svn).
2. you'll need to implement a GalleryZoomifyPhotoItem class. see GalleryMovieItem, GalleryPhotoItem, ...
those classes define which renderer is responsible to render them -> you can output your flash stuff with a renderer
3. photo.tpl / the theme must not be modified
Posts: 39
Great! thanks for your input.
1) The classes you refer to are in the 'core' module. My new class GalleryZoomifyPhotoItem can still be in my module "zoomify"?
2) How can I force the display of the zoomified version instead of the preferred version without modifying photo.tpl / themes?
In fact I would like the Zoomify be just another version of the main image (sort of like the derivative resized images), and have that displayed by default, not another item all together. Also this zoomified version should appear in the list of available sizes done in "PhotoSizes.tpl" with a "Zoomify" label.
In light of this I think that the GalleryZoomifyPhotoItem should be a sub-class of GalleryDerivative, just like GalleryDerivativeImage for the thumnails and resizes. This should work because there is a render() method in GalleryDerivative.
Your thoughts?
Posts: 8601
better examples are panorama module or flashvideo module.
these use a "renderer" class which is attached to an existing entity type.
Posts: 39
Great thanks valiant and mindless!
I've implemented a simple version! I've created a class GalleryZoomifyItem which extends GalleryDerivativeImage (so it's one of the derivatives of the base image). I use the bash script which uses netpbm utilities to make the tiles. The rendering is done in GalleryDerivativeImage::render().
Now I would like to make this derivative the one that is shown by default (make it the first of the derivatives). I dind not find a way to do this, because it seems that GalleryDerivativeHelper_simple::__loadDerivatives does a simple sql query to get the derivatives and does not allow for sorting. Anyone have a clue?
Working example at http://www.openphotoblog.com/test/photo/main.php?g2_itemId=108
All of the images have been zoomified and selecting the 600X450 version shows the zoomified version with the SWF viewer.
And does the code need to be fully mature before addinng it to svn?
Posts: 8601
cool!
we gladly give access to any developers who would like to add code into gallery-contrib.. let us know if you'd like to put zoomify in gallery-contrib and we'll get you setup. this is a good first step to getting a module into main svn, where code must be reviewed and have unit tests.
Posts: 32509
that's pretty neat
i guess you simply don't want multiple resizes per image when using zoomify.
all you want is that when you click on the photo, it should show you the zoomified flash version. right?
i'd do it like that: delete all resizes for the item, create your GalleryZoomifyItem derivative as a preferred derivative.
the problem: the good thing about preferred derivatives in g2 is that they are shown instead of the original.
the bad thing is that they're used as source for derivatives, e.g. thumbnails and resizes.
so if the thumbnail gets deleted in some event, it will try to rebuild a new thumbnail based on your GalleryZoomifyItem...
my concern is also that you call it an Item when it actually extends a Derivative.
I agree that we can see it either as derivative or item, but i'd at least rename your class to GalleryZoomifyDerivative.
I'm still not sure if an item approach would be better.
Posts: 39
Thanks!
mindless:
please sign me up and send me a PM with the info to add the module to gallery-contrib svn. What's the best way to discuss concept or implementation issues? Threads like this?
valiant:
I agree with the first part of your idea. Show the zoomify instead of mid-size resized image, which are deleted. But I don't see why it should be a preferred... If it's the only resize (apart from the thumbnail) then it should be shown by default right? And I would like the fullsize to be available also for download. So I think the best is to delete the resizes when creating the zoomify and keep the original. This could be configurable though.
This link illustrates my point w/o resizes:
http://www.openphotoblog.com/test/photo/main.php?g2_itemId=166
I'll rename the class to GalleryZoomifyDerivative, do some code cleanup and commit it to gallery-contrib.
Regarding Derivative vs. Item, conceptually I see it as a derivative since it's generated from the fullsize. ANd it cuold be regenerated at a later date again from the original. I don't see a use to having two versions (two items) of a given image, one with the original and resizes and the other just a ZoomifyItem. Perhaps someone would like to generate a ZoomifyImage on their own (from a very big original) and then upload the tiles for display in Gallery. This would need another approach, something to think about later.
Posts: 32509
the meaning of "preferred" derivatives in g2 is that they are shown instead of the original file. and still show a "download original" link in addition.
isn't that your intention?
a side effect: they are used as source for other derivatives instead of the original.
@item vs derivative:
i like both approaches. just to explain the item approach, consider the GalleryPanaormaItem (modules/panorama/).
actually, this shows another variation: the renderer approach. we render a huge jpg file with a Java applet as renderer.
using a flash application as renderer is conceptionally the same.
but the difference is that you generate a lot of tiles and you don't want to do that again and again.
while you could still do that with an item or renderer approach, I agree that a derivative approach probably makes more sense.
fine with me.
Posts: 39
Yes it should be preferred in that it's the default view, and a "download original" appears. I'd have to look into how to force using the original (and not the zoomify) as the source for other derivatives.
I've tried this (by setting g_derivativeType to 3 in the DB) and strangely there are two links that appear now: "Download photo" and "Download photo in original format" (using the Matrix theme) both which point to the original. Example at http://www.openphotoblog.com/test/photo/main.php?g2_itemId=163 . If it's not the preffered then only the "Download photo" link appears, which is sufficient for me.
I'll just stick to removing the other derivatives for now.
@item vs derivative:
Just a small detail: it seems that the panorama module now is just a renderer, calling $item->setRenderer('PanoramaRenderer') on the PhotoItem. There is no GalleryPanoramaItem any longer.
Again thanks for your help! I've learned a lot recently!
Posts: 8601
PM me your sf.net username and I'll get you setup on gallery-contrib.
yup, design discussions here are great. you can also drop by #gallery IRC on chat.freenode.net
i still suggest the renderer approach..
- GalleryPhotoItem is unchanged, so if someone wants to create a resize they can, and it will be built from the full size.
- if you have no resizes then of course the main item+renderer will be the default view
- the renderer outputs whatever html is needed for the zoomify view
then the question just becomes, where does the resize for the initial zoomify view come from? i think you could either make a new child entity of the GalleryPhotoItem (that is really a DerivativeImage, but not called that so it doesn't appear in the list of resizes), or maybe we still use GalleryDerivativeImage and make a new type DERIVATIVE_IMAGE_HIDDEN.. ie a resize derivative that is "unlisted" by themes.. just some ideas..
Posts: 39
mindless:
if I understand correctly, the zoomify object would be independent of the GalleryPhotoItem (not a real derivative, just a ChildEntity), and would be the default renderer for the fullsize. There would then be a link to download the original fullsize photo, done automatically by the theme when viewing the fullsize?
The "resize for the initial zoomify view", is that the container for the zoomify tiles?
I guess this would be a good idea, the zoomify is a child of the fullsize not listed by the themes, but is displayed instead of the fullsize version, and there would still be a link to the fullsize photo by itself.
Posts: 8601
ok, you're all setup in gallery-contrib.. i sent you a PM with some info on where to commit your module.
a renderer is a callback, not an entity. the name of the renderer is attached directly to the GalleryPhotoItem, and then your code is called when that item is rendered. but for your module, you need a resized image in addition to the fullsize (i assume you just give the swf the 2 URLs?). that resize should be a derivative entity, so it can be automatically built, etc. Here's another idea.. make a dummy ChildEntity as a child of the PhotoItem, then make the GalleryDerivativeImage a child of that. kinda hacky, but now this resize won't be shown by themes since it isn't a direct child, but would still be deleted if the photo item is deleted, since it is a descendent.
Posts: 39
Well the image used by the swf viewer is in fact a number of small tiles, and the original becomes irrelevant(for viewing). So the viewer needs the directory where the tiles are kept as well as some optional arguments to control the display.
If I create this GalleryZoomifyItem (not a derivative) and make it a child of the GalleryPhotoItem, will it be rebuilt or deleted when necessary? Or does it absolutely have to be a (hidden) derivative for that? If not I'll adopt your double-descendant hack.
Regarding the rebuilding of resizes and thumbnails, is this done in GalleryDerivative::rebuildCache for each of the derivatives of te original? If not where?
Sorry if we keep bouncing messages, but I want to make it right!
Posts: 8601
i think i can give better advice once i see the code you've got so far, so check it in!
any child entity will be deleted if it's parent is deleted.. but only a real derivative entity will be treated as such for rebuilds, etc. yes, rebuildCache is how derivatives are built.
Posts: 39
It's in svn now.
It needs a few adjustments to be portable to other sites - in function render() it needs the HTTP path to g2data dir (for the tiles). What var / function gives this value, on single and multi-sites? gallery->getConfig('data.gallery.base') gives the file path to g2data, not the HTTP path. I know the g2data should not be accessible to the browser (and the directory is restricted-this is fixed by a .htaccess) but the viewer needs an HTTP path to the dir where the tiles are stored (http://<path_to_g2data>/plugins_dir/modules/zoomify/<itemId>). This is similar to the thumbnail module, but it uses urlGenerator to generate the URL. Perhaps it should reside in another directory?
And the sh script zoomifyimage.sh probably won't run under Windows...
Also the indentation in svn viewer is screwd-up, using emacs as the editor. Weird I used the directives given on the codex page to indent with tabs ansd spaces so that there are 4 spaces at each indentation. When I view the file with less the indentation is correct though.
Posts: 32509
> in function render() it needs the HTTP path to g2data dir (for the tiles
in general, g2daza/ is not in the document root. (for security reasons)
you need to read the file via php and print it out. that's what modules/core/DownloadItem.inc does. all files that g2 delivers run through DownloadItem.inc.
i haven't looked at your code yet. are the tiles GalleryDerivatives? if so, gallery knows how to serve them.
if not, maybe you should consider making them derivatives. how many tiles per image are there?
else you'll need something like DownloadItem.inc in your own module that will read the tile file from disk and print it out.
but i'd really prefer if it was a derivative or so and would use core's DownloadItem since this would be a bad case of code duplication (maintenance, security, ...).
Posts: 39
here you go: there are 121 tiles for one zoomify item, but this can vary depending on the size of the input file. And here is the directory structure for a zoomify item:
-----
[temple]$ ls -R 225
225:
ImageProperties.xml TileGroup0
225/TileGroup0:
0-0-0.jpg 3-0-2.jpg 3-3-1.jpg 4-0-0.jpg 4-1-3.jpg 4-10-6.jpg 4-3-1.jpg 4-4-4.jpg 4-5-7.jpg 4-7-2.jpg 4-8-5.jpg
...many others...
3-0-1.jpg 3-3-0.jpg 3-5-3.jpg 4-1-2.jpg 4-10-5.jpg 4-3-0.jpg 4-4-3.jpg 4-5-6.jpg 4-7-1.jpg 4-8-4.jpg 4-9-7.jpg
-----
So there is the ImageProperties.xml file and the TileGroup0 directory which contains the tiles.
And the viewer just uses the url to the directory where this stuff resides (e.g. http://www.openphotoblog.com/test/photo/g2data/plugins_dir/modules/zoomify/225/) and from the information in ImageProperties.xml knows which tiles to get and where.
The ZoomifyItem is a derivative of the PhotoItem, but only one item which knows where it's directory is.
So we have a problem if we want to serve each file, because the reader just needs the URL of the directory...
I've circumvented the security restriction with a local htaccess but it won't work when the g2data is not in the document root.
Your thoughts?
Posts: 8601
in svn, great! i did a quick cleanup pass (added properties, removed tmp dir, whitespace/phpdoc fixes). i'll try to actually look at the code later..
Posts: 32509
121 tiles, that's a lot (but maes sense).
alternatives:
- 121 derivatives (sounds like a overkill solution)
- 121 files that are served by a DownloadTile.inc file from your module
- 1 single file that stores the 121 files and seeks to a specific position to serve e.g. tile 15. only profit is when the filesystem is bad with lots of files
anyway, the main problem is the public g2data dir and that we place a brutal .htaccess into our g2data dir which basically leads to internal server errors / rejects everything if accessed directly.
i don't like the idea of communicating "if you want to use this module, you need to move your storage folder into the document root". our application level permission system wouldn't work anymore to protect the images from direct access. and it would set a bad precedence.
is there really no way that this zoomify flash tool can deal with other urls?
i see an alternative:
use the URL rewrite module to give your module some short urls.
you could then tell zoomify that the tiles are at: http://www.example.com/gallery/tile/225/
'tile' would be the registered prefix for your short url and 225 would be the item id. your TileView is registered for that url prefix and could then serve the ImageProperties.xml and the tile files.
the requirement for your module would then be that the rewrite module is active.
Posts: 32509
or could you tell the zoomify flash that the files are at http://www.example.com/gallery/main.php?g2_view=zoomify.DownloadTile&g2_file=
and zoomify would then request http://www.example.com/gallery/main.php?g2_view=zoomify.DownloadTile&g2_file=ImageProperties.xml (since it just appends the file name to the given url, maybe?).
and then it would request http://www.example.com/gallery/main.php?g2_view=zoomify.DownloadTile&g2_file=TileGroup0/0-0-0.jpg
etc.
so that would work without the URL rewrite module too.
Posts: 39
I tried this idea, using a viewer to download the item. It works to generate a basic URL for the SWF
/test/photo/main.php?g2_view=zoomify.DownloadZoomify&g2_itemId=225&g2_fileName=
and also manually I can accesss the tiles with
/test/photo/main.php?g2_view=zoomify.DownloadZoomify&g2_itemId=225&g2_fileName=TileGroup0/2-2-0.jpg
but the zoomifyViewer removes everything after the first & so it generates requests like:
"GET /test/photo/main.php?g2_view=zoomify.DownloadZoomify/ImageProperties.xml ..."
and stops there because the itemId and fileName are removed...
1) is there a way to pass the url options without &?
2)I guess url rewrite is the way to go, how can I get started?
Posts: 32509
1) with HTTP GET? no. and POST is no option with the flash application i suppose
You'll will need to follow the URL rewrite approach in this case. that way you don't need "&"
2) See getRewriteRules() in module.inc of the following modules:
comment, rss, slideshow, permalinks, keyalbum, dynamicalbum
see: http://gallery.menalto.com/apidoc/GalleryCore/Classes/GalleryModule.html#getRewriteRules (modules/core/classes/GalleryModule.class has the same docs with proper newlines)
Posts: 32509
I forgot to add a link to the real development docs: http://codex.gallery2.org/index.php/Gallery2:URL_Rewrite
Posts: 39
Alright the rewrite rules are now in ZoomifyModule::getRewriteRules()
the pattern is /z/%itemId%/%fileName% and it is locked so that GalleryZoomifyItem::render knows the Url to give to the SWF.
I wasn't able to figure out how to activate the rewrite rule, and make sure the rewrite module is active when activating the Zoomify module. So after activating Zoomify you need to activate the rewrite rule for Zoomify. How can it be activated automagically?
I've added DownloadZoomifyItem.inc (taken from DownloadItem) to actually serve the files to the SWF. Need to return nothing when a directory is queried. I've also deleted lib/htaccess-zoomify since it's not needed anymore!
So the module should work now on any linux setup (I haven't testes on a standalone install though).
It is now needed to decide the links between the fullsize image and the zoomify derivative. Simple Child? Derivative? The best would be the zoomify being a "hidden" derivative of the fullsize, so it's rebuilt or deleted when necessary but doesn't appear in the list of resizes, and it should be shown by default instead of the fullsize (with a "Download original" link). Have a look at the code and tell me what you think please!
P.S. mindless and valiant : you guys rock! thanks for helping me out!
Posts: 32509
excellent
@checking for and activating rewrite:
since you depend now on an active rewrite module, you need to ensure that your module can only be active when the rewrite module is active.
1. you need an event listener on plugin deactivation events. see modules/permalink/module.inc -> registerEventListeners(). your event handler will then check if the deactivated module is rewrite and deactivate itself. the permalinks module does the same.
2. you need to check for an active rewrite module before activating yourself:
you can add the dependency on an active rewrite module to your module's activate() method:
- override the autoconfigure() method and make it return false if the rewrite module is not active, see GalleryModule::autoConfigure
(in autoconfigure, check GalleryCoreApi::fetchPluginStatus('module') to get the status of the rewrite module, see phpdoc for the returned data structure)
- you could show a module configuration view that explains the dependency on the rewrite module
- you need to check for an active rewrite module in activate() as well
3. so what happens if your module deactivates? there are still some zoomify images in your albums. :/ i guess we can't do much about that. we have the same problem with other modules.
i forgot about a disadvantage of not using core.DownloadItem (= tiles not being derivatives):
performance
we do quite a few short-cuts and optimizations for core.DownloadItem.
with tiles having to go through zoomify.DownloadZoomifyItem we load the whole framework on each tile request. we'll see how that performs.
Posts: 39
ok thanks let me work on this in my spare time this week.
how can I activate the rewrite rules automagically(when I activate my module)? Your excellent info is relevant to the status of the rewrite module.
regarding the zoomify.DownloadZoomifyItem, I was well aware that this could have a performance hit. Perhaps it was my imagination but when testing the display it was a bit long on loading the tiles. However Dreamhost has some problems sometimes...
I don't see the short-cuts and optimizations you are talking about in core.DownloadItem (that's modules/core/DownloadItem.inc right?). For zoomify.DownloadZoomifyItem, we could make some optimisations like serving the file directly without reading it (stats()), and other tests. I'll check that out, I guess we don't need the mime types and things like "Expires:" headers, unless the zoomify has itself been rebuilt?
Posts: 32509
> how can I activate the rewrite rules automagically
you can't. there's no API to do that outside of the rewrite module and since it doesn't expose its methods as a versioned API, you should not use rewrite module methods from any other module.
you'll have to show a message to the users that they need to enable the rewrite rule themselves. you can do that e.g. in a configuration view or the same way as it is done in the permalinks module as a result view of the activate() method.
@core.DownloadItem:
the main optimization we did (that cannot be done for other modules):
fastDownload caches. all files that can be viewed by the public have a fastDownload cache (it's basically just a while(fread) print script of 5-10 lines). main.php checks if the request is core.DownloadItem and if it's cached, if so, do not include tons of php files and do not load the framework, just include the fastDownload file and we're done.
this saves a lot of time and CPU load.
the optimizations you mention are minimal and wouldn't really help a lot compared to the time that is spent before your view is executed. i wouldn't do those changes.
Posts: 39
I'll put an option to specify a temp dir (webroot and filesystem) to store the zoomify tiles, accessible from the webroot. The default install will be a little slower and work in whichever location of the g2data dir.
I don't see a security risk here, and I don't see the point in loading the whole framework to serve tiny files, in the order of 1-20 kb...
Posts: 32509
maybe that makes sense. the only other viable option would be to create a derivative for each tile since that would make it use the core.DownloadItem optimizations.
just in case you can't understand the security concerns of not having g2data/ in the webroot at all:
- you can't enforce access permissions (who's allowed to download a specific file) without it
- people can guess urls or do a programmatic search, so if the files are somewhat sensitive or of high value you should not consider putting them into the webroot
- and we store other information (cached data) in g2data/, it wouldn't be good to let everybody d/l it
so as long as you explain that one probably shouldn't use the zoomify viewer with the "temp dir in web root" option for sensitive images, it sounds ok.
Posts: 32509
Etienne,
You'll have to remove the zoomify .swf file from svn. We cannot package / ship a module that has non-GPL compatible components.
Either that or we need to be able to provide the source code of zoomify.
Please remove it.
Then I suggest that you include instructions in a module config view on where to get the zoomify flash app and where to copy it.
Then you can check if the file is in the lib dir as instructed and then the users can activate the module.
Another alternative:
On module installation time, fetch the zoomify.swf directly from the official company server and store it on the gallery server. ;)
Thanks for understanding this. We're GPL and cannot change the rules.
Posts: 39
Alright it's been removed, sorry for the trouble.
1)
When I first read the licence I thought that there was not a restriction to distribute it (there is no restriction to use it however). It seems that if someone buys the "Zoomifyer for Flash" with source .fla files, then they may redistribute the .swf file.
In an examples package that they provide at http://www.zoomify.com/downloads/ZoomifyExamplesVol2-onlySWFs.zip
there is a file called Legal Notices.txt where it is written "The following Zoomify viewing software may be freely distributed in non-source":
-----
1. GRANT OF LICENSE. Zoomify grants to you a nonexclusive, royalty-free, right to use the SOFTWARE. You may only install or otherwise use the SOFTWARE on one computer. If you use the SOFTWARE on additional computers, additional licenses must be obtained from Zoomify, Inc. The following Zoomify viewing software may be freely distributed in non-source (compiled or published) form: Zoomify Viewers, Zoomify Viewer SWF (with import protection enabled). The Zoomify Annotation System SWF file(s) may not be redistributed, but may reside on one (1) server per license purchased.
...
-----
Would this violate the GPL if we distribute third-party packages which we are allowed to freely distribute?
2)
Can I however host the file somewhere and then fetch that file at install? Or it has to be fetched from the official company server?
Posts: 32509
1)
> The following Zoomify viewing software may be freely distributed in non-source (compiled or published) form:
GPL software must be freely distributable including the source code. So that's a no, we can't include .swf in G2 and we can't buy a single license and then offer that for download for our users.
2)
Their license says: "may be freely distributed in non-source".
So from their point of view it's ok to host their .swf and have other people download it. Probably there's a clause that the license must be included when distributing it.
I'd ask myself what you gain by hosting the file on your own server or on gallery.menalto.com. We're resilent to URL changes, license changes and the like. So that's an advantage. Anything else?
So that leaves us the question: Concerning the GPL, is there any difference between instructing users to download a non-GPL component to make the module work vs. doing it at install time for them.
I'm not a lawyer, but I would say you can do that, you can download the non-GPL component at install time. But you need to include their license in the lib/ folder.
Posts: 2
The Brain Maps API is a lightweight multiresolution image viewer that lets you view Zoomify images. It has been designed to be small and fast, and to consume very little memory, yet still be very functional and extensible. Future versions will enable you to add overlays to multiresolution images (including markers and polylines) and to display clickable labels. The Brain Maps API is a free service, available for any web site that is free to consumers. Available at http://brainmaps.org/index.php?p=brain-maps-api
Posts: 39
It seems pretty interesting, I assume that we could bundle the code and make modifications to it keeping the original copyright information.
If I have some time later this week I'll check it out in more detail. Thanks
Posts: 2
Has anyone used the MagicZoom zoomifier with Gallery? I'd like to use it to provide high res close-ups of my smaller images.
http://magictoolbox.com/magiczoom/
If so, what's involved for integration?
Thanks in advance,
Jake
Posts: 344
Not sure I understand....is there a module for zoomify that we can use with Gallery2?
Posts: 39
yup the module lets you create the zoomify file from the original and displays them with the zomify viewer
Posts: 344
Thanks for that info! But I was asking...where do I get this module?
Posts: 39
It's in the gallery-contrib svn you can browse it at
http://gallery-contrib.svn.sourceforge.net/viewvc/gallery-contrib/trunk/gallery2/modules/zoomify/
You need to download the zoomify swf viewer from the zoomify site.
Sorry I don't have more time to help you at this time.
Posts: 10
Hey everyone!
We've just released the zoom module for Gallery!
You can download the Magic Zoom Gallery module here:
http://www.magictoolbox.com/magiczoom_gallery/
Upload the plugin to your Gallery website, activate it and enjoy the zooming effect on your photos! The effect appears as the user hovers over the image. Look at the example.
Magic Zoom is free to use if your website is non-profit. If it is a commercial site, then there is a license fee.
Here is a screenshot of it working:
To zoom an image, you just link the small image to the big one. The HTML would look something like this:
We can help you add it to your website if you are stuck. Contact us here:
http://www.magictoolbox.com/contact/
Enjoy!
Magic Toolbox
www.magictoolbox.com
Posts: 388
Here we have what I classify as one of the coolest modules since sliced bread.
Thanks for contributing!
Does or can this work with Wordpress/Gallery2 in Posts??
Posts: 10
Thanks Swordfish!
Yes, Magic Zoom also works with WordPress posts.
You can download the WordPress plugin here:
http://www.magictoolbox.com/magiczoom_wordpress/
Posts: 388
Double thanks! This is some really cool innovation.
Posts: 41
Is there a working gallery example? I would like to see in used on a site. Thanks!
Posts: 25968
Magic Toolbox,
This is a great module, thanks for the contribution!
One feature request: Make it a per album setting or 'block' so that some albums can have this feature and other can't.
It is hard on some themes to add comments, view slide show, etc without going to the photo.tpl page.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 10
Tlmothy - here is an example of Magic Zoom on a Gallery site. Hover over the images!
http://test.tomalik-net.de/gallery2/main.php?g2_itemId=330
(It's not our site, so we can't guarantee that this link will always work. We will set-up our own demo site in the future).
Floridave - good feature request! Leave it with us...
Posts: 41
It's nice but how do open the full sized image? Wouldn't it be better to insert zoomify on the photo page instead of the album page? And if you notice the zoom box goes out of the browser space when you hover on a far right thumbnail. The random image is also bugged.