Image Banks, which are collections of images with associated data and captions, are a valuable teaching tool for Astronomy courses at the Open University.  Until now web pages have been created for each image and its associated information.  This paper examines how a database, front-ended by a multimedia authoring tool, can provide a much more flexible and maintainable architecture for producing Image Banks.  Accessibility issues are discussed

Lucas, Robert

English

Open Research Online

Open Research OnlineThe Open University’s repository of research publicationsand other research outputsThe design of an Image BankJournal ArticleHow to cite:Lucas, Robert (2009). The design of an Image Bank. New Directions, 5(2009), pp. 26–30.For guidance on citations see FAQs.c© 2009 The AuthorVersion: Accepted ManuscriptLink(s) to article on publisher’s website:http://www.heacademy.ac.uk/physsci/resources/detail/publications/newdirections/new directions september 2009 issue 5Copyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copy-right owners. For more information on Open Research Online’s data policy on reuse of materials please consultthe policies page.oro.open.ac.uk 1 The Design of an Image Bank  Robert J Lucas (r.j.lucas@open.ac.uk) Department of Physics and Astronomy The Open University Abstract:  Image Banks, which are collections of images with associated data and captions, are a valuable teaching tool for Astronomy courses at the Open University.  Until now web pages have been created for each image and its associated information.  This paper examines how a database, front-ended by a multimedia authoring tool, can provide a much more flexible and maintainable architecture for producing Image Banks.  Accessibility issues are discussed. Introduction Image Banks are used within several science courses1,2,3 presented by the Open University.  They typically consist of between one and six hundred images with titles, captions (often running to a thousand words or more), dates, credits and scale information. The idea is that these images can be browsed by logical sections or by searches on the captions.  The student might be investigating a certain kind of object.  Sometimes exercises can be carried out on the images such as measurement of a particular feature.  The image banks are perceived as being vital components of the relevant courses and are well received by the students.  They offer a way to deliver large volumes of information that are based around images in a way that can easily be accessed and searched.  Many of our subjects contain large numbers of educationally valuable images that would be difficult to produce in book form, due to the volume and regular updating of the images.  In particular, astronomical images are constantly being updated with new discoveries and better resolution images and images taken at different wavelengths.  For these reasons we perceive image banks as being a generally applicable teaching tool which might be used across many subject areas where large numbers of images and associated captions are a beneficial resource. Until recently these image banks have been created by using Dream-Weaver, a webpage authoring package, to create a set of individual web-pages that incorporate the image and the various text fields.  Hence a particular image and its various text fields will become a single web page.  The web-page approach has some advantages: everyone has a browser with which they can view the image bank, so there’s nothing to install and the image bank will run straight from the CD/DVD.  Also screen readers such as JAWS (Job Access With Speech) are able to read the text for partially sighted and blind users and take advantage of text used in Alt-tag fields that are commonly used to describe fields on web pages. It is foreseen that Image Banks will be used more widely due to the successful use of those already in place and the need to provide the students with a tool which they can use alongside the main course material that supports their own exploration of additional material.  Thus a more generic approach to creating and maintaining them is seen as highly desirable.  Ideally, we would like to have a viewer which can be used with any set of images so that the viewer and the sets of data it can use can be maintained independently of each other. Requirements for an Image Bank Viewer. 1. A generic approach can be taken to viewing the images that does not require each image to be individually processed to produce a web-page or some such viewing medium.  It shouldn’t be necessary to produce pages that list all the hyperlinks to sections and subsections.  These should be generated automatically from the data. 2. The viewer must not rely on the user having any particular application installed unless this is something that the user must have anyway (such as a web browser). 3. It should not need to be installed, but should run directly from the CD/DVD as a matter of convenience. 4. We want to be able to pan and zoom images. 5. Measurement tools should be incorporated into the viewer. 6. Accessibility should be addressed. Proposing a solution The first requirement suggests a database approach with each image being associated with a record in a table.  This table would store all the textual items and give the path to the particular image.  A page can then be created that can display any of the images with its associated data fields.  Additionally, pages giving hyperlinks to each of the sections can be generated at run-time.  2 The second requirement rules out using Power Point, Word or whatever as either the application delivery mechanism or as a software component for viewing images or documents. The third requirement makes component-based applications unusable.  Hence, VB, C, C++ and Delphi are all going to be problematic as development tools. Requirement 4 might be met in one of several ways.  A multi-media authoring package might be expected to provide this as a primitive function, but if not, any such environment would be capable of providing this given the ability to program in some embedded language such as Java or C. Requirement 5 can be satisfied just a long as a sufficient amount of programming is available to provide the necessary calculations on the image positions. Requirement 6 will be discussed in its own section ‘Accessibility’. Database Connectivity It is clear that an Image Bank that is required to work with various collections of images and their associated data should be a database application as databases are designed to solve the problem of efficiently storing and giving access to collections of related data.  With the added requirements of needing to operate directly from CD/DVD with no installation then a multimedia development tool with ODBC (Open DataBase Connectivity) is going to be the only solution.  These requirements are met by the Opus Professional Multimedia development environment4.  This has the additional advantage of permitting programming in Java. ODBC drivers, which are available as part of the Windows Operating System, give access to a huge range of databases some of which are not actually genuine databases at all, but are just treated as such.  This is achieved via SQL (Standard Query Language)5.   This allows us to select fields from tables of information, apply conditions on whatever is selected and impose ordering on retrieved datasets.  Whether we have a genuine database system such as Oracle, or a table of data in the form of an Excel spreadsheet is of little consequence as we access both using identical SQL strings.  There are questions of efficiency and sharing which commercial database systems address but simply don’t apply here where we have a relatively small, non-shared dataset.  A fully-fledged database system such as Oracle would not be feasible here.   It couldn’t be provided on a runnable CD/DVD, it would require the user to have Oracle installed, and it’s very expensive amongst many other reasons.  A PC based system such as Access would provide all that we want, but again it could not be used on a runnable CD as it would need to create a log file at run time which could not be achieved on a read-only device.  Hence, an Excel spreadsheet will serve as the database, with the connection to the application provided by a suitable ODBC driver. Accessibility It is certainly not clear that Opus can provide the necessary Accessibility features as its controls do not even support a tab ordering which would allow it to be controlled via the keyboard rather than the mouse.  Some experimentation has shown that tab-ordering can be achieved by programming it in for each screen, but it is surprisingly clumsy and elaborate.  However, it is an easy matter to use keys for the same functions as on-screen buttons.  For example, the PgDn key can be used instead of mouse-clicking on the Page Forward button. Screen readers such as JAWS need access to the underlying text in order to be able to render it as speech.  This is only usually the case for the major Microsoft applications like Word where it has been specially provided for or in HTML documents where the source text is not encoded (surprisingly screen readers never do screen-scraping coupled with Optical Character Recognition, they always require special hooks to be provided that give them access to the underlying text).  JAWS cannot be directly interfaced to the database.  To enable JAWS to read the text it would be necessary for the Image Bank software to extract the data from the database and then present the text in an HTML document or some other format that JAWS could access. In addition to tools such as JAWS which are aimed squarely at the partially sighted or blind user, there are a multitude of Text To Speech (TTS) applications available.  A common facility is being able to paste text into them and have it converted to WAV or MP3 format, i.e. the text is rendered into a spoken form and stored as a sound file in one of the Windows standard formats.  The latest generation of TTS programs, such as Natural Reader from AT&T6 is really very good with a tonal quality that is good enough to be used where students would prefer to listen to the captions rather than read them.  Thus we can take all the text from our captions and other fields and translate them to sound files that can be played by the multimedia application.  Additionally we can make help on navigating and using the application available as both text and speech.  This actually works better than using an application like JAWS which tends to deliver an unnecessarily large amount of information about the current window.  Whereas, our application restricts itself to exactly what the blind user needs to know. DeskBot7 is a freeware clipboard reader that allows the user to configure how the text is to be read.  It is only necessary for the application to copy the text to the clipboard for the DeskBot reader to start  3 reading the text to the user.  The user can also ask for the text to be displayed at any size and at a given number of lines at a time.  This is a very elegant solution as the application, upon extracting the text from the database for the particular image, can at the same time copy this text to the clipboard making it instantly available to the DeskBot reader which renders it as audible. Formatted text There is a requirement for some formatting of the text such as subscripts used in chemical formulae and superscripts to indicate numerical powers.  These are surprisingly awkward to deal with.  A superscript character is not simply an item of a character set.  It is such an item plus additional attributes set for this item.  So when a character string is read in from a database character field there is no such attribute data and any such formatting simply does not exist. Unicode gives us the capability of storing wide character sets, but these do not address consistently the need for superscripts and subscripts.  Typically some values such as 2 for squared and 3 for cubed will exist but little else.  For this reason Unicode is simply a red-herring. The options that remain are to: • Mark all cases of special formatting with escape sequences so that the formatting can be applied once the data has been extracted into the application. • Store the data in a standard format such as RTF (Rich Text Format). Perhaps surprisingly SQL based databases do not have the capability to store any formatted text directly.  There is no formatted text type in the SQL Standard5.  If the second option is to be used then a binary type is needed for a database field which is to store it.  Or store each of the captions in its own formatted file which is then referenced in the database. Having stored it, as binary (which precludes the use of text files or spreadsheets as our database source, something that we might wish to do if we were to use ODBC) then we need to be able to retrieve the formatted text and then display it in its formatted form. We also need to be mindful that we might wish to change other attributes of the text, such as size for readability. Opus will allow us to use a document viewer to view any Active X document (Active X is simply the technology that allows the document to be opened within another applicaton).  However, this requires the application that views this format to be present on the end-user’s machine.  This clearly cannot be guaranteed in the case of Word or Excel.  The only viable format is RTF which can be displayed without recourse to an external application.  Image Bank Design The original image bank was designed for the Introduction to Astronomy Course (S194)1.  The design uses an Excel spreadsheet as the database.  The Image Bank application is written in Opus4 and used an ODBC connection to the database.  The database stores the captions, the image file paths and other information such as credits and image size.  From this spreadsheet all the pages, the section and subsection headings are automatically generated by the viewer.  In the first instance, superscripts and subscripts were catered for using escape sequences.  This is not ideal and in future we will store the captions in individual RTF files with a reference to them in the caption field of the database. Features, such as being able to do on-screen measurements, panning and zooming were exceptionally easy to program into the application using the underlying Java language and the available set of multimedia functions.  4  The Image Bank viewer which shows the measurement of the distance between two sunspots. Extending the design Since building the first image bank for the Introduction to Astronomy course, several more have been built for the Planets course (S196)3 and for the Understanding the Weather course (S189)2.  These two courses added to the requirements.  In particular hyperlinks were required between images and captions.  Also more control over formatting the captions was required.  These were both provided for by introducing new escape sequences into the text. We are also now looking at the possibility of generating the final image bank in different formats.  Currently we use the Opus front-end to access the database on a disk.  This means that to update the images or the captions means re-mastering the disk.  However, with all the data stored in a central database we could easily create an application capable of generating HTML pages from the contents of the database that could be updated without any need for updating student copies.  Student feedback The students’ reactions have not been formally evaluated, but comments posted on the students’ forums indicate a general appreciation of the image banks.  Here are some from the S196 Planets – and introduction course: The CD-ROM (with its moving planetary images) and textbook images were all beautifully presented and shown in great clarity and colour The course is challenging, interesting and loaded with up-to-date info and images. And from the S194 – Introduction to astronomy course: …while the CD-ROM images formed an excellent complement to the course book… …beautifully illustrated course materials. Conclusions A high-level multimedia authoring tool coupled to a database has proved an excellent architecture for the design of the Image Bank.  The image bank has been used by many hundreds of students and has proved to be robust with very few issues arising.  We have since developed several more image banks that have demonstrated the advantages of this architecture and have introduced new facilities.  This has shown that this architecture is not limited to astronomical images but is suitable for a wide range of  5 images with associated captions.  We are now looking at designing a Resource Library from which Image Banks for different courses can be automatically generated from the department’s entire collection of image and image-related data.  This will require the course editor to simply select the images required for the course causing the entire CD/DVD image to be created.  This will remove the hard work currently needed to create a new Image Bank and also remove the possibilities for errors.  This work has demonstrated that simply collecting relevant images is straightforward but collecting them with appropriate captions, scales, copyright information and relevant dates needs substantial resources. Using a database to store the image data gives us a very flexible approach and if necessary we can extend our use of the data to automatically generating HTML pages.  As we are moving towards more web content orientated courses this will almost certainly be a future enhancement. Although we haven’t as yet incorporated the text to speech technology into our current version the effectiveness of this approach is manifestly obvious.  Our students can spend their time looking at the images instead of reading the text.  Additionally we can provide instructions for using the package as speech generated directly from the Help text.  Both the Natural Reader software and the DeskBot approaches have been tried.  We abandoned Natural Reader because of licensing reasons, but DeskBot has proved to be very easy to use and highly effective and I would expect it to be incorporated in future versions of the image bank. Acknowledgements The images and captions for the S194 – Introduction to astronomy course were collated and edited by Bob Lambourne and Simon Green of the Open University.   The images and captions for the S189 – Understanding the weather course were collated and edited by Shelagh Ross and Stephen Lewis of the Open University.   The images and captions for the S196 – Planets – an introduction course were collated and edited by David Rothery of the Open University.   References: 1. S194 – Introducing astronomy http://www3.open.ac.uk/courses/bin/p12.dll?C01S194 2. S189 – Understanding the weather http://www3.open.ac.uk/courses/bin/p12.dll?C01S189 3. S196 – Planets: an introduction. http://www3.open.ac.uk/courses/bin/p12.dll?C01S196 4. Illuminatus Opus Pro User Manual and Additional Features.  Digital Workshop Ltd. 5. A Guide to the SQL Standard.  C.J. Date with Hug Darwen.  Addison Wesley 1993. 6. Natural Reader - http://www.naturalreaders.com/ 7. DeskBot - http://www.bellcraft.com/deskbot/ 

The design of an Image Bank

Abstract

Similar works

Full text

Available Versions

Open Research Online