Search the Community
Showing results for tags 'AHRCRTI'.
Found 1 result
We had a good meeting to discuss some elements of the @AHRCRTI project today. For administrative reasons the project now has a revised official start date of 1 August 2013 so expect more regular progress updates from then. Still, the meeting has reminded me that I owe an update to CHI Forums on current planning. As ever we *really* welcome comments and ideas. We are designing this out in the open and so I hope that the results will be a consequence of the RTI community as much as an individual research project. One of the core work-packages for the project is provided an open source RTI viewing framework for the web. Since we also have an interest at Southampton at gigapixel RTI capture and fitting making the web framework support tiled data (as the RTI Viewer and SpiderGL viewers do) has been the driving factor. This in turn has led to us focussing on IIP Image as a mechanism for serving tiles. RTI asset management We have an archive of several 1000 RTIs at Southampton now and managing the data behind these continues to be difficult. As outlined below we have made good progress in frameworks for managing these data in the long term but management during the lifecycle of a project is still complex. We wonder if a new framework is needed or whether existing DAMs can be adapted. Whilst this isn’t in scope for the current project it is something we are looking at alongside. RTI streaming server We want this to be based on the RTI Viewer support of tiled data if at all possible. We really don’t want to fork the format off in a new direction – indeed it wouldn’t be RTI if it did J Interesting stuff to consider here is how best to encode HSH and PTM in tiled formats (and to compress it) and what to do about linking the tiled data to the metadata component of the RTI specification. We also don’t want to look at local solutions for holding the tiled data. The standalone RTI Viewer already does everything needed for interacting with local data. So, for these reasons we are concentrating on modification of IIP Image: http://iipimage.sourceforge.net/ Kirk was a developer of this (see e.g. http://eprints.soton.ac.uk/252876/1/122.html) and the community is active. And IIP Image can be deployed on many server types, has a variety of existing clients, and is now an official Debian and Ubuntu package http://iipimage.sourceforge.net/2012/10/iipimage-now-an-official-ubuntu-package/ RTI ingestion tool We will need a mechanism to allow non server admins to ingest RTI data. We don’t have a sense yet of how this process will work but one option would be to have a user level on the server with permission to upload RTI. We certainly do not intend this server to act as an RTI repository. Whilst such a mechanism could be a side development it is not part of this project. We have already completed some work on RTI data management as part of the JISC DataPool and JISC DepositMORE projects, and the AHRC RTISAD project, which I can describe separately. Basically this facilitates ingestion of RTI data to a repository. Ideally I would like to add an IIP Image server to our Southampton RTI repository to deliver content by the end of this project. RTI viewer Development of this is focused on adding a webGL layer to IIP MOO Viewer: http://iipimage.sourceforge.net/documentation/iipmooviewer/ In the first instance we are assuming webgl support on devices, including tablets. However we also have ideas for a cut down native HTML5 viewer. How far we progress with this will in part depend on how tablet support of webgl changes in the current year. For example, see http://www.techradar.com/news/internet/web/microsoft-s-internet-explorer-11-to-include-webgl-graphics-after-all--1141713 In terms of iOS I would still dearly love to avoid a separate app, particularly as the gyroscope and compass data are so readily accessed from within the browser, but at the moment I think we would still be restricted to very simple RTI rendering options in this case e.g. analogous to hillshade approaches. RTI Annotation We very much hope to be experimenting with the Research Space IIP Image annotation framework soon. This will provide an annotation framework that immediately fits into a wide linked data community and into the associated communities. Leif did some work on the RTISAD project defining a bookmark format for RTI and this has since been developed in discussions with CHI. Our plan is for the new viewer to support this bookmark framework so that a current set of views can be saved as a bookmark and so that a bookmark can be used to set the viewer settings in the browser e.g. the light/s position/s, current filters, etc. One interesting idea that was raised about this at the meeting is that a coherent set of annotations on for example a text artefact would constitute a new publication - this is in fact a standard structure for publishing text artefacts. So, what is the best way to cite these annotations as a coherent argument? A DOI, or via the URI from ResearchSpace? We had thought previously about the ability to link to individual annotations but this feels somehow different to citing a collection of annotations. And what makes it even more exciting will be the ability to change the viewer settings for each annotation in turn, perhaps getting an insight into the reading process (in the case of the text artefacts). Would look nice played as an animation too - cycling through the annotation bookmarks in turn. WordPress plugin to embed the RTI Viewer The final component is easy deployment of the viewer. Hembo already developed a wordpress plugin to use with the MaterialObjects browser and so it is a natural step for us to implement the new RTI Viewer in such a way that it can be easily embedded in wordpress and exposed to allow control from the wordpress page e.g. setting viewer parameters based on a bookmark referenced on the page, or even perhaps using wordpress tags to define preset RTI views.