Hey, inspired by the Djakota postig I whipped up a little wrapper around IIP [1] and VIPS [2]. It is basically the same think as Djakota, but as a compiled fast-cgi program (rather than Java).
A couple of examples: http://toolserver.org/~dschwen/iip/wip.php?f=LC-39_Observation_gantry_pano.j... http://toolserver.org/~dschwen/iip/wip.php?f=Chicago.jpg http://toolserver.org/~dschwen/iip/wip.php?f=Seattle_7.jpg
The examples use a flash viewer, but you can append &flash=no to the urls to get a Javascript viewer.
It should work to replace the names with arbitrary images on commons, but new images will have to be processed into a pyramidal tiled tiff image (with jpg compression) first. That takes time, about a minute. After that the image is cached and the viewer appears immediately. Be warned, there is no visual feedback that anything is happening while the image is processed. So be patient and try a reload after waiting a minute or so.
I'll write a gadget to integrate this into commons (the gadget will only appear on images with a certain minimum size).
Best, Dschwen
[1] http://iipimage.sourceforge.net/ [2] http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS
Daniel Schwen wrote:
A couple of examples: http://toolserver.org/~dschwen/iip/wip.php?f=LC-39_Observation_gantry_pano.j... http://toolserver.org/~dschwen/iip/wip.php?f=Chicago.jpg http://toolserver.org/~dschwen/iip/wip.php?f=Seattle_7.jpg
The examples use a flash viewer, but you can append &flash=no to the urls to get a Javascript viewer.
Nice! But after I have zoomed in on a detail, I need to derive a permanent link to that point/coordinate (x+y+zoom). It's not half as useful without that feature.
Hoi, I am really happy with you having an inspiration .. One of the biggest advantages I see is that we will have something we can work with soon. I hope it will inspire Guillaume and his team to have a good hard look at it and make it standard functionality.
I have blogged several times about Djatoka, what I would like to know if the approaches that I discussed can be done in this way. Thanks, GerardM
http://ultimategerardm.blogspot.com/search/label/Djatoka http://ultimategerardm.blogspot.com/2010/03/new-graphics-developments-for-me...
On 19 March 2010 04:56, Daniel Schwen lists@schwen.de wrote:
Nice! But after I have zoomed in on a detail, I need to derive a permanent link to that point/coordinate (x+y+zoom). It's not half as useful without that feature.
Yeah, I know. this should be possible.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On 19 March 2010 02:35, Daniel Schwen lists@schwen.de wrote:
Hey, inspired by the Djakota postig I whipped up a little wrapper around IIP [1] and VIPS [2]. It is basically the same think as Djakota, but as a compiled fast-cgi program (rather than Java).
A couple of examples: http://toolserver.org/~dschwen/iip/wip.php?f=LC-39_Observation_gantry_pano.j... http://toolserver.org/~dschwen/iip/wip.php?f=Chicago.jpg http://toolserver.org/~dschwen/iip/wip.php?f=Seattle_7.jpg
The examples use a flash viewer, but you can append &flash=no to the urls to get a Javascript viewer.
This is beautiful! I'm playing with it on an aging Windows machine, and I think it's smoother to view a large image via this tool than it is to open it locally and scroll across it :-)
Does the processing and recompression cause any noticeable lack of fidelity, do you think? Working from a jpeg original, then converting to tiff and back again sounds like it might be problematic...
Does the processing and recompression cause any noticeable lack of fidelity, do you think? Working from a jpeg original, then converting to tiff and back again sounds like it might be problematic...
I seriously doubt that it causes _noticeable_ lack of fidelity. I think it should work with only one conversion step in any case, as the TIF contains jpg tiles. In theory it should even work without any conversions as it should be possible to tile the raw jpg block data. I googled a bit and it looks like nobody has done this before. Such a tiler has the potential to be both faster and more memory efficient.
But, recompression is not such a bad thing. Especially if you look at the compression ratios some people upload on commons. Photoshop should have a dialog box popping up when ever someone selects jpg quality level 10 (or 100%): "Seriously? Do you think this picture is really woth all those bytes?! I don't think so" And then it should automatically move the slider back to 90% ;-) I'm not talking about restorations here, just about regular photos, where you cannot see the difference IMO.
Daniel Schwen wrote:
I seriously doubt that it causes _noticeable_ lack of fidelity. I think it should work with only one conversion step in any case, as the TIF contains jpg tiles. In theory it should even work without any conversions as it should be possible to tile the raw jpg block data. I googled a bit and it looks like nobody has done this before. Such a tiler has the potential to be both faster and more memory efficient.
In fact JPEG has the image split in blocks, which are compressed separatedly. It should be possible to extract them.
That takes time, about a minute. After that the image is cached and the viewer appears immediately. Be warned, there is no visual feedback that anything is happening while the image is processed. So be patient and try a reload after waiting a minute or so.
If there's it should show a page saying "Please wait while we process the image" with a timer. I get "502 Bad Gateway" and "download wip.php" messages, which probably come from the processing.
It should fallback to javascript vieweer in case there's no javascript support.
You should have built iipimage with FILESYSTEM_PREFIX
I'll write a gadget to integrate this into commons (the gadget will only appear on images with a certain minimum size).
In that case I think you should remove the dependancy on googleapis.com
Good work. Are the wikimedia-specific pieces available?
In fact JPEG has the image split in blocks, which are compressed separatedly. It should be possible to extract them.
That is exactly what I was referring to :-)
If there's it should show a page saying "Please wait while we process the image" with a timer.
I know, I'm working on that right now.
I get "502 Bad Gateway" and "download wip.php" messages, which probably come from the processing.
No, that is an unrelated bug on the toolserver: https://jira.toolserver.org/browse/TS-568
It should fallback to javascript vieweer in case there's no javascript support.
Huh?
You should have built iipimage with FILESYSTEM_PREFIX
Shhh, I know. Don't tell anybody. I'm working on that right now.
In that case I think you should remove the dependancy on googleapis.com
Ok. I'll keep that in mind.