Hoi, I blogged about the 15 meter Indonesian story cloth that has been restored and patched into a single 992.4 MB file by Durova. Using the MediaWiki software, it is unmanageably big. There are many image files that are too big to handle.
Djatoka is open source software that allows us to manage files that are a tad too big.
http://ultimategerardm.blogspot.com/2010/03/indonesian-story-cloth-there-for... http://ultimategerardm.blogspot.com/search/label/Djatoka
Thanks, GerardM
Is the image actually too big for MediaWiki to handle, or just too big for the maximum file upload size as currently set? Are there limiting factors within the Mediawiki software or the image tools that it uses that prevent rescaling of large images for online viewing?
I would love to see something like Zoomify/SlippyMap for all image on Commons (or even direct on Wikipedia) as a way of zooming in on detail rather than needing to download the whole image - presumably that's essentially what Djatoka does? Also, presumably the limit in getting this working with MediaWiki is developer time - or are there other limitations? Is this something that would come under the Multimedia Usability Project?
Mike
On 11 Mar 2010, at 01:54, Gerard Meijssen wrote:
Hoi, I blogged about the 15 meter Indonesian story cloth that has been restored and patched into a single 992.4 MB file by Durova. Using the MediaWiki software, it is unmanageably big. There are many image files that are too big to handle.
Djatoka is open source software that allows us to manage files that are a tad too big.
http://ultimategerardm.blogspot.com/2010/03/indonesian-story-cloth- there-for-you-to.html http://ultimategerardm.blogspot.com/search/label/Djatoka
Thanks, GerardM _______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hoi, The file of the story cloth is almost 1 gigabyte. MediaWiki will download a picture from top to bottom. This is prohibitively expensive and also the user experience is not good... Think also about those poor people who use wikipedia on their mobile !!
Rescaling makes sense up to a point. The point is the size of the screen, not the size of the picture.
The argument about developer time is a nonsence. It is about priority. There is now a project for Commons usability / user experience and in my perception this is where signals like this belong. In the end this is where it may get its priority. Djatoka has the advantage of a universal apeal.
Did I tell you that Djatoka is open source ? Thanks, TerardM
On 11 March 2010 10:58, Michael Peel email@mikepeel.net wrote:
Is the image actually too big for MediaWiki to handle, or just too big for the maximum file upload size as currently set? Are there limiting factors within the Mediawiki software or the image tools that it uses that prevent rescaling of large images for online viewing?
I would love to see something like Zoomify/SlippyMap for all image on Commons (or even direct on Wikipedia) as a way of zooming in on detail rather than needing to download the whole image - presumably that's essentially what Djatoka does? Also, presumably the limit in getting this working with MediaWiki is developer time - or are there other limitations? Is this something that would come under the Multimedia Usability Project?
Mike
On 11 Mar 2010, at 01:54, Gerard Meijssen wrote:
Hoi, I blogged about the 15 meter Indonesian story cloth that has been restored and patched into a single 992.4 MB file by Durova. Using the MediaWiki software, it is unmanageably big. There are many image files that are too big to handle.
Djatoka is open source software that allows us to manage files that are a tad too big.
http://ultimategerardm.blogspot.com/2010/03/indonesian-story-cloth- there-for-you-to.html http://ultimategerardm.blogspot.com/search/label/Djatoka
Thanks, GerardM _______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On 11 March 2010 09:58, Michael Peel email@mikepeel.net wrote:
I would love to see something like Zoomify/SlippyMap for all image on Commons (or even direct on Wikipedia) as a way of zooming in on detail rather than needing to download the whole image - presumably that's essentially what Djatoka does?
There's a good article on the implementation of Djakota here:
http://www.dlib.org/dlib/september08/chute/09chute.html
(I was very taken by it when I looked into it for a project at work a year or so back, but that sadly never got off the ground...)
It seems that the main benefit of Djakota is that it's an elegant and open-source front end built upon JPEG 2000; it's this, the actual image format, which allows things like progressive loading from set coordinates within the image rather than downloading the entire file. You need the software to handle them, but you're not tied to a specific implementation.
If we can generate these source files (there are vague worries about licensing, but to my untrained eye it seems okay) and store them without size issues then we'd have two options:
* run a seperate system for viewing very large files, which we hand the user off to, perhaps in a popup window; run this on Djakota or something very like it, hosted locally, and make it seem as seamless as possible
* integrate the "image browser" into MediaWiki itself, like we integrate the existing media players.
Technically, I have no idea which of those would be more desireable or less headachey - anyone?
I do agree entirely that something like this is quite desirable; even if we don't have many individual items requiring this sort of capability now, build it and they will come...
Hoi, We have MANY individual images that will benefit from the Djatoka, more importantly particularly mobile users will benefit a lot.
Almost all our pictures where we look at the full pictures and that are bigger then the screen *will *benefit. When the screen is the same size as the picture, the loading will give you much sooner an impression of the picture, allowing you to abort the rest of the download.
So really truly and honestly the Indonesian story cloth is an extreme example why we will benefit from Djatoka, it is easy to grasp why you NEED it for this picture, all the other pictures are as deserving and, the Djatoka approach provides a much better user experience. Thanks, GerardM
On 11 March 2010 12:02, Andrew Gray andrew.gray@dunelm.org.uk wrote:
On 11 March 2010 09:58, Michael Peel email@mikepeel.net wrote:
I would love to see something like Zoomify/SlippyMap for all image on Commons (or even direct on Wikipedia) as a way of zooming in on detail rather than needing to download the whole image - presumably that's essentially what Djatoka does?
There's a good article on the implementation of Djakota here:
http://www.dlib.org/dlib/september08/chute/09chute.html
(I was very taken by it when I looked into it for a project at work a year or so back, but that sadly never got off the ground...)
It seems that the main benefit of Djakota is that it's an elegant and open-source front end built upon JPEG 2000; it's this, the actual image format, which allows things like progressive loading from set coordinates within the image rather than downloading the entire file. You need the software to handle them, but you're not tied to a specific implementation.
If we can generate these source files (there are vague worries about licensing, but to my untrained eye it seems okay) and store them without size issues then we'd have two options:
- run a seperate system for viewing very large files, which we hand
the user off to, perhaps in a popup window; run this on Djakota or something very like it, hosted locally, and make it seem as seamless as possible
- integrate the "image browser" into MediaWiki itself, like we
integrate the existing media players.
Technically, I have no idea which of those would be more desireable or less headachey - anyone?
I do agree entirely that something like this is quite desirable; even if we don't have many individual items requiring this sort of capability now, build it and they will come...
--
- Andrew Gray
andrew.gray@dunelm.org.uk
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hello, I also think that we need a support for high resultion images. But we should rethink if JPEG2000 and Djatoka is the right way. What's happen with the servers if we get 1000 requests per second and how free is JPEG2000?
If you use instead tiles you can use tile-caches and other server optimisations.
So I experiment a little bit with TMS[1] and create: http://toolserver.org/~kolossos/zoom-image/tms/ To create this tiles I use the opensource tool GDAL2tiles.[2] The frontend is OpenLayers which we want to use in Mediawiki so or so for the Openstreetmap-integration project.
I also test Zoomify so if you want to compare: http://toolserver.org/~kolossos/zoom-image/ but I think we need in the future no flash.
I'm very interested on highresolution pictures and use a panorama robot to create such images and would like to upload pictures like this [3] to commons. What I want to say is that also normal Commons users can create Photos with 1 Gigapixel resolution.
Greetings Tim alias User:Kolossos
[1]http://en.wikipedia.org/wiki/Tile_Map_Service [2]http://en.wikipedia.org/wiki/GDAL [3]http://gigapan.org/gigapans/37926/
Tim Alder wrote:
So I experiment a little bit with TMS[1] and create: http://toolserver.org/~kolossos/zoom-image/tms/ To create this tiles I use the opensource tool GDAL2tiles.[2]
I also test Zoomify so if you want to compare: http://toolserver.org/~kolossos/zoom-image/ but I think we need in the future no flash.
One thing that is needed is to address a specific point in the picture, like a coordinate in a map. When this is applied to digitized newspapers, we need to be able to link directly to the article halfway down in column 5.
I'm certain map tile systems can do this (it works for coordinates in OpenStreetMap), but we need to ask the same question for any image zoom system.
If you use this solution for digitized newspapers or books, you can put all page images in one big zoomable picture.
Hoi, This is indeed a clever approach to the use of a system like Djatoka.. I have no clue if this has been done.. I will ask. Thanks, GerardM
On 13 March 2010 17:36, Lars Aronsson lars@aronsson.se wrote:
Tim Alder wrote:
So I experiment a little bit with TMS[1] and create: http://toolserver.org/~kolossos/zoom-image/tms/http://toolserver.org/%7Ekolossos/zoom-image/tms/ To create this tiles I use the opensource tool GDAL2tiles.[2]
I also test Zoomify so if you want to compare: http://toolserver.org/~kolossos/zoom-image/http://toolserver.org/%7Ekolossos/zoom-image/ but I think we need in the future no flash.
One thing that is needed is to address a specific point in the picture, like a coordinate in a map. When this is applied to digitized newspapers, we need to be able to link directly to the article halfway down in column 5.
I'm certain map tile systems can do this (it works for coordinates in OpenStreetMap), but we need to ask the same question for any image zoom system.
If you use this solution for digitized newspapers or books, you can put all page images in one big zoomable picture.
-- Lars Aronsson (lars@aronsson.se) Aronsson Datateknik - http://aronsson.se
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hoi, This is the answer I received..
It would be quite possible to index the offsets of each article and render a view that presents the article based on the width of the column, screen, etc. This would only really be helpful if pixel-based imagery is necessary, otherwise a text or vector based solution may require less bandwidth.
Thanks, GerardM
On 15 March 2010 19:29, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, This is indeed a clever approach to the use of a system like Djatoka.. I have no clue if this has been done.. I will ask. Thanks, GerardM
On 13 March 2010 17:36, Lars Aronsson lars@aronsson.se wrote:
Tim Alder wrote:
So I experiment a little bit with TMS[1] and create: http://toolserver.org/~kolossos/zoom-image/tms/http://toolserver.org/%7Ekolossos/zoom-image/tms/ To create this tiles I use the opensource tool GDAL2tiles.[2]
I also test Zoomify so if you want to compare: http://toolserver.org/~kolossos/zoom-image/http://toolserver.org/%7Ekolossos/zoom-image/ but I think we need in the future no flash.
One thing that is needed is to address a specific point in the picture, like a coordinate in a map. When this is applied to digitized newspapers, we need to be able to link directly to the article halfway down in column 5.
I'm certain map tile systems can do this (it works for coordinates in OpenStreetMap), but we need to ask the same question for any image zoom system.
If you use this solution for digitized newspapers or books, you can put all page images in one big zoomable picture.
-- Lars Aronsson (lars@aronsson.se) Aronsson Datateknik - http://aronsson.se
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Gerard Meijssen wrote:
I blogged about the 15 meter Indonesian story cloth that has been restored and patched into a single 992.4 MB file by Durova. Using the MediaWiki software, it is unmanageably big. There are many image files that are too big to handle.
Djatoka is open source software that allows us to manage files that are a tad too big.
Displaying large images is one field for future work.
How to take such pictures is another. Today's 10 or 12 megapixel cameras take pretty big pictures, and soon we might have 20 or 40 megapixel cameras. But even then, we want to stitch many such images together for some uses.
A third area is to take multiple pictures with different levels of exposure, which can be combined into a high dynamic range (HDR) image, http://en.wikipedia.org/wiki/High_dynamic_range_imaging
A fourth area is to take multiple pictures with different light source directions, to be combined with Polynomial Texture Mapping (PTM), as documented in this Hewlett-Packard research project, http://www.hpl.hp.com/research/ptm/ and shown in this Google Techtalk video, http://www.youtube.com/watch?v=rxNg-tXPPWc
All of these are examples of how we no longer take a single small photo, but a whole bunch and combine them into something much larger and much different.
Ten years ago, digital cameras were very expensive, and we all used scanners to digitize our photos after the film was processed and they were printed on paper. In the coming decade, digital cameras will probably evolve in ways that never could be achieved with old, chemical photography.