- Email: [email protected]
Design and implementation factors in image retrieval across a wide area network—A commercial example
~
Pergamon
International Journal of Information Management, Vol. 16, No. 5, pp. 381-390, 1996 Copyright (~) 1996 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0268-4012/96 $15.00 + 0.00
PII: S0268-4012(96)00024-2
Design and Implementation Factors in Image Retrieval Across a Wide Area NetworkmA Commercial Example D J CHAFFEY
An assessment is made of the range of design and implementation factors that need to be considered when implementing a client/server based image retrieval system across a wide area network (WAN). The assessment is based on the commercial implementation of a customer facing system to display digital photographs of properties for a large estate agency chain. The digital images are displayed to customers on PC based clients and retrieved across a WAN from a server running a Windows NT hosted Oracle Relational Database Management System. It is shown how key image attributes: size; resolution; colour depth and compression method affect the balance between image quality and data volume/ retrieval times for this image retrieval application. The change in business processes involved in retrieving digital images across a WAN is also considered. It is shown that there is additional complexity in processes and an increased hardware specification, both leading to increased costs on traditional character based applications. Copyright (~ 1996 Elsevier Science Ltd
Dave Chaffey has extensive experience of working in the software industry on corporate software projects for British companies, in roles varying from business and systems analyst to project manager. He is currently Lecturer in Business Information Systems in the School of Business at the University of Derby. His main research interests are the application of groupware to computer supported co-operative work in service-oriented businesses and software project management techniques.
IO'BRIEN, J. (1993) Management Information Systems: A Managerial End User Pers~cective 2nd edition, Unwin, New York OMetrrlNG (1995) November
Introduction An increasing number of organisations are currently seeking to improve the quality of customer service and thus differentiate themselves from the competition using customer accessible information systems. These systems often incorporate digital photographs or video to provide a high-quality, attention catching image of available products. The technology may be deployed either as an information kiosk with which the customer interacts directly, or as a desktop system which is used together with a sales or service assistant. Example applications include systems for banks, travel agents, building societies and estate agents.1 Recently, the estate agency division of General Accident PLC has introduced such a customer facing system to assist in the sale of properties. 2 The current study explores the range of factors involved in implementing this type of system for another UK-based estate agency chain. The objective of this evaluation is to identify the key design decisions affecting image quality, data volumes and retrieval times for image retrieval. To achieve this the business objectives are described first and then the decisions reviewed for different stages in the project. Thus the focus of this description is on the constraints in capture, storage, retrieval and display of the property image data and how these governed the implementation of the system. This evaluation provides a checklist which could be applied in other similar implementations.
381
Image retrieval across a wide area network. D J Charley
Figure 1
Property selection screen in image application
Business objectives of implementation The purpose of the project was to produce an application for estate agents which would facilitate all aspects of the sales negotiators' work of arranging the sale and purchase of properties. The main business objective of the system development was to increase market share by providing a software system that differentiated the agency from the competition. This market differentiation was achieved by producing a highly graphical, customer facing application with the main interactive screen consisting of a location map indicating the position and details of properties including interior and exterior photographs (Figure 1). Facilities were also provided to automatically match an applicants' requirements against the properties available. Additionally, workgroup and workflow facilities were provided to improve customer service and to enable an increased number of customers to be serviced by the same number of staff. It was also hoped that market share could be increased since a greater selection of properties would be available to a customer visiting an individual branch. In the previous non-networked situation, each branch would only hold details of properties available in its catchment. With the new system full sharing of properties and applicants between branches was intended, this was possible through linking each branch via a W A N to a central branch database server holding details of all properties.
Key stages in system design and implementation Owing to the number of factors affecting the use of images and other evolving business requirements, it was not possible to specify detailed requirements at the start of the project. For this reason development occurred on the basis of an iterative or incremental life cycle method as
382
Image retrieval across a wide area network." D J Chaffey
Figure 2 Gallery screen display of property images and summary details described by DeGrace and Stahl. 3 The life cycle stages of specification, design and coding were repeated until the appropriate look, feel and performance for the imaging components were established. Several application prototypes 4 were produced to achieve this. The structure of this evaluation is based on the decisions involved at different stages of the project and for each, describes the basis on which the final decision was made. Often the decision could not be made until several iterations or prototypes had been made.
Stage 1. Define functional requirements The functional or end-user requirements of the image retrieval and display module of the application were driven by the system being used directly with customers. Owing to the need to capture the customers interest and attention and then maintain it the following were important requirements: • good usability with a simple user interface giving easy access to interior and exterior photographs for each property; • high quality of images--clearly showing the features of the property to advantage; • seamless integration of image retrieval into the package; • acceptable retrieval and display performance.
3DEGRACE, P AND STAHL, L H (1990) Wicked Problems, Righteous Solutions: A Catalogue o f Modern Software Engineering Paradigms Y o u r d o n Press/Prentice Hall, En~alewood Cliffs, NJ OAR, B (1984) Application Prototyping A d d i s o n Wesley, Reading, M A
The requirement for image output from the application was to display colour internal and external photographs of all properties currently available for sale. The images were integrated into the system by displaying them in a gallery of properties immediately following a match of an applicants' criteria against the currently available properties. The gallery consisted of four colour property images on a textured blue graphic bitmap background (Figure 2). The acceptable performance level for retrieval and display following completion of a criteria match was set at two to five seconds. Additionally, for each property a 383
Image retrieval across a wide area network: D J Charley
full-screen shot was available for the best shot and all the interior images. The size of this image, the largest in the system was approximately 470 pixels × 320 pixels. The quality of the images was constrained by a combination of the display technology available and the transmission capabilities of the WAN. At Stage 1, when the functional requirements were being defined it was not possible to specify a suitable combination of resolution and colour depth. Further experimentation and prototyping was required to establish this. This is described for Stages 5 and 7.
Stage 2. Define business processes involved in acquiring images To display online images of properties and their interiors it was necessary to revise the business processes involved with the capture and display of the photographs. This had to be achieved in such a way that the previous 48 hours turnaround of photo processed images provided to agents was equalled or improved upon. Figure 3 shows the new processes in comparison with the old. It can be seen from Figure 3 that additional processes were introduced by the use of digital photos and digital image processing between the stage of the negotiator taking the photograph at a property through to it being passed to a customer. This occurred for two reasons, firstly it is necessary to convert the originals to a digital form by scanning and then to manipulate the image so that it is in a suitable form for display (new processes 3 and 4). This is a specialist job requiring an expensive scanner which can only be used centrally. Secondly it is necessary to associate the image with a particular property and room which is already present on the database (new processes 5 and 6). Since the digital image is scanned and manipulated centrally it is not known at the time of scanning which photos correspond to which room, this association can only be done by the negotiator who took the photograph (process 7). It is thought that with the advent of digital cameras costing less than £500, the new process can be streamlined to remove Stages 1 to 3. At the time of the project, however, this technology was not available at the right price. Although the use of the W A N makes image capture processes more complex this is offset by the images for a property being available from all branches.
Stage 3. Define system requirements--architecture The system architecture was of 10 branches and an area office connected using a WAN. Data was accessed using a simple client/server arrangement with PC clients accessing data from a central database server across the WAN. The system architecture for each branch is shown in
Figure 4. Network requirements. Of the constraints on network performance
5TERPLAN,K (1992)
Communications Network Management 2nd edition, Prentice
Hall, NJ
384
described by Terplan, 5 the main determinant was the transmission capacity. Network contention from different sites, database access times and the performance of the gateway product (router) are not considered here since the bandwidth of the network is the most significant factor affecting performance. Each local area network (LAN) was running an Ethernet network giving a transmission speed of 10 Mbps (megabits per second) which did not restrict image display. The many factor was the choice for W A N transmission. The choices were a standard British
Image retrieval across a wide area network: D J Chaffey
Original process p h o t o g r a p h i c prints
N e w p r o c e s s - digital photographs
Property
1.Take photos of property
Property
I .Take photos of property
Photo processors
2.Photo process negatives to produce prints
Photo processors
2.Photo process negatives
Branch
3.Attach photo to particulars and file
Area office
3.Scan negatives to digital form ! !
4.Use Photoshop to reduce colour depth/resolution
4. Retrieval and display
I
5.Associate image to property/branch Branch
6.Associate image to room
i !
7.Retrieval and display
3 Processes required in the digital based image system to capture, retrieve and display images in comparison with the previous system Figure
Local Printers
i
°c_)sl
~
Router o9
th
~
Dockstation laptop
Figure 4
..........................
Network
Area
Office
Printers
Branchsystem architecture 385
Image retrieval across a wide area network: D
J Chaffey Telecom (BT) ISDN network with a transmission of 64 or 128 Kbps (kilobits per second) or an SMDS network running at 448 Kbps. Further tests were required to select which transmission method was used once the optimal image size had been established (Stage 6). Simple calculations described for Stage 7 were used to compare the volume of the image (in kilobytes) with available transmission capacity. These calculations indicated that for images of the required size a sub 5 second retrieval could best be achieved using 448 Kbps. The use of transmission speeds greater than 64 Kbps required for character based systems represents an additional cost required for these types of system. The gateways used were CISCO 7000 routers.
Stage 4. Define system requirements--software components Server. A relational database management system (RDBMS) was selected to store the customer and property data (including the images) on the area office server. Oracle Workgroup Server version 7.1 was selected on the basis of this being an existing company standard which had been used in similar implementations. The Oracle R D B M S was mounted on a server running Microsoft Windows N T Server version 3.51.
PC clients. Each PC used a combination of Microsoft DOS and Windows for Workgroups version 3.11 plus a TCP-IP adapter to provide the operating system, windowing and network environments. The application software was developed using Gupta SQLWindows version 5.01 Corporate edition. The SQLWindows based application accessed the Oracle database for all SQL queries and was also used for all screen display including images.
Stage 5. Define system requirements--hardware components The hardware components are described here in terms of what was used on the server and client parts of the system to give adequate performance with the software that had been selected.
Server hardware. The server selected was a Compaq P75 Prosignia with 3 Gigabyte Level 5 R A I D magnetic storage media. This housed the Oracle R D B M S running under Microsoft Windows NT.
Client PC monitor selection--image colour depth and resolution. The combination of device supported resolution and colour depth was the determinant of the components of the PC compatible hardware. Device resolution was fixed at 800 × 600 pixels with 256 unique colours displayed on a 17-inch monitor (with the capacity to display up to 65 000 colours if required). This resolution was chosen since it was required that the system be used in the field by negotiators carrying notebook computers. This was the maximum practical combination of resolution and colour depth at the time for notebooks. An IBM Thinkpad 755CX was selected for this purpose. By prototyping screen displays with a device resolution of 640 × 480 pixels and 800 × 600 pixels with different combinations of colour depth or colour resolution (4 bit--16 unique colours; 8 bit--256 colours; and 24 bit--16.7 million colours) it was found that 800 × 600 pixels with 256 colours gave an acceptable quality of image coupled with an uncluttered image display in which there was 386
Image retrieval across a wide area network." D J Chaffey
sufficient screen space to display four properties simultaneously. After ensuring that this combination of resolution and colour depth was suitable to provide the right image quality for the application it was then necessary to determine whether the size of image displayed at 800 x 600 pixels and 256 colours could be transmitted at a sufficient speed given the bandwidth of the network. This is described in Stage 7 where it is shown that a transmission capacity of 448 Kbps was appropriate for this combination of image attributes. It is also shown that combinations of greater resolution, colour depth or image size would have been too slow in retrieval with the available transmission capacities.
Other PC components. Of the PC components the key features affecting performance were processor speed, system memory (RAM) and graphics card. The client PC chosen to run this application was a Compaq Prolinea P90 with a 90 MHz Pentium processor, PCI bus and 24 Mb of RAM. A standard Compaq graphics adapter on the motherboard gave sufficient performance at the resolution used. 24 Mb of RAM was required to run the mapping module of the application but comparative tests showed that 16 Mb of RAM was sufficient for the image display module. The choice of monitor and graphics card did not involve any additional expenditure on what could be considered a standard desktop PC. However the use of 24 Mb of RAM in comparison with the standard 8--16 Mb supplied as standard on PC represents a significant additional cost of several hundred pounds per client which is required by the use of digital images. Stage 6. Implement digital picture acquisition and digital image processing
"HEC'KBERT, e s (1986) Filtering by Repeated Integration Siggraph 86, 315-321 7FOLEY, J D, VAN DAM, A s FEINER, S K AND H U G H E S , J F (1990) Computer Graphics:
Principles and Practice Addison Wesley, Reading, MA 8HALL, R (1989) Illumination and Color in Computer Generated Imagery SpringerVerlag, New York
The photographs taken at the property as described for Stage 2 were processed using normal photographic techniques at a photo processing laboratory. These were then captured in digital form using a Kodak colour scanner operating at 1200 x 1200 dpi (dots per inch) and 24 bit colour (16.7 million unique colours). This high end scanner was available on evaluation and was chosen since it had the option to scan from negatives and offered high quality scan resolution. Scanning from negatives was more rapid than manually positioning each print to be scanned. Scanning each negative took approximately 3 minutes. Once scanned, digital image processing was performed using Adobe Photoshop, the de facto standard for PC and Macintosh based processing. Image transformation consisted of reducing the colour depth from 24 bit colour to 8 bit colour and reducing the size of the image to a resolution consistent with an 800 x 600 pixel resolution monitor which is the equivalent of approximately 72 dpi. This produces an improved quality of image compared to an image scanned at the target colour depth and resolution. Transformation was achieved using standard antiliasing or post-filtering methods provided by Photoshop to sample the existing pattern of pixels and then use an average colour for the transformed image. A survey of the types of image transformation used is given in Heckbert 6 and Foley et al. 7 To use the optimal unique 256 coiours in the transformed version a technique known as gamma correction was applied (see Hall 8 for a detailed description).
Stage 7. Implement data storage and retrieval mechanisms The following options were available as the method of data storage: 387
Image retrieval across a wide area network: D J CharleY
Table 1 Difference in theoretical uncompressed image volumes in kilobytes using different combinations of PC screen resolution and colour depth. Calculations are for the largest image in the system which occupies about 31 per cent of screen area (470 × 320 pixels at 800 × 600 resolution) Device resolution (pixels) 640 x 480 800 × 600 1024 × 768 1600 × 1200
4 bit (16 colours)
8 bit (256 colours)
16 bit (65 000 colours)
24 bit (16.7 million colours)
47.6 74.4 121.9 297.6
95.2 148.8 243.8 595.2
190.5 297.6 487.6 1190.4
285.7 446.4 731.4 1785.6
• To store each image in the Oracle database as a Binary Large Object
(BLOB). • To store each images in the Oracle database as a compressed string (of long raw datatype). • To store the individual images as uncompressed bitmap files. • To store the individual images as compressed files using formats such as .GIF. It was decided to take advantage of the facility to store non alphanumeric data in Oracle as B L O B s or Windows bitmaps stored as compressed strings. This decision was taken since the development of the application would be more rapid than the approach of using flat files for which it would have been necessary to write code for image indexing, retrieval and backup. Through using Oracle, standard SQL could be used to retrieve the images and backup of the images was performed along with other data held in the database. Tests conducted before implementation showed that the use of B L O B s caused a once to twice daily downtime on the database possibly due to an error with the SQL*Net router v2.1 when using TCP-IP. A patch release to SQL*Net from Oracle resolved this problem. Due to the instability the decision was taken that the images be stored on the database in fields of type long. This proved to be an acceptable solution and no further instability was encountered. An indication of the storage volumes required per branch were calculated based on the storage required per best shot property image as given in Table 1. Each branch has of the order of 200 properties at a given time. Given an average of 4 images per property this gives a volume of circa 1.4 Gb for the highest possible combination of colour depth and resolution. For the selected resolution of 800 × 600 with 8 bit colour a more practical volume of 120 Mb per branch before compression. A decision also had to be made regarding the physical location of the images. The choices were: • on the central area server (either in the database or as a file); • on a server in each branch office; • on each individual PC. This was a key design decision which depended primarily on the transmission capabilities of the WAN. From the calculations performed using Tables 1 and 2 as described in the following section it was shown that it would be possible within the two to five seconds required to access images and customer/property data held on the central server
388
Image retrieval across a wide area network: D J Chaffey
Table 2 Differences in image transfer speed in seconds given by different combinations of transmission capacity (kilobits per second) and image co/our depth. The calculations are based on the image sizes from Table 1 for an 800 x 600 resolution Transmission speed (Kbps) 28.8 64 128 448
4 bit (16 colours)
8 bit (256 colours)
16 bit (65 000 colours)
24 bit (16.7 million colours)
20.7 9.3 4.6 1.3
41.3 18.6 9.3 2.6
82.7 37.2 18.6 5.3
124.0 55.8 27.9 7.97
from each branch via the WAN. This was the most cost effective solution since it meant that it was not necessary to maintain a separate database or file server in each branch and to setup replication for when new properties were added to the system. Retrieval of the images was performed by issuing a SQL SELECT FROM statement against the master table which held all property images. The SELECT was then performed on the central database and the image was then transmitted from the server over the Wide Area Network and Local Area Network to the PC client making the request where it was converted from a compressed string to a bitmap and then displayed on screen. Selection o f transmission capacity. To calculate a practical transmission
capacity based on the selected combination of colour depth and resolution Table 2 was used. Table 2 gives theoretical transmission times in seconds assuming 100 per cent of the transmission capacity is available. The calculations are based on image size for a device resolution of 800 x 600 pixels from Table 1. Table 2 shows that for the required retrieval time of 2 to 5 seconds only the 448 Kbps link was appropriate. These theoretical times were improved on due to the image being compressed using a lossless compression method available with Gupta SQLWindows where a bitmap is converted to a compressed string for transmission and storage. This reduces the size of the image to be transmitted to 50-70 per cent of the original depending on the number of repeating pixels. Thus the actual times observed were 50-70 per cent of those in Table 2. To confirm that a 448 Kbps transmission capacity would be required physical tests were also used.
Conclusion It is evident from the review of the decisions required during design and implementation that the introduction of digital images to an information system may increase the complexity, hardware requirements and hence the cost of the system. Table 3 summarises the decisions required during the project. The associated additional costs were justified since graphical systems incorporating digital images provide an improved quality application which is easier to understand by the customer and aids differentiation from the competition. The complexity introduced implies good planning is required to undertake the prototyping and system benchmarks required to identify suitable key image attributes which 389
Image retrieval across a wide area network: D J Chaffey
Table 3
Summary of key factors determining image capture, storage and retrieval
Decision
Option chosen
Option 2
Option 3
1. Type of camera
Standard film
Digital
2. Type of scanner
Scan from negatives
Scan from print
3. Scanning resolution/colour depth
Maximum available
That appropriate for screen output device ie c 60 dpi and 256 colours
Between options 1 to3
4. Method of image storage
Database compressed string
Database
Flat file
5. Location of image storage
Central server
Server in each branch
Each client PC
6. Screen resolution
800 x 600 pixels
640 x 480 pixels
1024 x 768 pixels
7. Colour depth
8 bit (256 colours)
4 bit (16 colours)
16 or 24 bit (to 16.7 million colours)
8. Type of graphics card to support chosen colour depth and resolution
Support for 16 bit (65 000 colours at 800 x 600 pixels)
Support for 8 bit (256 colours at 800 x 600 pixels)
Support for 24 bit (16.7 million colours at 800 x 600 pixels)
9. Network transmission
SMDS 448 Kbps
ISDN 64 Kbps
ISDN 128 Kbps
10. Network protocol
TCP-IP 32 bit
IPX/SPX
BLOB
Reason Technology for 2 unavailable with correct cost performance Higher quality images, more rapid throughput from using negatives Better quality obtained by scanning at highest available resolution number of colours and then reducing using Photoshop Could use RDBMS facilities~least coding and best stability Least complex option--no replication required Best compromise between storage requirements and image speed and quality. Maximum resolution of laptops used Best compromise between storage requirements and image speed and quality. Maximum resolution of laptops used Was required to remove 'palette flashes' in application although only 256 unique colours used. Used Compaq card installed on rnotherboard Needed to achieve retrieval in 2 to 5 seconds Chosen for simplicity of use across WAN
provide a useable system for the selected hardware and network bandwidth. The key attributes are image quality, size, number of colours, screen resolution and compression method. 390
Pergamon
International Journal of Information Management, Vol. 16, No. 5, pp. 381-390, 1996 Copyright (~) 1996 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0268-4012/96 $15.00 + 0.00
PII: S0268-4012(96)00024-2
Design and Implementation Factors in Image Retrieval Across a Wide Area NetworkmA Commercial Example D J CHAFFEY
An assessment is made of the range of design and implementation factors that need to be considered when implementing a client/server based image retrieval system across a wide area network (WAN). The assessment is based on the commercial implementation of a customer facing system to display digital photographs of properties for a large estate agency chain. The digital images are displayed to customers on PC based clients and retrieved across a WAN from a server running a Windows NT hosted Oracle Relational Database Management System. It is shown how key image attributes: size; resolution; colour depth and compression method affect the balance between image quality and data volume/ retrieval times for this image retrieval application. The change in business processes involved in retrieving digital images across a WAN is also considered. It is shown that there is additional complexity in processes and an increased hardware specification, both leading to increased costs on traditional character based applications. Copyright (~ 1996 Elsevier Science Ltd
Dave Chaffey has extensive experience of working in the software industry on corporate software projects for British companies, in roles varying from business and systems analyst to project manager. He is currently Lecturer in Business Information Systems in the School of Business at the University of Derby. His main research interests are the application of groupware to computer supported co-operative work in service-oriented businesses and software project management techniques.
IO'BRIEN, J. (1993) Management Information Systems: A Managerial End User Pers~cective 2nd edition, Unwin, New York OMetrrlNG (1995) November
Introduction An increasing number of organisations are currently seeking to improve the quality of customer service and thus differentiate themselves from the competition using customer accessible information systems. These systems often incorporate digital photographs or video to provide a high-quality, attention catching image of available products. The technology may be deployed either as an information kiosk with which the customer interacts directly, or as a desktop system which is used together with a sales or service assistant. Example applications include systems for banks, travel agents, building societies and estate agents.1 Recently, the estate agency division of General Accident PLC has introduced such a customer facing system to assist in the sale of properties. 2 The current study explores the range of factors involved in implementing this type of system for another UK-based estate agency chain. The objective of this evaluation is to identify the key design decisions affecting image quality, data volumes and retrieval times for image retrieval. To achieve this the business objectives are described first and then the decisions reviewed for different stages in the project. Thus the focus of this description is on the constraints in capture, storage, retrieval and display of the property image data and how these governed the implementation of the system. This evaluation provides a checklist which could be applied in other similar implementations.
381
Image retrieval across a wide area network. D J Charley
Figure 1
Property selection screen in image application
Business objectives of implementation The purpose of the project was to produce an application for estate agents which would facilitate all aspects of the sales negotiators' work of arranging the sale and purchase of properties. The main business objective of the system development was to increase market share by providing a software system that differentiated the agency from the competition. This market differentiation was achieved by producing a highly graphical, customer facing application with the main interactive screen consisting of a location map indicating the position and details of properties including interior and exterior photographs (Figure 1). Facilities were also provided to automatically match an applicants' requirements against the properties available. Additionally, workgroup and workflow facilities were provided to improve customer service and to enable an increased number of customers to be serviced by the same number of staff. It was also hoped that market share could be increased since a greater selection of properties would be available to a customer visiting an individual branch. In the previous non-networked situation, each branch would only hold details of properties available in its catchment. With the new system full sharing of properties and applicants between branches was intended, this was possible through linking each branch via a W A N to a central branch database server holding details of all properties.
Key stages in system design and implementation Owing to the number of factors affecting the use of images and other evolving business requirements, it was not possible to specify detailed requirements at the start of the project. For this reason development occurred on the basis of an iterative or incremental life cycle method as
382
Image retrieval across a wide area network." D J Chaffey
Figure 2 Gallery screen display of property images and summary details described by DeGrace and Stahl. 3 The life cycle stages of specification, design and coding were repeated until the appropriate look, feel and performance for the imaging components were established. Several application prototypes 4 were produced to achieve this. The structure of this evaluation is based on the decisions involved at different stages of the project and for each, describes the basis on which the final decision was made. Often the decision could not be made until several iterations or prototypes had been made.
Stage 1. Define functional requirements The functional or end-user requirements of the image retrieval and display module of the application were driven by the system being used directly with customers. Owing to the need to capture the customers interest and attention and then maintain it the following were important requirements: • good usability with a simple user interface giving easy access to interior and exterior photographs for each property; • high quality of images--clearly showing the features of the property to advantage; • seamless integration of image retrieval into the package; • acceptable retrieval and display performance.
3DEGRACE, P AND STAHL, L H (1990) Wicked Problems, Righteous Solutions: A Catalogue o f Modern Software Engineering Paradigms Y o u r d o n Press/Prentice Hall, En~alewood Cliffs, NJ OAR, B (1984) Application Prototyping A d d i s o n Wesley, Reading, M A
The requirement for image output from the application was to display colour internal and external photographs of all properties currently available for sale. The images were integrated into the system by displaying them in a gallery of properties immediately following a match of an applicants' criteria against the currently available properties. The gallery consisted of four colour property images on a textured blue graphic bitmap background (Figure 2). The acceptable performance level for retrieval and display following completion of a criteria match was set at two to five seconds. Additionally, for each property a 383
Image retrieval across a wide area network: D J Charley
full-screen shot was available for the best shot and all the interior images. The size of this image, the largest in the system was approximately 470 pixels × 320 pixels. The quality of the images was constrained by a combination of the display technology available and the transmission capabilities of the WAN. At Stage 1, when the functional requirements were being defined it was not possible to specify a suitable combination of resolution and colour depth. Further experimentation and prototyping was required to establish this. This is described for Stages 5 and 7.
Stage 2. Define business processes involved in acquiring images To display online images of properties and their interiors it was necessary to revise the business processes involved with the capture and display of the photographs. This had to be achieved in such a way that the previous 48 hours turnaround of photo processed images provided to agents was equalled or improved upon. Figure 3 shows the new processes in comparison with the old. It can be seen from Figure 3 that additional processes were introduced by the use of digital photos and digital image processing between the stage of the negotiator taking the photograph at a property through to it being passed to a customer. This occurred for two reasons, firstly it is necessary to convert the originals to a digital form by scanning and then to manipulate the image so that it is in a suitable form for display (new processes 3 and 4). This is a specialist job requiring an expensive scanner which can only be used centrally. Secondly it is necessary to associate the image with a particular property and room which is already present on the database (new processes 5 and 6). Since the digital image is scanned and manipulated centrally it is not known at the time of scanning which photos correspond to which room, this association can only be done by the negotiator who took the photograph (process 7). It is thought that with the advent of digital cameras costing less than £500, the new process can be streamlined to remove Stages 1 to 3. At the time of the project, however, this technology was not available at the right price. Although the use of the W A N makes image capture processes more complex this is offset by the images for a property being available from all branches.
Stage 3. Define system requirements--architecture The system architecture was of 10 branches and an area office connected using a WAN. Data was accessed using a simple client/server arrangement with PC clients accessing data from a central database server across the WAN. The system architecture for each branch is shown in
Figure 4. Network requirements. Of the constraints on network performance
5TERPLAN,K (1992)
Communications Network Management 2nd edition, Prentice
Hall, NJ
384
described by Terplan, 5 the main determinant was the transmission capacity. Network contention from different sites, database access times and the performance of the gateway product (router) are not considered here since the bandwidth of the network is the most significant factor affecting performance. Each local area network (LAN) was running an Ethernet network giving a transmission speed of 10 Mbps (megabits per second) which did not restrict image display. The many factor was the choice for W A N transmission. The choices were a standard British
Image retrieval across a wide area network: D J Chaffey
Original process p h o t o g r a p h i c prints
N e w p r o c e s s - digital photographs
Property
1.Take photos of property
Property
I .Take photos of property
Photo processors
2.Photo process negatives to produce prints
Photo processors
2.Photo process negatives
Branch
3.Attach photo to particulars and file
Area office
3.Scan negatives to digital form ! !
4.Use Photoshop to reduce colour depth/resolution
4. Retrieval and display
I
5.Associate image to property/branch Branch
6.Associate image to room
i !
7.Retrieval and display
3 Processes required in the digital based image system to capture, retrieve and display images in comparison with the previous system Figure
Local Printers
i
°c_)sl
~
Router o9
th
~
Dockstation laptop
Figure 4
..........................
Network
Area
Office
Printers
Branchsystem architecture 385
Image retrieval across a wide area network: D
J Chaffey Telecom (BT) ISDN network with a transmission of 64 or 128 Kbps (kilobits per second) or an SMDS network running at 448 Kbps. Further tests were required to select which transmission method was used once the optimal image size had been established (Stage 6). Simple calculations described for Stage 7 were used to compare the volume of the image (in kilobytes) with available transmission capacity. These calculations indicated that for images of the required size a sub 5 second retrieval could best be achieved using 448 Kbps. The use of transmission speeds greater than 64 Kbps required for character based systems represents an additional cost required for these types of system. The gateways used were CISCO 7000 routers.
Stage 4. Define system requirements--software components Server. A relational database management system (RDBMS) was selected to store the customer and property data (including the images) on the area office server. Oracle Workgroup Server version 7.1 was selected on the basis of this being an existing company standard which had been used in similar implementations. The Oracle R D B M S was mounted on a server running Microsoft Windows N T Server version 3.51.
PC clients. Each PC used a combination of Microsoft DOS and Windows for Workgroups version 3.11 plus a TCP-IP adapter to provide the operating system, windowing and network environments. The application software was developed using Gupta SQLWindows version 5.01 Corporate edition. The SQLWindows based application accessed the Oracle database for all SQL queries and was also used for all screen display including images.
Stage 5. Define system requirements--hardware components The hardware components are described here in terms of what was used on the server and client parts of the system to give adequate performance with the software that had been selected.
Server hardware. The server selected was a Compaq P75 Prosignia with 3 Gigabyte Level 5 R A I D magnetic storage media. This housed the Oracle R D B M S running under Microsoft Windows NT.
Client PC monitor selection--image colour depth and resolution. The combination of device supported resolution and colour depth was the determinant of the components of the PC compatible hardware. Device resolution was fixed at 800 × 600 pixels with 256 unique colours displayed on a 17-inch monitor (with the capacity to display up to 65 000 colours if required). This resolution was chosen since it was required that the system be used in the field by negotiators carrying notebook computers. This was the maximum practical combination of resolution and colour depth at the time for notebooks. An IBM Thinkpad 755CX was selected for this purpose. By prototyping screen displays with a device resolution of 640 × 480 pixels and 800 × 600 pixels with different combinations of colour depth or colour resolution (4 bit--16 unique colours; 8 bit--256 colours; and 24 bit--16.7 million colours) it was found that 800 × 600 pixels with 256 colours gave an acceptable quality of image coupled with an uncluttered image display in which there was 386
Image retrieval across a wide area network." D J Chaffey
sufficient screen space to display four properties simultaneously. After ensuring that this combination of resolution and colour depth was suitable to provide the right image quality for the application it was then necessary to determine whether the size of image displayed at 800 x 600 pixels and 256 colours could be transmitted at a sufficient speed given the bandwidth of the network. This is described in Stage 7 where it is shown that a transmission capacity of 448 Kbps was appropriate for this combination of image attributes. It is also shown that combinations of greater resolution, colour depth or image size would have been too slow in retrieval with the available transmission capacities.
Other PC components. Of the PC components the key features affecting performance were processor speed, system memory (RAM) and graphics card. The client PC chosen to run this application was a Compaq Prolinea P90 with a 90 MHz Pentium processor, PCI bus and 24 Mb of RAM. A standard Compaq graphics adapter on the motherboard gave sufficient performance at the resolution used. 24 Mb of RAM was required to run the mapping module of the application but comparative tests showed that 16 Mb of RAM was sufficient for the image display module. The choice of monitor and graphics card did not involve any additional expenditure on what could be considered a standard desktop PC. However the use of 24 Mb of RAM in comparison with the standard 8--16 Mb supplied as standard on PC represents a significant additional cost of several hundred pounds per client which is required by the use of digital images. Stage 6. Implement digital picture acquisition and digital image processing
"HEC'KBERT, e s (1986) Filtering by Repeated Integration Siggraph 86, 315-321 7FOLEY, J D, VAN DAM, A s FEINER, S K AND H U G H E S , J F (1990) Computer Graphics:
Principles and Practice Addison Wesley, Reading, MA 8HALL, R (1989) Illumination and Color in Computer Generated Imagery SpringerVerlag, New York
The photographs taken at the property as described for Stage 2 were processed using normal photographic techniques at a photo processing laboratory. These were then captured in digital form using a Kodak colour scanner operating at 1200 x 1200 dpi (dots per inch) and 24 bit colour (16.7 million unique colours). This high end scanner was available on evaluation and was chosen since it had the option to scan from negatives and offered high quality scan resolution. Scanning from negatives was more rapid than manually positioning each print to be scanned. Scanning each negative took approximately 3 minutes. Once scanned, digital image processing was performed using Adobe Photoshop, the de facto standard for PC and Macintosh based processing. Image transformation consisted of reducing the colour depth from 24 bit colour to 8 bit colour and reducing the size of the image to a resolution consistent with an 800 x 600 pixel resolution monitor which is the equivalent of approximately 72 dpi. This produces an improved quality of image compared to an image scanned at the target colour depth and resolution. Transformation was achieved using standard antiliasing or post-filtering methods provided by Photoshop to sample the existing pattern of pixels and then use an average colour for the transformed image. A survey of the types of image transformation used is given in Heckbert 6 and Foley et al. 7 To use the optimal unique 256 coiours in the transformed version a technique known as gamma correction was applied (see Hall 8 for a detailed description).
Stage 7. Implement data storage and retrieval mechanisms The following options were available as the method of data storage: 387
Image retrieval across a wide area network: D J CharleY
Table 1 Difference in theoretical uncompressed image volumes in kilobytes using different combinations of PC screen resolution and colour depth. Calculations are for the largest image in the system which occupies about 31 per cent of screen area (470 × 320 pixels at 800 × 600 resolution) Device resolution (pixels) 640 x 480 800 × 600 1024 × 768 1600 × 1200
4 bit (16 colours)
8 bit (256 colours)
16 bit (65 000 colours)
24 bit (16.7 million colours)
47.6 74.4 121.9 297.6
95.2 148.8 243.8 595.2
190.5 297.6 487.6 1190.4
285.7 446.4 731.4 1785.6
• To store each image in the Oracle database as a Binary Large Object
(BLOB). • To store each images in the Oracle database as a compressed string (of long raw datatype). • To store the individual images as uncompressed bitmap files. • To store the individual images as compressed files using formats such as .GIF. It was decided to take advantage of the facility to store non alphanumeric data in Oracle as B L O B s or Windows bitmaps stored as compressed strings. This decision was taken since the development of the application would be more rapid than the approach of using flat files for which it would have been necessary to write code for image indexing, retrieval and backup. Through using Oracle, standard SQL could be used to retrieve the images and backup of the images was performed along with other data held in the database. Tests conducted before implementation showed that the use of B L O B s caused a once to twice daily downtime on the database possibly due to an error with the SQL*Net router v2.1 when using TCP-IP. A patch release to SQL*Net from Oracle resolved this problem. Due to the instability the decision was taken that the images be stored on the database in fields of type long. This proved to be an acceptable solution and no further instability was encountered. An indication of the storage volumes required per branch were calculated based on the storage required per best shot property image as given in Table 1. Each branch has of the order of 200 properties at a given time. Given an average of 4 images per property this gives a volume of circa 1.4 Gb for the highest possible combination of colour depth and resolution. For the selected resolution of 800 × 600 with 8 bit colour a more practical volume of 120 Mb per branch before compression. A decision also had to be made regarding the physical location of the images. The choices were: • on the central area server (either in the database or as a file); • on a server in each branch office; • on each individual PC. This was a key design decision which depended primarily on the transmission capabilities of the WAN. From the calculations performed using Tables 1 and 2 as described in the following section it was shown that it would be possible within the two to five seconds required to access images and customer/property data held on the central server
388
Image retrieval across a wide area network: D J Chaffey
Table 2 Differences in image transfer speed in seconds given by different combinations of transmission capacity (kilobits per second) and image co/our depth. The calculations are based on the image sizes from Table 1 for an 800 x 600 resolution Transmission speed (Kbps) 28.8 64 128 448
4 bit (16 colours)
8 bit (256 colours)
16 bit (65 000 colours)
24 bit (16.7 million colours)
20.7 9.3 4.6 1.3
41.3 18.6 9.3 2.6
82.7 37.2 18.6 5.3
124.0 55.8 27.9 7.97
from each branch via the WAN. This was the most cost effective solution since it meant that it was not necessary to maintain a separate database or file server in each branch and to setup replication for when new properties were added to the system. Retrieval of the images was performed by issuing a SQL SELECT FROM statement against the master table which held all property images. The SELECT was then performed on the central database and the image was then transmitted from the server over the Wide Area Network and Local Area Network to the PC client making the request where it was converted from a compressed string to a bitmap and then displayed on screen. Selection o f transmission capacity. To calculate a practical transmission
capacity based on the selected combination of colour depth and resolution Table 2 was used. Table 2 gives theoretical transmission times in seconds assuming 100 per cent of the transmission capacity is available. The calculations are based on image size for a device resolution of 800 x 600 pixels from Table 1. Table 2 shows that for the required retrieval time of 2 to 5 seconds only the 448 Kbps link was appropriate. These theoretical times were improved on due to the image being compressed using a lossless compression method available with Gupta SQLWindows where a bitmap is converted to a compressed string for transmission and storage. This reduces the size of the image to be transmitted to 50-70 per cent of the original depending on the number of repeating pixels. Thus the actual times observed were 50-70 per cent of those in Table 2. To confirm that a 448 Kbps transmission capacity would be required physical tests were also used.
Conclusion It is evident from the review of the decisions required during design and implementation that the introduction of digital images to an information system may increase the complexity, hardware requirements and hence the cost of the system. Table 3 summarises the decisions required during the project. The associated additional costs were justified since graphical systems incorporating digital images provide an improved quality application which is easier to understand by the customer and aids differentiation from the competition. The complexity introduced implies good planning is required to undertake the prototyping and system benchmarks required to identify suitable key image attributes which 389
Image retrieval across a wide area network: D J Chaffey
Table 3
Summary of key factors determining image capture, storage and retrieval
Decision
Option chosen
Option 2
Option 3
1. Type of camera
Standard film
Digital
2. Type of scanner
Scan from negatives
Scan from print
3. Scanning resolution/colour depth
Maximum available
That appropriate for screen output device ie c 60 dpi and 256 colours
Between options 1 to3
4. Method of image storage
Database compressed string
Database
Flat file
5. Location of image storage
Central server
Server in each branch
Each client PC
6. Screen resolution
800 x 600 pixels
640 x 480 pixels
1024 x 768 pixels
7. Colour depth
8 bit (256 colours)
4 bit (16 colours)
16 or 24 bit (to 16.7 million colours)
8. Type of graphics card to support chosen colour depth and resolution
Support for 16 bit (65 000 colours at 800 x 600 pixels)
Support for 8 bit (256 colours at 800 x 600 pixels)
Support for 24 bit (16.7 million colours at 800 x 600 pixels)
9. Network transmission
SMDS 448 Kbps
ISDN 64 Kbps
ISDN 128 Kbps
10. Network protocol
TCP-IP 32 bit
IPX/SPX
BLOB
Reason Technology for 2 unavailable with correct cost performance Higher quality images, more rapid throughput from using negatives Better quality obtained by scanning at highest available resolution number of colours and then reducing using Photoshop Could use RDBMS facilities~least coding and best stability Least complex option--no replication required Best compromise between storage requirements and image speed and quality. Maximum resolution of laptops used Best compromise between storage requirements and image speed and quality. Maximum resolution of laptops used Was required to remove 'palette flashes' in application although only 256 unique colours used. Used Compaq card installed on rnotherboard Needed to achieve retrieval in 2 to 5 seconds Chosen for simplicity of use across WAN
provide a useable system for the selected hardware and network bandwidth. The key attributes are image quality, size, number of colours, screen resolution and compression method. 390