Lith Printing Simulation Paul Nicholas Whysall PRINTING SIMULATION.pdf · 1.2.1 Lith printing is difficult? 1 1.2.2 Time consuming 2 1.2.3 Expensive Process 2 1.2.4 “Pepper Fogging”

Lith Printing Simulation Paul Nicholas Whysall

Lith Printing Simulation

Author: Paul Nicholas Whysall

Date: 07/05/2002

Supervisor: Dr. Guy Brown

This report is submitted in partial fulfilment of the requirement for the degree of Bachelor of Engineering with Honours in Software Engineering by Paul Nicholas Whysall.

I


Declaration All sentences or passages quoted in this dissertation from other people's work have been specifically acknowledged by clear cross-referencing to author, work and page(s). Any illustrations which are not the work of the author of this dissertation have been used with the explicit permission of the originator and are specifically acknowledged. I understand that failure to do this amounts to plagiarism and will be considered grounds for failure in this dissertation and the degree examination as a whole. Name : Paul Nicholas Whysall Signature : Date :

II


Abstract Lith Printing is a photographic technique that overexposes negatives onto special purpose paper. Lith prints are becoming increasing popular because their visual appearance is considered to be:

“Beautiful, different and personal. Its flexibility offers almost limitless ways of interpreting a negative” [TR98].

But, there are various problems associated with lith printing. It is difficult to duplicate results, materials are expensive, the process is time consuming, and unwanted chemical reactions can affect print quality. The purpose of this project is to design a computer simulation that will teach users the principles of photographic development and the techniques required to create a lith print, also to provide a solution to the problems defined above. The emulation of the lith process will need to incorporate an interactive model representing the darkroom environment (such as the photographic equipment, chemical solutions, etc.) and an algorithm that is capable of generating a realistic lith image. The implementation of the Lith Printing Simulation will use the principles of Object Oriented Programming, Usability Engineering, Human-Computer Interaction and 2D image processing techniques, amongst other concepts, to produce the final application. To determine the performance of the simulation, and ultimately its potential for teaching the aspects of lith printing, the product will be subjected to extensive user testing throughout the software development process.

III


Acknowledgements I would like to thank: • My parents Albert and Janet, and my brother Rob. • My supervisor Guy Brown for valuable suggestions and advice throughout the

development of the project. • All my friends who contributed, and provided feedback, during the analysis and testing

phases of the project.

IV


Contents 1. Introduction 1

1.1 Description 1 1.2 Objectives 1

1.2.1 Lith printing is difficult? 1 1.2.2 Time consuming 2 1.2.3 Expensive Process 2 1.2.4 “Pepper Fogging” 2

2. Literature Review 3

2.1 The Darkroom and Apparatus 3 2.1.1 The Enlarger 3 2.1.2 Photographic Film and the Negative 3 2.1.3 Enlarger Lens 4 2.1.4 Image Enlargement 4 2.1.5 Image Focus 4 2.1.6 Aperture and f-numbers 4

2.2 The Lith Print 5 2.2.1 Lith Printing Paper 5 2.2.2 Print Contrast 5 2.2.3 Exposure Time 6 2.2.4 Exposure Control 6 2.2.5 Processing/Development Chemicals 6 2.2.6 Processing/Development Time and “Snatch Point” 6 2.2.7 Colour Control - Toning 7

2.3 Computer Simulations 7 2.4 Usability Engineering 7 2.5 Iterative Design and Prototyping 9 2.6 Visualisation and HCI 9 2.7 Object Oriented Programming and Design 10

2.7.1 The Class Diagram 10 2.7.2 The Sequence Diagram 11 2.7.3 Combining Usability and Object Oriented Design 12

2.8 The Java Programming Language 13 2.9 Java 2D Graphics 13 2.10 Image Processing 14 2.11 Competitive Analysis 15

3. Analysis 16

3.1 User Analysis 16 3.1.1 User Observation 16 3.1.2 Task Analysis 16

3.2 Contextual Enquiry 17 3.2.1 Making the lith print 17

3.2.1.1 Pre-exposure 17 3.2.1.2 Exposure 17 3.2.1.3 Development 17 3.2.1.4 Post-development 18

V


3.3 Use Case Analysis 18 3.4 Identification of Tasks 19 3.5 Usability Measurements 20

4. Design 22

4.1 Object Oriented Design 22 4.1.1 Design Patterns 22

4.2 User Interface Design 24 4.2.1 Swing and Event Listeners 25 4.2.2 Layout Management 25 4.2.3 Interactive Components 26

4.2.3.1 Easel 26 4.2.3.2 Enlarger 26 4.2.3.3 Focus 27 4.2.3.4 Aperture 27 4.2.3.5 The “Chain of Responsibility” 28 4.2.3.6 Exposure Control 28 4.2.3.7 Timer 29 4.2.3.8 Input Validation 30 4.2.3.9 Loading and saving the Lith Print 30

4.3 Testing Strategy 30 4.3.1 User Interface Design (UID) Patterns for Usability Testing 31 4.3.2 Traditional Testing Methods 32

5. Implementation 32

5.1 Image Processing during Projection 32 5.1.1 Obtaining the Image 32 5.1.2 Creating the Negated Image 32 5.1.3 Image Magnification 33 5.1.4 Image Focus 33 5.1.5 Aperture and Light Intensity 35 5.1.6 Saving the Buffered Image 36

5.2 Image Processing during Exposure 36 5.2.1 Multithreading 36 5.2.2 Implementing Exposure using Principles of Animation 37 5.2.3 The Exposure Algorithm 38 5.2.4 Dodging and Burning during Exposure 39 5.2.5 The “Flashing” Exposure Tool 40

5.3 Image Processing during Development 40 5.3.1 Implementing development using the Exposure Technique 40

5.4 The Lith Algorithm 40 5.4.1 Shadows 40 5.4.2 The Grain Effect - “Pepper Fogging” 42 5.4.3 Mid-tones and Highlights 43

5.4.3.1 Multicoloured mid-tones 43 5.4.3.2 Combining Highlights, Mid-tones and Shadows 44

5.5 Contrast Control 46 6. Testing 47

6.1 Usability Testing 47

VI


6.1.1 Synchronisation Problems during Real Time Exposure 47 6.1.2 “Off-line” Exposure processing 48 6.1.3 Rate of Development 49 6.1.4 The Lith Printing “on-line” Help Facilities 49

6.1.4.1 The Lith Print Tutorial 50 6.1.4.2 Tutorial Results 50

6.2 Specification (“Black Box”) Testing 53 6.3 Implementation (“White Box”) Testing 54

7. Evaluation 55

7.1 Examination of original Objective 55 7.2 Combining Contrast Control and Solution Intensity 55 7.3 Suggestions for Improvement of Simulation 56

7.3.1 Tracing movement of paper through the development process 56 7.3.2 Refinement of the Exposure Class 56 7.3.3 Advanced Exposure Tool Features 57 7.3.4 Toning and “Pepper Fogging” 57 7.3.5 Applet Version of Simulation 57

8. Conclusion 58 9. References 59 The Lith Printing Simulation program, source code, help files, example image files, etc. are contained on the CD-ROM attached to the back of this document. The photographic images used throughout this document and applied to the Lith Printing Simulation are taken from [MGI].

VII


1. Introduction 1.1 Description Lith Printing is the process of heavily over-exposing a negative onto special lith paper (or standard black and white paper), partially developing the paper in a very dilute lith developer, and then quickly removing (“snatching”) the paper from the solution. This process is described as an “infectious development,” [TR98] producing a print that has special characteristics which cannot be achieved via conventional photographic techniques and darkroom procedures. The characteristics of the print are typically black shadows, multicoloured mid-tones, and white highlights. For a particular print, there are certain factors that will influence the contrast and the colour scheme of the mid-tones; these factors can be categorised as either material or technical. The range of colours usually consists of different shades of the following: red, pink, peach, olive and caramel. The results are characteristically described as the production of an image with “hard shadows and soft highlights” [TR98].

Figure 1.1: Examples of lith prints by Marco Pauck [MP01] Material factors: 1. Paper type: how the base type, emulsion contrast, and other surface characteristics of the

paper will effect the desired result. 2. Toners: chemicals used to control and change the natural colours of the print. 3. Chemicals: the lith developer and other solutions, such as the stop bath, fixer, wash, etc. Technical factors: 1. The exposure time. 2. The development time and “snatch point.” 3. Exposure and contrast control: E.g. burning, dodging, and flashing. All of the above terminologies and techniques are described in more detail in the Literature Review section. 1.2 Objectives The purpose of this project is to develop an algorithm to produce the visual lith effect and design a simulation that will emulate the various darkroom procedures that are used to create the lith print. This application will be aimed at the amateur photographer, so only the basic darkroom equipment and peripherals that are essential to the process will be considered. There are also various problems associated with lith printing that this project will aim to resolve: 1.2.1 Lith printing is difficult? Lith printing is constantly referred to as a difficult technique to master, although this statement is usually misinterpreted as meaning that the process as a whole is complicated. In fact, the process is not vastly dissimilar to that of conventional printing, the only variation being the

1


extended exposure and development times; the major problem is controlling the results that are obtained. It is notoriously difficult to produce duplicate lith prints from the same negative, or maintain a consistency with a particular style when developing prints from a range of different negatives. Obviously, it is difficult to maintain consistency with normal black and white printing, so the control aspect of lith printing is even more challenging for an amateur photographer. But, there is an advantage to this apparent lack of control, in that every print that is made will posses unique properties that cannot be emulated or reproduced, and are therefore individualistic. Hence, both of these considerations must be incorporated into the simulation, a requirement for control and the need to be expressive. The computerised model can easily interpret the aspect of control; the same exposure and development times will always yield the same results as the variables are fixed. Whereas varying these times and introducing exposure and contrast controls will insure that results are unique. If the user is able to introduce different constraints into the emulation and experiment with different settings, not only will it enable them to better understand the printing process, but prepare them for the real experience of lith printing which is regarded as an experimental, trial and error technique. 1.2.2 Time consuming As already mentioned lith printing is dependent upon extended exposure and development times. In the most extreme cases, exposure times can be several minutes and development times up-to half an hour. The reason development time is so extensive is that the paper does not react instantaneously, tones only begin to appear steadily revealing a faint image, and then increase at an exponential rate resulting in an increasingly darker image. The simulation will be designed in order to give near instant results for each print. It is not essential to show the exposure of the image, as there is no apparent visual change on the surface of the paper. Only the development process requires visualisation, as the user must determine when the paper is to be “snatched” from the development tray. Therefore the appearance of the forming image must be animated in real time, and the rate at which the image is developed must emulate the actual process, i.e. ranging from gradual to exponential formation. But, the formation in the simulation must not been restricted by the time scale problems of the real process, e.g. the speed of development can be increased by a particular factor. 1.2.3 Expensive Process An essential material for lith printing is the lith printing paper. In order to achieve a wide variation of prints, different papers with contrasting properties are required. These papers are expensive and in some cases difficult to obtain; also, due to the trial and error approach of lith printing there is a large proportion of wasted materials. Obviously, the nature of a simulation insures that there is no cost involved and the user can experiment without incurring the expenses that are attributed to the actual process. 1.2.4 “Pepper Fogging” Pepper fogging is an unwanted area of density (black spots or dotted areas) that is an unfortunate by-product of lith printing as a result of over-exposure. Again, the nature of the simulation will insure the print will not be afflicted with such problems. Although, fogging is sometimes used to create photographic effects, therefore an additional requirement for the simulation is to introduce fogging, via the inclusion of random “noise” to create a dotted effect on the image.

2


2. Literature Review 2.1 The Darkroom and Apparatus The basic darkroom layout requires the following equipment and materials in order to produce a lith print: enlarger, easel, developing trays, developing solutions (print developer, stop bath, fixer), printing paper, exposure tools, and timer. Each component of the development process is described in the sections below. 2.1.1 The Enlarger The enlarger (Figure 2.1) is the most essential part of the darkroom printing facilities, and is divided into various sub-components. A lamp is situated at the top of the enlarger head, the purpose of this being to illuminate the negative that will be used to produce the print. The negative carrier holds the negative in position beneath the lamp. Below the negative carrier is the enlarger lens, an adjustable component that projects an enlargement of the negative image onto the easel. The printing paper is fixed in position at the base of the enlarger by the easel. A timer is connected to the enlarger that controls exposure times. The enlarger head may also contain a selection of coloured filters, to produce different print effects, but these are not required to for the purposes of lith printing.

Figure 2.1: Enlarger [AH97] There are three properties of the enlarger device that determine the appearance of the image that is projected onto the paper: 1. The enlarger head can be moved along a vertically column, altering the height between the

lens and the printing paper, this determines the magnification of the projected image. 2. The distance between the negative and the enlarger lens determines the focus of the image.

For each adjustment in image size, there must be a subsequent adjustment of the lens in order to re-focus the image.

3. Adjustment of lens aperture, which controls the light intensity of the projected image.

2.1.2 Photographic Film and the Negative The most widely used film and negative formats are based on 35mm photography, which is popular amongst amateur photographers. Hence, the negative size used in the simulation will be of the 35mm variety which produce negatives that are 24mm x 36mm in size.

3


2.1.3 Enlarger Lens The purpose of the lens is to refract the light and converge it to a point that forms an image on surface of the printing paper. The selection of the enlarger lens must complement the selection of the negative format. The lenses are classified by their focal length; this is the distance from the lens to the perfectly focused projected image of an object. The Jessops Darkroom Book [TS00] recommends that the lenses required for the 35mm negative format have a focal length of 50mm in order to achieve the best focusing results. Hence, this will be the measurement used in the simulation. 2.1.4 Image Enlargement The projected image size is dependent upon the distance between the lens and the printing paper. Moving the enlarger head up the vertical column increases the image size, and moving it down decreases the image size. The average maximum height for a 35mm enlarger, indicated in The Jessops Darkroom Book [TS00], is 70cm. The size of the enlarged image can be calculated by the magnification equation as specified by Michael Landford in Basic Photography [ML93]:

M = (LP / FL) - 1

Where M = Magnification, LP = Lens to Paper distance, and FL = Focal Length. For example, the maximum magnification of the simulation enlarger, and the maximum size of the projected image, can therefore be deduced:

Mmax = (0.7m / 0.05m) - 1 = 13 Negative size: 24mm x 36mm 13x magnification: 312mm x 468mm

The magnification calculation, and the constraints described above, will be used in the implementation of the simulation. 2.1.5 Image Focus The focus of the image is dependent upon the distance between the negative and the lens. Mainly estimation and good judgement achieve the desired focusing of the lens, but the negative to lens distance for perfect focus can be measured via the focus equation [ML93], this calculation will also be used in the implementation of the simulation:

F = LP / M Where F = Focus (negative to lens distance), LP = Lens to Paper distance, and M = Magnification. For example, using the maximum magnification calculated in section 2.1.4, the focus distance for Mmax can be measured:

Fmax = (0.7 / 13) = 54mm 2.1.6 Aperture and f-numbers An essential component of the enlarger lens is the iris, a device that is constructed from a number of overlapping blades, which determines the size of the aperture. The aperture can be altered from full lens diameter to a specified maximum lens coverage at the centre of the lens. Aperture represents the luminous intensity or brightness of the projected image, and is defined by a series of consecutive fixed “stops” which correspond to a particular value known as the f-

4


number. As the value of the f-number increases the aperture decreases and subsequently the brightness of the projected image also decreases. The enlarger lens on a typical 35mm enlarger conforms to the following range of f-numbers: f/2, f/2.8, f/4, f/5.6, f/8, f/11, f/16, and f/22. Each consecutive stop halves the intensity of the light passing through the lens. Aperture also has a direct influence on the exposure time of the image. This can be explained by considering the relationship between light intensity and the lens to paper distance; these two variables define the inverse square law. The law states that “when a surface is illuminated by a source of light, the intensity of the light is inversely proportional to the square of its distance from the light source” [ML93]. An example of this would be if the lens to paper distance were doubled, then the paper would only receive one-quarter of the original illumination as the light is covering four times the surface area. To compensate for the decreased intensity, exposure time would have to be increased by a factor of four. Alternatively, the aperture can be stopped-up two settings, as doubling the lens diameter increases light coverage by a factor of four, this insures that exposure times remain consistent. 2.2 The Lith Print This section describes the general processes, techniques, and materials involved in the development of a lith print. 2.2.1 Lith Printing Paper Although it is not plausible to simulate certain properties of the paper, for example, a textured surface finish, it will be possible to emulate how the paper reacts during the exposure and development process. The Master Photographers Lith Printing Course [TR98] provides a colour characteristic guide that describes the change in appearance and colour of the print during development. For example, when the paper is in the fixer solution, the colours change from light purple to yellow. The other paper characteristic, print contrast, is detailed in the section below. 2.2.2 Print Contrast Photographic papers are coated with crystals of silver halide which are sensitive to light, when the paper surface is exposed to light a chemical reaction occurs. This reaction causes the silver deposits to group together forming contrasting dark and light tones, which produces the image. The contrast of the print is the degree of difference between the dark and light tones of the image. The contrast is determined mainly by considering the relationship between exposure and development. Reducing exposure and extending development increases contrast, whereas extending exposure and reducing development decreases contrast.

Figure 2.2: The contrast Characteristic Curve

5


The varying contrasts of the paper can be represented as a Characteristic Curve (see Figure 2.2). The graph plots image intensity (relative log10 of exposure) against tone density (log10 of opacity), relating contrast as directly proportional to exposure time. The graph is divided into three segments: (a) the “toe” represents underexposure, (b) the straight line represents “ideal” exposure times, and (c) the “shoulder” represents overexposure. Best results, in terms of lith printing, are achieved using the higher parts of the straight line, where shadow contrast is greater than highlight contrast, causing all grey tones to be drastically darkened. 2.2.3 Exposure Time Exposure time is usually determined by producing trial test strips, i.e. exposing different areas of the paper at different intervals. This will be a difficult technique to simulate in the application, so the user will be expected to experiment with the enlarger options and timer settings to achieve adequate exposure times. 2.2.4 Exposure Control Exposure control for lith printing corresponds to conventional exposure control techniques. These controls are used to alter the contrast of specific areas of the print, traditionally by using an object to intercept light from the enlarger head, preventing or intensifying exposure by casting shadows onto areas of the printing paper. There are three distinct exposure controls: 1. Burning tool - increases the exposure, darkening a specific area of the print. 2. Dodging tool - reduces the exposure, lightening a specific area of the print. 3. Flashing - provides additional exposure before and/or after the negative exposure, by

projecting pure light onto the paper (i.e. removing the negative). The penumbra effect is the gradual change in intensity from shadow to light, and is a direct product of burning/dodging, which forms a range of contrasts across the surface of the print. This effect, along with the exposure tools, will be built into the simulation. 2.2.5 Processing/Development Chemicals The minimum solutions required for a successful print are described below, each of these processing stages will be included in the simulation as they all have varying effects on the resultant lith print: 1. The lith developer - this solution, which is diluted by a particular volume of water,

gradually forms the image as it reacts with the printing paper. A useful requirement would be to alter the dilution variable, so that the user can experiment with different solution concentrations and development times.

2. The stop bath - a solution that acts as a stopping agent. This is an essential process in lith printing because at this stage the development of the dark tones will be accelerating rapidly and, to achieve the desired lith effect, must be halted immediately.

3. The fixer - removes excess chemicals from the paper. For the purpose of lith printing, fixing time must be relatively short, as extensive bleaching in the solution will result in the loss of lighter tones and contrasts, increasing the brightness of the image in general.

2.2.6 Processing/Development Time and “Snatch Point” There is no exact time to snatch the print from the developing tray. As with exposure time in section 2.2.3, the user will be expected to experiment with the snatch times during development to achieve the best results. This introduces an element of trial and error into the process. For example, if the print is under-exposed the user will expect to see poor highlights, if the print is over-developed then darker tones will consume the print. But, the aim of the

6


simulation is to obtain a realistic image resulting in the “classical black/colour/white split and the typical hard in the shadows/soft in the highlight qualities of a lith print” [TR98]. 2.2.7 Colour Control - Toning Toning is a post-development process that could also be incorporated into the simulation. Toners are used to change the colour of the print, of which there are two distinct types typically associated with lith printing: 1. Gold - which produces different shades of purples and blues. 2. Selenium - produces a multicoloured effect. 2.3 Computer Simulations Simulation software is typically used for educational or industrial purposes as part of a Computer-Aided Leaning (CAL) package, where a program is used to assist the user in learning a particular subject area, in this case the process of Lith Printing. The problem of categorising the Lith Printing Simulation as a CAL application is that this assumes that the program will be used in conjunction with expert tuition. CAL is described as an “integrative technology” [AO01] that is used to enhance the learning process of a particular subject area by combining it with other resources. But, one of the objectives of the Lith Printing Simulation will be that it can be used by anyone, regardless of whether they have access to expert supervision or photographic resources, who is interested in lith printing. Therefore, the simulation is more suited towards Computer-Based Learning (CBL), as it is used as the primary source of knowledge and learning expertise, essentially replacing a human expert. This is not necessarily a disadvantage because it enables the user to experiment with the simulation and provides direct access to the subject material, so the user can define a learning curve that is best suited for themselves. This approach contrasts with the intervention from experts, whose communication can be more one sided, providing less opportunity for the user to express their own opinion or experiment with the software [AO01]. But, it is important that there is some form of assessment, one of the main advantages of having an expert available is that they provide feedback and advice, so that the user is able to judge their own performance. A possible approach to resolve this limitation is to include a detailed tutorial and help system or an evaluation option (such as an on-line questionnaire) that the user can access in order to determine their progress, essentially providing a form of self-assessment. Therefore, the simulation can provide an intermediate between the CAL and CBL approaches, inheriting the advantages of both. Ultimately, CBL insures that the users of the simulation can learn the lith printing process without having to be in a dark room environment and the process can be repeated as many times as required without wasting photographic resources. Finally, the simulation can eliminate the disadvantages of the real lith process, as indicated in the introduction section, such as “pepper fogging.” 2.4 Usability Engineering Usability Engineering is a software development model that places emphasis on the human-computer interaction (HCI) that exists between the user and the software interface. The principles of usability engineering is concerned with whether a particular system meets and satisfies the requirements of the users, i.e. can the system be used to achieve a desired goal? In this case, the production of lith prints. Usability is determined by measuring various factors of

7


the user interface. These factors are outlined by Jakob Nielsen in the book Usability Engineering [JN93]: 1. Learnability - determines how easy the system is to use, this could be measured by timing

how long it takes the user to complete a task. For example, the time taken to position and focus the projected image or the time taken to expose and develop the lith prints. Each new attempt at the task can be compared with the previous attempt, this will give an indication of how satisfactory the results are while also considering the users progress.

2. Efficiency - The efficiency can be calculated by repeating the learnability factor and then determining the percentage difference in time taken and quality of results. This will deduce if the user is improving at producing better quality lith prints and subsequently learning how to use the interface, or if the interface is proving problematic and hence requiring redevelopment.

3. Memorability - By introducing the user back to the system after a period of time, the first two factors can be repeated, and the new results compared with the original results. If the new results are equal to or exceed the original results, then it can be deduced that the interface is memorable. Hence the system is not over-complicated, and requires the minimum of efforts to begin using it efficiently again.

4. Error Detection - There should be few minor errors, no catastrophic errors, and the user should be able to recover, or be corrected, from performing an illegal operation.

5. Satisfactory Performance - The purpose of the simulation is for the user to learn the lith printing techniques, and also to derive enjoyment from using the system. Therefore the emphasis of the interface design should be concerned with the interaction and teaching qualities of the system, and also the quality of the final result. The performance will be determined by asking the users to evaluate the system, i.e. via questionnaire, observation or verbal feedback.

Because these attributes can occasionally conflict, for example learnability and efficiency can have a negative effect on each other [FJWC01] as low learnability results in low efficiency, it is therefore necessary to subdivide the attributes into additional variables that are more specific to the aspect of usability in question. To rectify the problem above, a possible solution is to introduce key combinations (accelerators) to perform important tasks and then measure both lernability and efficiency for beginner and advanced users. This insures there is a range of results so the attributes can be considered individually to avoid conflicts, but can still be compared if required. There may also be a requirement for “usability trade-offs” [JN93]. Although the simulation will be designed specifically for the amateur photographer, it is conceivable that a more advanced user may use it. Hence, it may be appropriate to build two different learning curves into the system. For example an amateur setting could exclude the exposure (dodging, burning, etc.) and toning controls, whereas the advanced setting would include these features, and it would be to the discretion of the user as to which level they prefer. Another consideration is the “evolution” of the user; i.e. the user may advance from novice to expert, either using the simulation or with the actual lith printing process. Other Usability Engineering methods that will be deployed are: • User Analysis - Collecting information from the users of the proposed system to determine

how they will interact and relate with the user interface. Possible approaches include questionnaires, interviews, focus groups, observation, etc.

• Task Analysis - Studying the current method of approaching a task and the resultant goals, then identifying the weaknesses and consider improvements.

• Functional Analysis - Observing the underlying “functional” operations of a particular task and determining logical errors that could arise.

8


• Usability Measurements - evaluating the goals, which the users are to attain via a particular task, in advance of the design and implementation of the application. The evaluation measurements are based on the five usability attributes defined above or sub-attributes that are important to the goal in question, for example:

1. The time it takes the user to complete a single task or a collection of tasks and then comparing these with best and worst case scenarios.

2. The number of errors the user makes during each task. 3. The number of system features that the user can remember without referring to the

documentation or help files. • Scenarios - A scenario is an encapsulated description of a single user task, which will

prove essential to the design of the simulation. These descriptions can be used to detect problems that affect the usability of the program by considering different circumstances and outcomes to a specific task.

The methods described above will be used during the analysis phase of the usability engineering development cycle to gather user information and drive the design and implementation of the Lith Printing Simulation. 2.5 Iterative Design and Prototyping All the requirements for the simulation cannot be completely specified from the beginning of the usability life cycle [DFAB98]. To ensure that the various components of the system have been fully considered and are correct, they must be continually re-built and tested on the user until a satisfactory design is decided upon with the majority of the problems eliminated. Each of the iterations will result in a new prototype that represents a limited part of the complete system (either in terms of functionality or interface design). A more traditional approach to prototyping involves sketching or producing paper mock-ups of the proposed user interface and presenting them to the users for evaluation. Any problems with the simulation design will be resolved using heuristic evaluation and applying the factors described in section 2.4, considering the results, and then making the necessary alterations. Examples of usability heuristics are: • Use simple and natural dialogue - provide sufficient details relevant to the current task

using a minimal amount of information. • Speak the users language - for example, it would be inappropriate to present the user with

system error messages, during the use of the simulation, if they perform an illegal operation.

• Provide consistency - by insuring that the interface has a consistent design and operational performance, the user will be able to learn the features of the simulation easily and quickly.

• Provide help facilities and documentation. Heuristic evaluation is part of the usability testing process, which requires test participants to perform a series of test cases (the test case design is based on the results obtained from User Analysis and Task Analysis). The users are observed and the results are analysed and applied to the next iterative stage of the Usability Engineering process. 2.6 Visualisation and HCI Visualisation is the process of using graphical techniques to present information to the user. Although Visualisation is more suited to software applications that manipulate large amounts

9


of data, the approach can be used for less complex programs, by using the principles of HCI to support the interactive visualisation of abstract data [JL96]. For example, by visualising photographic equipment such as the Enlarger, the user can look at how the data is represented (the enlarger head, lens, aperture, etc.) and can also manipulate the data through exploration (changing the magnification, focus, brightness, etc.) to achieve a particular goal. This provides a more meaningful perception of the data available to the user who is able to interpret the meaning of the data and better understand how it is applied and the purpose it serves in terms of creating a lith print. 2.7 Object Oriented Programming and Design OOP is a programming technique that considers data as objects, and the interfaces that these objects will be applied to. Each object relates to a specific class that describes the tasks to be performed and the data contained by each instance of the class, and has three main identifiable characteristics: 1. Behaviour - this defines the operations that can be applied to the object. 2. State - the current configuration of the object that may change over time, indicating how

the object reacts when the operations are applied and the internal data is modified. 3. Identity - the method of uniquely identifying objects which contain similar behaviour and

state, i.e. instances of the same class. Objects encapsulate their state and behaviour internally, which hides the implementation form other objects. Therefore one object can never directly change the state of another object, all activities are restricted by method calls, and these methods are described in the implementation of the class. The darkroom model consists of various objects, for example the enlarger, which can subsequently be divided into further object states, for example the enlarger head, focus and aperture. The movement of the enlarger head relates to the behaviour of the object, and the subsequent change in height relates to the change in state of the object. As described above, objects can communicate via method calls, this suggests that relationships exist between different class. These “relations” fall into different categories, for example: 1. Inheritance - A class will have its own methods defined, but can extend its functionality

and operations by inheriting methods from other classes. 2. Dependency - A class will “use” another class that it depends upon, in order to perform a

certain task. 3. Aggregation - A class will contain an instance of another class. The Unified Modelling Language (UML) is a system development tool that uses graphical elements, and a series of rules for combining these elements, in order to construct diagrams. The purpose of the diagrams are to present a model of the system describing how it will work, but not how it will be implemented. The diagrammatic notations and rules are explained in The Unified Modelling Language User Guide [BRJ99], which also describes the various types of diagrams that can be used in order to assist Object Oriented analysis and design. The diagrams that will be used in conjunction with this project are detailed below: 2.7.1 The Class Diagram This diagram essentially captures the attributes (variables) and behaviour (method declarations) of each class inside a box structure. The relationships between classes (outlined above) are represented as a series of arrows, associating a class with one or many other classes.

10


As already stated, an object is an instance of a class, this is expressed in the diagrams via multiplicity characteristics. These are numerical values that define the number of objects from one class that relate with a single object in an associated class. The diagram in Figure 2.3 shows a fragment of the class overview for the enlarger; an example of multiplicity is the relationship between the ExposureTool class and Easel class, showing a “many-to-one” relationship, i.e. many exposure tools can be placed on a single easel.

Figure 2.3: Class Diagram 2.7.2 The Sequence Diagram This diagram shows the interaction between objects over a particular time interval (as opposed to the static information represented by the class diagrams). The diagram characterises the sequence of object state change that occurs during a particular process of the system, and captures the interaction and communication between the objects by using arrows to represent method calls.

Figure 2.4: Sequence Diagram The sequence diagram in Figure 2.4 shows the method calls involved between the objects when the user moves the enlarger head to change the magnification of the image. Objects are defined horizontally, and the objects lifeline and activation are defined via vertical lines and

11


rectangular boxes, respectively. The changes in state over time are indicated by progressive method calls as the vertical lines are traversed further down the diagram. The accumulation of these two diagrams provides details relating to object instance, state, behaviour, and activity. Therefore it seem appropriate not to use the remaining diagrams that expand on these details, such as Collaboration, State and Activity diagrams, etc., unless it is absolutely necessary to investigate a particular design aspect further. The class and sequence diagrams are also useful as they complement each other. For example after defining a class, constructing a sequence diagram will highlight missing attributes and method declarations and the original class diagram can subsequently be amended (this process can be repeated until a satisfactory result is obtained). Finally, using a minimal number of different UML diagrams will simplify the design process. 2.7.3 Combining Usability and Object Oriented Design As indicated in section 2.4, the Usability Engineering principles will be deployed throughout the development life cycle of the simulation. The UML method of object oriented design belongs to a more traditional and structured style of software development. But, because of the iterative nature of Usability Engineering, where-by there is continual evaluation and reconfiguration of the design, combining this with a traditional life cycle approach “makes introducing usability techniques fairly impossible” [FJWC01]. Recently there has been progress made in combining usability processes into traditional software engineering models, with most of the integration occurring at the analysis and design level. For example, in the paper “Incorporating Usability into an Object Oriented Development Process” [XF01] Xavier Ferre distinguishes parallels between usability and traditional methods, and suggests dividing usability into analysis, design, maintenance and testing criteria so that it can be substituted into a traditional model. One approach suggested to achieve this is to combine Usability task analysis and UML’s use case diagram during the analysis phase because both are used to determine how the user interacts with the software. The former defines how the user interface is designed and the latter defines how the functionality of the system is implemented.

Figure 2.5: Use Case Diagram The use case diagram, shown in Figure 2.5, indicates the photographers’ perspective of a task in the dark room environment. In this instance, the photographer (or the “actor” in UML notation) initiates the use case to adjust the projected image by manipulating the enlarger controls. There are two primary relationships between the use cases:

12


1. Inclusion - enables the reuse of an existing use case internal to another use case. In the example, the adjustment the enlarger “includes” the adjustment of the enlarger controls (such as the enlarger head height, focus control, etc.).

2. Extension - enables the creation of a new use case by including existing use cases. In the example, the user observing the appearance of the projected image can result in the alteration of the enlarger controls. This process “extends” the “alter controls” step of the Adjust Enlarger use case.

This combined approach to development will be used throughout the design of the Lith Printing simulation. The Analysis and Design sections provide more details concerning the principles and techniques deployed. 2.8 The Java Programming Language The simulation will be implemented in Java, an Object Oriented language that stores code within classes and considers data as objects. Hence, the program can be developed using the principles and design techniques described in the previous section. The language also has numerous pre-defined package libraries, which contain classes useful for interface design and image processing. 1. The Abstract Windows Toolkit (AWT) - although its Graphical User Interface (GUI)

components have been superseded by the Swing interface (see below), the AWT still contains useful elements such as event listeners. These are interfaces components that respond to user interactions within the GUI, for example clicking a button with the mouse pointer, or entering data into text fields.

2. Swing - this is a user interface library that contains a vast number of advanced GUI features, such as scrollbars, fixed and floating menus, text fields, internal frames, tables, etc. But, most importantly it provides a “consistent user experience and visual appearance” [HC01] across different platforms. The program will be highly portable between several mediums, for example across different operating systems and the Internet.

3. Applets - converting the simulation to an applet application will enable the program to be embedded in a web page and run over the Internet.

Both AWT and Swing are part of GUI toolkit, the Java Foundation Classes (JFC), which also contains the most vital component in terms of simulating the lith printing technique, the Java 2D Application Programming Interface (2D API). 2.9 Java 2D Graphics The 2D API contains a library of classes that can be used to create and manipulate graphics within the GUI environment. For example transformations (translation, rotation, scaling, etc.), compositing (adding graphics to an existing image), and control over text, colour, printing, etc. The image processing techniques and 2D classes used in the simulation are described in detail in the Implementation section. The internal representation of an image is defined as a rectangular array of pixels. The width and height of the image determine the number of pixels in the array. Each pixel has a series of numerical values that represents its colour, and co-ordinate (x and y) values that indicate its position within the image. The 2D API contains the BufferedImage class that provides control over the pixels of an image and allows direct access via the Raster interface, which retrieves the specified pixels of a particular image. Conversely, the WritableRaster class (a sub-class of the Raster interface)

13


allows direct manipulation and modification of Raster pixel data. The buffered image also specifies the colour space of the image via the ColorModel class. The standard colour space is ARGB, which describes each pixel by four numerical values representing red, green, blue and alpha (the pixel transparency). Altering these values, which range between 0 and 255 for the standard 8-bit component (28 = 256), can change the colour of each pixel. A consideration, which has been dismissed, was to use the Java Advanced Imaging (JAI) API. This is an additional API that accompanies the standard base classes of the Java platform, and builds on the existing 2D classes resulting in more advanced features. Although this package would probably be more appropriate than the 2D API in terms of its graphical capabilities, there are numerous drawbacks to using it during implementation: 1. There is a lack of support for the platform. Currently, there is very little material covering

the features of JAI in explicit detail. At the time of writing only one book is in publication that devotes any material to the JAI [LR01]. The main support obviously comes from the developers, Sun Microsystems [SUN2], who provide an API specification, a brief tutorial, and example code.

2. There is a lack of browser support for the JAI, which would effect the proposed applet version of the simulation. Although there is a browser plug-in available, its download size is relatively large, and can be difficult to install.

2.10 Image Processing Image processing is the mathematical manipulation of digital images. The Java 2D API provides built-in image processing operations, which can be applied to a BufferedImage object, via the BufferedImageOp. This procedure is described as filtering because the BufferedImageOp is supplied with a particular image processing operation and then its filter() method is called. This results in the source image been manipulated (or “filtered”) according to the processing operation applied and then output to the destination image. This method is more advantagious than reading each pixel of an image, then modifying and rewriting the pixel back to the source image, which is essentially the purpose of the Raster interface as described in section 2.9. Although for complex processing, or to perform operations that are not defined by the 2D API, it is essential to utilise the tools provided by the Raster and WritableRaster classes. There are various built-in operations available, which are used in the simulation and are described in more detail in the implementation section, the main operations are: 1. AffineTransformOp - performs affine transformations, for example, translation, scaling,

rotation, shearing, etc. 2. RescaleOp - adjusts the brightness of an image by multiplying the colour component of

each pixel by a particular scale factor. 3. LookupOp - specifies how the source pixels should be mapped to the destination image by

applying a “lookup table” that indicates how the mapping should be performed. 4. ConvolveOp - The colour of the destination pixel is determined by averaging the colour of

the corresponding source pixel and a selection of its surrounding neighbours. This selection of pixels is represented as a matrix that contains the corresponding pixel values as coefficients. Convolution is calculated by the sum of multiplying the source coefficient by its neighbouring coefficients.

5. ColourConvertOp - converts the colours of an image from the initial colour space to a new colour space.

14


2.11 Competitive Analysis Although the term “competitive analysis” [JN93] is a relatively extreme statement to use within the context of this project, it is useful to examine related work that could be useful in the analysis, design and development of the Lith Printing Simulation. A previous project, Darkroom Simulation for Photographic Printing by Duncan Watson [DW01], devised a simulation for conventional black and white photographic development. The programs user interface modelled the various component of the dark room set-up as interactive components that the user could manipulate to alter the appearance of the projected and developed images. Another important feature was the implementation of the photographic paper being exposed in real time, which is also central to the lith simulation. The original design ideas discussed in [DW01] will be used as a foundation for this project and built upon to produce the lith-effect during development. Improvements that could be made to the previous project were also discussed within the project documentation, these included: 1 Implementation of an applet version of the simulation running on a web page. 2 On-line tutorials or help files. 3 A choice of negatives so that the user can experiment with alternative images. 4 “Drag and drop” features for the interactive components, for example, the user could move

the paper from the enlarger to the development tray by dragging the paper object between different windows or graphical elements.

5 The only exposure control available was via the dodging tool that had limited functionality. Burning and flashing exposure tools can also be considered, with additional control features, such as the resize and rotation of the tools.

A major alteration will be the inclusion of the mathematical principles relating to the manipulation of the components of the enlarger (such as magnification, focus, aperture, etc.) as described in section 2.1, which will probably result in a complete redesign of the simulation user interface. Finally, a more ambitious option for this project was to create a plug-in for Adobe Photoshop. Although this option has been rejected, it would be useful to incorporate graphics package-style facilities such as a load/save and print options, so that the user can retain the completed print after the tutorial is complete.

15


3. Analysis 3.1 User Analysis The first phase of analysis was to gather information about the proposed users of the Lith Printing Simulation. The purpose of this being to distinguish how the user will need to relate with the application, i.e. what they are attempting to achieve and how the simulation will accomplish this. Initially, using questionnaires and interview techniques were considered as a possible User Analysis method. The advantages of this approach being that it is possible to gather a wide range of contrasting opinions and user preferences, and the methods can easily be repeated if necessary. But, the major drawback of these methods is that they are time consuming (in terms of gathering potential users, conducting the analysis, and analysing the results) and also requires a large number of participants in order to tabulate substantial results that will useful to the preceding design and implementation stages. The latter problem was one of the limiting factors during preparation for user analysis, which prompted the use of the methodology described below. 3.1.1 User Observation The Observational technique provides more insight into the functionality and features required in the simulation, than either the questionnaire or interview methods, by observing the users in their working environment. Although, there is one main disadvantage, in that the interviewer has restrictive and limited control of the individual being observed. To eliminate this problem, Contextual Enquiry was used (an extension to the standard observational technique), which encourages the interviewer to engage in a dialogue, converse and interact with the interviewee, in order to gain knowledge from the perspective of a user oriented approach. Contextual Enquiry was carried out in a darkroom environment, with a single interviewee, where the process of developing various photographs was observed. Although the development was specifically concerned with traditional black and white photography the requirements and objectives recorded can easily be extended to the development of lith prints. An important factor to note, is that the simulation is not designed to improve the development process in any way, simply to provide an emulation of existing techniques and to reduce some of the restrictions of the actual process (E.g. cost, time consuming, waste of materials, “pepper fogging,” etc.). Therefore some of the comments made by the interviewee are irrelevant, for example, the problem of weak shadows resulting from an underdeveloped negative cannot be resolved in the simulation because it is physical and chemical consideration, which goes beyond the scope of the application. 3.1.2 Task Analysis Another advantage of Contextual Enquiry is that it is “a well-known method for doing user analysis jointly with task analysis” [FJWC01]. This insures that that the tasks and goals can be obtained from the observation process defined above. As already mentioned in section 2.7.3, UML Use Case notation will be used to assist task analysis, to help define the actions the user will take to perform a specific task and the subsequent goal(s) that the user is aiming to achieve. Once the tasks have been established they will be used to test the design and implementation of the user interface throughout the development process. Also, the number of tasks will be restricted to the most essential and frequently used, to insure that the most important functional aspects of the lith printing process are implemented in the final iteration of the simulation.

16


3.2 Contextual Enquiry Described below are the various results that were obtained by performing the contextual enquiry technique in a dark room environment. 3.2.1 Making the lith print The production of lith prints follows a step-by-step procedure, which is detailed below: 3.2.1.1 Pre-exposure: 1. The developer concentration, stopping agent and fixer solutions are prepared in advance to

the exposure and development process. 2. The printing paper grade is selected with respect to the negative that has been selected,

which will influence the contrast characteristics of the resultant print. 3. The printing paper is placed on the easel and the metal “arms” are adjusted to the

dimensions of the paper. a) The paper can be exposed to pure light by applying the flashing technique, i.e.

performing the exposure process (go to step 9) without the negative placed in the negative carrier. The paper is then removed from the easel.

b) Or, flashing is not applied and the paper is removed. 4. The negative is placed in the negative carrier and the enlarger light is switched on, the

image is projected onto the easel. 5. The magnification is altered my moving the vertical position of the enlarger head along the

enlarger frames column. This will also result in a subsequent alteration of image focus and brightness.

6. The focus is adjusted by turning the focus dial located on the enlarger head. 7. The aperture is adjusted by rotating the aperture dial attached to the enlarger lens. 8. The enlarger light is switched off, and the paper is re-placed on the easel. 3.2.1.2 Exposure: 9. A long exposure time is programmed, the timer is started, and the enlarger is activated.

The exposure can be stopped at any time or will continue until the time limit has expired. 10. During the exposure the dodging and burning exposure tools can be applied. The tools can

be held in a fixed position or moved in two dimensions: a) Horizontally: gradually moving the tool across the easel, which will result in a

varying range of contrasts over the surface of the print. b) Vertically: moving the tool towards the lens will result in a larger area of coverage

and a larger penumbra effect, where-as moving the tool away from the lens will result in a smaller area of coverage and smaller penumbra effect.

11. The timer has stopped. If required, the flashing technique can be reapplied (see step 3.a in the pre-exposure section).

12. The paper is removed from the easel and placed in the development tray. 3.2.1.3 Development: 13. During development, the image gradually begins to appear on the surface of the paper as a

reaction takes place with the development solution. Generally, the formation of the lith-effect will conform to the following visual steps:

a) There will be an exponential increase in the development of the darker tones. b) These dark tones will eventually form solid, black, high contrast areas on the print

that will separate the lighter tones and low contrasts.

17


14. At this stage the print should be snatched from the solution, while the lighter tones are still developing, resulting in the traditional black/colour/white split and the hard shadows/soft highlights “lith effect”.

15. The paper is placed in the stop bath and development is haltered. 16. The paper is placed in the fixer to remove the chemicals from the surface 3.2.1.4 Post-development: 17. Toners can be applied to the lith print to alter the colour characteristics. 3.3 Use Case Analysis The purpose of use case analysis is to clearly identify the basic tasks that the photographer will perform in the dark room environment. The tasks that are established at this stage will be used in the preceding section, Identification of Tasks, where they will be clearly defined in extensive detail. The use cases will also be extended to the design stage, as they are important in terms of establishing possible classes that will be implemented in the program code. Figures 3.1 and 3.2 show the various tasks involved during the exposure and development processes, respectively. The Exposure Process diagram shows an important extension between the Flashing Tool and the Set Timer tasks. The flashing tool essentially uses exactly the same task steps as the exposure process from the initial stage of setting the timer. Therefore, the Flashing Tool task is defined via the Set Timer task (and its corresponding sub-tasks).

Figure 3.1: Exposure Process Use Case

18


Figure 3.2: Development Process Use Case 3.4 Identification of Tasks The list below indicates the requirements and objectives of the simulation: 1 The user should be provided with a selection of images that can be used as negatives and

applied to the simulation. 2 The user must be able to control and manipulate the basic darkroom equipment that is vital

to the production of a lith print. The most essential mechanism is the Enlarger. The user should be able to manipulate the enlarger components that control magnification, focus, and brightness.

3 The user should be able to adjust the easel slider “arms” to define the size of the paper. Also, the easel must be repositioned to configure the area of the projected image that will be within the confines of the paper.

4 The user should be able to select from a range of paper grades providing different contrast characteristics.

5 A timer device must be available, which enables the user to increment/decrement the exposure duration, and also start/stop the exposure.

6 To achieve unique prints the user should be able to manipulate various tools in order to control exposure and contrast rates, such as burning and dodging tools. The user should be able to resize and reposition the tools to achieve different effects. Additional exposure of the paper should be provided via a “flashing” option.

7 The user should experience real time exposure that incorporates the use of the exposure tools defined above.

8 The user should be able to alter the development solution intensity in order to obtain different lith-effect results during development.

9 It would be useful for the user to experience the development in real time, firstly to gain an understanding of how the image is formed, and secondly to determine the best “snatch” point. The user must be able to interrupt the development process as any time.

10 The exposure and development of the projected images should result in a destination image that emulates the appearance of a lith print

11 A method of representing the “fogging” of a print, possibly by developing an algorithm or generating random “noise” that will cause image degradation. The user may wish to disable this feature.

19


12 Enable the user to trace the “movement” of the paper as it passes through the different stages of the lith development. For example, the user could select a piece of paper and then drag it to the enlarger, once the exposure process is complete the user will move the paper through the various development trays, etc.

13 A post development toning option that enables the user to adjust the highlight colour of the lith prints (possibly including gold and selenium toning effects).

Additional features: 1 The simulation should provide help facilities, or possibly a text based running commentary

in order to assist the user in the operation of a particular feature, or provide insight into a particular aspect of the process. There should also be some form of self-assessment, such as an on-line questionnaire, so that the user can insure they are learning the concepts of lith printing sufficiently.

2 Incorporate graphics package-style facilities such as a load/save and print options, so that the user can retain the completed print after the tutorial is complete.

3 Conversion of the simulation program into a Java applet to be used on a web page. Restraints: 1 Once the exposure or development process is executing, the user should be prevented from

manipulating any of the interactive components (with the exception of the exposure tools during the exposure process). This will reduce the complexity of the simulation because it insures attributes such as magnification, focus, etc. do not have to be re-calculated during the real time processing of the lith print.

2 The user should only be able to manipulate one exposure tool at any one time to reduce the complexity of real time processing.

3 It is not possible to emulate the exact characteristics of the various printing paper grades or the exact properties of the development solutions, stopping agents, toners, etc. these variables will have to be approximated.

3.5 Usability Measurements The Usability Measurements use the tasks specified in the previous section as parameters and define the goals to be attained by the user during testing, and more specifically, in the final application. This concept was applied in the Darkroom Simulation for Photographic Printing [DW01] project and proved to be a highly successful method of insuring targets have been obtained. If the measurement results improve for all successive iterations of the prototype design, this means that the learnability and efficiency of the simulation is subsequently improving, hence the user goals are being satisfied. Otherwise, the design needs to be reconsidered. The tables specified below relate to the most important tasks the user will perform; these correspond to the selection of the Use Cases defined in section 3.3. The design of the tables is based on the “sample usability specification table” as defined in [FJWC01] as part of the “Usability Benchmarks” process (which is a comparable technique to usability measurements). The tables will be used in conjunction with a tutorial the user will complete, which will aid the testing of the user interface and the task/goal requirements (a more detailed examination of the tutorial is given in the Testing section).

Measurements Observations Value Usability Attribute Manipulation of the Enlarger components. Measuring Instrument The user is expected to set the magnification, focus and

brightness according to the example given in the tutorial. Tutorial

Value Measured The ability of the user to successfully alter the enlarger head, focus dial, and aperture dial.

Range: 0 - 2

20


Current Level This will be measured during testing. - Worst Acceptable Level The user is unable to adjust any of the interactive

components. 0

Target Level The user can adjust the interactive components, but the magnification, focus and brightness values are incorrectly specified

1

Best Possible Level The user can adjust the interactive components and the magnification, focus and brightness values are correct.

2

Observed Results This will be measured during testing. - Table 3.1: Enlarger Manipulation Usability Measurements

Measurements Observations Value Usability Attribute Exposure Process Measuring Instrument The user is expected to set the timer, start the exposure

process, and then manipulate an exposure tool, as indicated in the tutorial.

Tutorial

Value Measured The ability to perform the exposure technique and control the exposure tool.

Range: 0 - 5

Current Level This will be measured during testing. - Worst Acceptable Level The user is unable to start the exposure process or

manipulate the exposure tool. 0 - 1

Target Level The exposure process is initiated and basic control of the exposure tool is achieved.

2 - 3

Best Possible Level The exposure process is initiated and the user is able to perform all the required exposure tool commands, such as movement, scaling, rotation and removal.

4 - 5

Observed Results This will be measured during testing. - Table 3.2: Exposure Process Usability Measurements

Measurements Observations Value Usability Attribute Development Process Measuring Instrument The quality of the lith image after development in

comparison to the expected image provided in the tutorial. This will assume that the Exposure Process has already been completed.

Tutorial

Value Measured The visual appearance of the image. Range: 0 - 5

Current Level This will be measured during testing. - Worst Acceptable Level The image is not developed or the developed image is

totally underexposed or overexposed so that there is no image detail apparent to the observer.

0 - 1

Target Level The image has been correctly developed, with an adequate range of shadow/highlight separation, but is distinguishable from the example given in the tutorial.

2 - 3

Best Possible Level An obvious shadow/highlight and black/colour/white split of the developed lith image that corresponds very closely with the example given in the tutorial.

4 - 5

Observed Results This will be measured during testing. - Table 3.3: Development Process Usability Measurements

21


4. Design During the analysis phase the users’ tasks and goals were defined, this gave an indication of the expected interaction between a user and the simulations user interface. As already indicated the usability of the interface is essential to the design of the simulation because the user must be able to attain their goals effectively, with relative ease, and to a level of satisfaction they deem acceptable. But, the development of the lith algorithm is also an equally important feature of the simulation, as the output must adequately emulate the properties of a lith print. Therefore, it was decided that the implementation of the user interface (UI) would be conducted in conjunction with the design phase in order to reduce time restrictions and enable more focus on the lith algorithm later in the development cycle. 4.1 Object Oriented Design Before considering the usability aspects, it is important to establish the class hierarchy of the simulation, using UML notation. 4.1.1 Design Patterns Because object oriented design is now an established software development model, there are several design problems that are frequently encountered during the development life cycle. Design Patterns provide design solutions to a specific problem domain or context. The solutions are described in terms of objects and interfaces that can be applied in many different situations. This approach essentially provides a template that can be reused across designs; hence there is no concrete definition or implementation for a pattern. “Design Patterns” by Gamma, Helm, Johnson, and Vlissides [GHJV95] defines 23 fundamental design patterns, each of which falls into a particular category: 1. Creational - defines the process of creating an instance of an object. 2. Structural - defines the relationship between compositional classes and objects. 3. Behaviour - defines the way classes or objects interact and distribute responsibility. Furthermore, each individual design pattern is characterised by four parameters: 1. Name - used to describe the design problem. 2. Problem - indicates the situation when a design pattern can be applied. 3. Solution - describes the objects and interfaces that compose the design solution and

indicate their behaviour, relationships, responsibilities, etc. 4. Consequences – the advantages and disadvantages of applying the design pattern. The Lith Printer Simulation will consist of various components that will be interacting with each other. Therefore, in terms of design, the most important pattern categories are structural and behavioural because they will help define the interaction. The first pattern incorporated into the design is shown in Figure 4.1, the complete overview of the Enlarger class hierarchy, extended from the class diagram in Figure 2.3. The enlarger device consists of additional components (the enlarger head, which subsequently incorporates focus and aperture), which need to be defined structurally. This is achieved by using the Composite pattern, which composes objects into hierarchical structures to represent the relationship between the controller class (the Enlarger class) and its sub-classes (the Focus and Aperture classes), via the use of the composite relation (the diamond symbol in the diagram).

22


Figure 4.1: The Enlarger hierarchy The behaviour of the Enlarger class hierarchy can be described in terms of the MVC (Model/ View/Controller) example described in [GHJV95]. The Model is defined as the “application object,” which obviously corresponds to the Enlarger object and its working components. The View is the graphical representation of the Enlarger object presented to the user on screen. And finally, the Controller is the user interface operations the user can manipulate in order to control the enlarger device. When the controller is activated by the user, the internal state of the model (Enlarger data) is changed, and the view (such as the magnification of the projected image) is updated to “ensure that its appearance reflects the state of the model” [GHJV95]. The design of the exposure and development classes (Figures 4.2 and 4.3, respectively) are based on the Adapter pattern, that enables classes to work together via a compatible interface. Both the exposure and development classes must implement a timer class that controls the real time operations involved in exposing and developing a lith image. Using the exposure class diagram as an example, both the Exposure class and ExposureTimer class implement a TimerListener interface that enables the ExposureTimer object to call the timeElapsed() method in the Exposure object. The timeElaped() method is called every second by the timer classes and will perform the image processing operations that emulate the gradual change in exposure or development (a more detailed discussion is provided in the Implementation section). In the class diagrams, the Exposure and Development classes are related to the interface via the realisation relationship (the dashed line with a triangular head), which indicates the behaviour and operations inherited from the ExposureTimer and DevelopmentTimer interfaces (more specifically, the inheritance of the timeElapsed() method).

23


Figure 4.2: Exposure class diagram based on the Adapter design pattern.

Figure 4.3: Development class diagram that is also based on the Adapter design pattern. 4.2 User Interface Design The initial stage of interface construction was a series of conceptual designs, basically pencil drawings, which described the layout of the proposed UI. These included diagrams of all the

24


interactive elements that the user will be able to manipulate. The next stage involved checking the designs against the task and goal specifications to insure all usability aspects were covered and then finally coding the first prototype of the UI, essentially providing a shell for the implementation of the lith algorithm and other image processing operations. The method of usability design is based on Scenarios, which “take prototyping to the extreme by reducing both the level of functionality and the number of features” [JN94]. By laying a foundation to construct the remaining functionality of the application, it enables the code to be changed easily and frequently, without the necessity of a complete redesign. 4.2.1 Swing and Event Listeners The UI design will require the use of Java’s Swing package that provides the tools required to build the interface components, in conjunction with the support of the AWT event handling capabilities. The operating system supports the UI by monitoring events, such as a button being selected via a mouse click, and then reporting these events to the application that is running. Using the button being clicked as an example, the Swing JButton interface component is created inside a class that implements the ActionListener interface, which contains the actionPerformed() method. This method is called every time an action event is registered (i.e. when the button is selected) and is passed an ActionEvent object from the source of the event. The code, specified by the programmer, contained inside the actionPerformed() method then captures the ActionEvent object and uses its information to verify that the button has been selected and to determine an appropriate reaction. There are various event listeners that can be implemented depending upon the Swing component being used, for example, mouse movement events are registered via the MouseMotionListener. For the Lith Printing Simulation to provide interaction with the users, all UI components will be established as described above, such as the interactive elements, buttons, input fields, etc. 4.2.2 Layout Management The user interface is divided into a series of internal windows, each containing a separate component representing a particular feature of the darkroom process, all of which are contained within a single frame. The advantage of having all the windows internal to the frame, as opposed to having separate windows (i.e. multiple instances of the standard JFrame class) is allowing more control over layout management. For example, minimising the main frame will hide all the windows relating to the program. Internal windows are created using the JInternalFrame class and must be contained within a single JFrame.

Figure 4.4: The Lith Printer frame layout. Every internal frame contains a JPanel object; this is an essential interface class, as it contains the paint component method that can be overridden to allow the graphical elements to be drawn within the frames (e.g. the easel sliders, enlarger head, buffered image, etc.). Before each JPanel is added to an internal frame, it is first wrapped inside a JScrollPane. This

25


procedure insures that if an internal frame is resized to a dimension that is less than the preferred panel size, the user will be able to scroll the panel to view its contents. 4.2.3 Interactive Components The easel, enlarger, focus and aperture frames all have interactive graphical elements. For example, the enlarger has an adjustable enlarger head that the user can move between the base and top of the enlarger frame (see Figure 4.5). The enlarger head is a JPEG image that is contained within a separate class, the EnlargerHead class, which is a relation of the Enlarger class. The EnlargerHead class contains co-ordinate data relating to the position of the enlarger head within the frame. The Enlarger class implements the MouseListener and MouseMotionListener interfaces that intercept the mouse events and detect when the mouse pointer is within the confines of the enlarger head object by using the getX() and getY() methods of the captured mouse movement event. The user can then use the mouse to move the object by clicking and dragging. Obviously, depending upon its function, the interactive element has various constraints, in the case of the enlarger head the user can only move the image vertically. All the classes that have interactive elements work using exactly the same technique, the combination of MouseListener and MouseMotionListener (implementing the mouseMoved(), mousePressed(), mouseClicked(), mouseReleased(), and mouseDragged() methods) and image co-ordinate information.

Figure 4.5: Screen shot of the easel and enlarger windows. This shows the projected image partially obscured by the triangular burning tool in the easel window, and the height of the burning tool in the enlarger window (the floating rectangular shape). 4.2.3.1 Easel - The easel frame contains a vertical and horizontal arm that the user can move to adjust the paper size (indicated by the white area surrounding the projected image). The maximum dimension of the projected image at full magnification is 468 by 312 pixels; this corresponds to the equation in section 2.1.4 that calculates maximum magnification to 46.8cm by 31.2cm, i.e. a scale of 10 pixels to one centimetre. To insure that the easel size is proportionate to the projected image, the easel uses the same scale. Therefore, when the enlargement calculation is applied to the projected image, it will fit adequately on screen. 4.2.3.2 Enlarger - As already described, the user can move the enlarger head vertically along the enlarger column, adjusting the height will increase/decrease the size of the image displayed in the easel frame. Again, to insure that enlargement calculations can be applied accurately, the

26


enlarger uses a scale value of 5 pixels per centimetre. Although the minimum height is defined a 0.0cm, the Enlarger class rejects any height values less than 10.0cm, because this will result in a magnification where M < 1.0. This subsequently results in a projected image that is too small for the user to manipulate. 4.2.3.3 Focus - The focus frame contains a graphical representation of the internal working of the enlarger head (which shows the distance of the lens from the negative, see Figure 4.6) and a control dial that the user can rotate to alter the focus. As the user rotates the dial, two events occur, the projected image is blurred/sharpened in the easel frame and the enlarger head graphic is updated within the focus frame. Because the dial can rotate by 360o and the maximum focus value is 120mm, each turn of the dial corresponds to a 3o rotation. Rotation is applied via an AffineTransformOp image processing operation (see the Implementation section for more details).

Figure 4.6: The focus frame. The position of the lens (blue object) represents focal length and is updated simply by incrementing the vertical co-ordinate relative to focus change, and then calling the repaint method in the Focus object. 4.2.3.4 Aperture - The aperture frame contains a graphical representation of the enlarger lens (simply two circle objects, a white circle that represents the lens, and a black circle that represents lens coverage) and two directional arrows. Clicking on the left arrow increases lens coverage, and clicking on the right arrow decreases coverage. Each successive change in aperture updates the intensity of the projected image in the easel frame. Aperture is also updated by adjusting the JSlider in the panel at the bottom of the frame, which is divided into f-number intervals.

Figure 4.7: The aperture frame

27


4.2.3.5 The “Chain of Responsibility” As already indicated, the Enlarger has a composite relationship with the enlarger head, focus and aperture components. When a user alters a component, the corresponding image processing operation will be performed. For example, if the aperture dial is altered, the image will be brightened/darkened accordingly. However, the current magnification and focus settings will need to be reapplied to the projected image in the easel window, and the methods required to calculate these parameters are contained in the Enlarger class and Focus class respectively. To resolve this problem, the Chain of Responsibility design pattern is used to define a “chain” of requests from the parent object to the child objects. Basically, the Enlarger object will initiate all image processing operations by calling the calculation methods in the Focus and Aperture objects (in that order), and finally redraw the projection in the easel window. Figure 4.8 indicates the requests made by the Enlarger object after the enlarger head height has been changed. In comparison, Figure 4.9 indicates the requests made by the Focus object after the focal length has been changed. The Focus object delegates the request back to the Enlarger objects, which then initiates the calculation methods in the same sequence defined in Figure 4.8.

Figure 4.8: The “Chain of Responsibility” initiated by the alteration of the enlarger head height.

Figure 4.9: The “Chain of Responsibility” is delegated back to the Enlarger. 4.2.3.6 Exposure Control - This UI element consists of a floating internal frame, which contains various JButtons. Six buttons correspond to the different dodging and burning tools. When the user selects one of these buttons the corresponding tool object is drawn on the easel, the object can be moved within the frame and rotated about its axis (double clicking on the object transfers operation between translation and rotation mode). A rectangular shape is also placed in the enlarger frame (between the base and enlarger head, see Figure 4.5), moving this object will adjust the size of the burn/dodge tool in the easel frame.

28


Figure 4.10: The exposure control frame Figure 4.11: XOR operation The dodging tools are constructed using the Shape interface that allows the outlines and filling of shapes to be rendered. The square and circular dodge tools are instances of the Rectangle2D and Ellipse2D classes, respectively. As the Shape interface does not have a triangle subclass, the construction of the triangular shape is more complex, requiring the GeneralPath class to build the shape. This class takes path instructions, represented as co-ordinates, and iterates through each instruction building the triangle segment by segment. The burning tools are created using the “constructive area geometry” [JK99] method of combining two or more shapes using a set of pre-defined operations. A Rectangle2D object is created and then the equivalent dodge tool object is created (i.e. if a circular burn tool is being created the circular dodge shape is used) that is half the size of the rectangle. These two shapes are then converted into an “area” object via the Area class. The Area class contains the ExclusiveOR() method that will produce the hollow outline of the burn shape internal to the rectangle object (i.e. subtracting the area of the larger shape that is covered by the smaller shape, figure 4.11 shows an example of this). The ‘X’ button removes the exposure tool from the easel frame, and the ‘torch’ button will control the “flashing” operation (see Implementation section). The directional arrow button is used to increase or decrease the size of the internal burn shape with respect to the rectangular boarder. When this option is selected, a dialog box (see figure 4.12) is displayed that excepts a percentage between 10% and 90% in the input box. This percentage corresponds to the ratio between the size of the border and the size of the internal shape.

Figure 4.12: The burn tool ratio frame 4.2.3.7 Timer - The timer frame is divided into two panels. The bottom panel provides various JButton’s that increment the exposure time (by intervals of 1 minute, 10 seconds, or 1 second), which update the exposure time drawn in the top panel (using the Font class to draw the numerical values). The timer control panel uses a GridLayout instance to equally distribute the arrangement of the buttons.

Fig 4.13: The timer frame

29


4.2.3.8 Input Validation - Both the easel, focus and enlarger frames have text fields that contain the numerical position of the sliders, focal length and enlarger head height, respectively. These text fields are DoubleTextField objects; this class extends the standard JTextField class (that allows single line data input), but provides validation and verification constraints that prevent illegal characters and out-of-range numerical data being entered. The code for this class is based on the implementation of IntTextField [HC01], and works by essentially eliminating invalid data before it is even displayed in the text field (this also includes the “pasting” of data into the text field). The DoubleTextField class extends the PlainDocument class, responsible for the formatting of text, and overrides its validation method, replacing it with constraints related to the simulation (non-negative numerical data within a given range, e.g. the enlarger head should accept values between 0 and 70 centimetres). The user is forced to enter information, and not leave the text field empty, as the class also extends the InputVerifier class, which retains the focus of the DoubleTextField if “null” data is detected or if the user attempt to transfer focus elsewhere leaving invalid data in the text field. Finally, the DoubleTextField also implements the KeyListener interface, which waits for the return key to be pressed, in order to read the data from the text field and update the appropriate interface component. 4.2.3.9 Loading and saving the Lith Print - The JFileChooser class is used to open and save files, allowing the user to navigate the file and directory hierarchy. This design incorporates the FileFilter interface that restricts the users file selection to just JPEG and GIF image files, discarding any other file format. The FileFilter interface allows icon images and descriptions (i.e. the .jpeg and .gif tags) to be assigned to the filtered files, and also enables customisation by adding “accessory” components such as the image previewer. All of these additional features are included in the design, see Figure 4.14.

Figure 4.14: File chooser with file filter and image preview features

4.3 Testing Strategy Usability testing will be performed throughout the iterative design and implementation cycle. As already indicated, each prototype developed will initially have the minimum level of functionality required, with the number of features increasing proportional to the increase of iterations. During testing it is important that the users follow a pre-defined task set or plan, to insure that they are only evaluating the parts of the system that are functional. Once implementation reaches its final stages, and the vast majority of the features are implemented,

30


then the test participants will be provided with a tutorial to complete, which will be evaluated according to the Usability Measurements tabulated in section 3.5. In conjunction with the testing strategy described above, Heuristic Evaluation will be deployed, which uses a series of heuristic principles to detect usability problems in the design so that they can be resolved during the iterative design process [NM90]. This is described as a “discount usability engineering” process [JN94], which provides a relatively quick and easy approach to interface design evaluation, on account of a major difference concerning the observation of the evaluation participants in comparison to standard usability testing. The purpose of usability testing is to discover all the errors a user makes when using the interface. Therefore the “experimenters” observing the users do not usually provide help when problems are encountered. During heuristic evaluation, the user is encouraged to ask questions if they are confronted with a difficulty or describe what they are currently trying to achieve, and the experimenter will provide details of how to resolve the problem. This approach insures a better understanding of how and why a usability problem is encountered and what can be done to improve usability from the users’ perspective, as opposed to simply observing the problem but gaining no insight or feedback. To insure that a good proportion of usability problems are found during heuristic evaluation, the process will be performed using a number of test users, and repeated if necessary, providing there are no time restraints. 4.3.1 User Interface Design (UID) Patterns for Usability Testing As described in section 4.1, object oriented design patters are useful for resolving software design problems. In the same way, user interface design patterns can be useful for resolving interface design problems. Although the standard UI guidelines will be used to design the interface, they have various disadvantages, the main problem being they are merely design suggestions and do not apply specifically to interface design problems [WVE00]. For example, “make the user feel in control of the interface,” is too simplistic and abstract to provide any possible solution to a problem. Unlike the equivalent object oriented design patterns, there is no UID pattern standardisation, which is the main reason they have not been deployed in the design phase. Therefore, it has been decided to use UID patterns in conjunction with usability testing to focus on problems highlighted during Heuristic Evaluation, and to indicate the possible solutions. The UID pattern in Figure 4.15 is based on the Template design described in [WT00]. Name The Help Dialog. Problem The user enters a value for the enlarger head height that exceeds the

maximum height of the enlarger. Usability Principle Prevent Errors. Solution The height value should not be changed and the user should be

informed of the error.

Figure 4.15: User Interface Design Pattern Template

31


4.3.2 Traditional Testing Methods Finally, it is probably unrealistic to perform extensive “traditional” testing strategies combined with the usability testing procedures described above. For example, Specification (“Black Box”) testing is very time consuming in terms of examining the vast number of variables and statements that inevitably occur in reasonably sized software applications, and then devising evaluation data that will test the input, output and functionality of the code [JW00]. Although, the nature of the Lith Printing Simulation is more oriented towards usability testing than Specification testing on account of the reduced data input requirements of the application and the use of a prototype driven design as opposed to a formal specification. One possibility is to perform Implementation (“White Box”) testing, tracing each “logical” path (or code segment) through the program, for example, insuring that the user cannot start the development process before an image has been exposed to prevent a system error. In conclusion, the simulation will only be subjected Specification and Implementation based testing to verify crucial segments of the program code.

5. Implementation

This section is concerned with the image processing that is applied to the “lith” image during projection, exposure and development. Most importantly, a description of the lith-effect algorithm is provided, which is defined via a combination of image manipulation techniques. 5.1 Image Processing during Projection 5.1.1 Obtaining the Image Initially, the source image to be used as the negative is loaded using the Toolkit class (which contains system-related information, specifically the file hierarchy of the operating system) and stores it as an Image object. To prevent any other operations being applied to the image before it is completely loaded into memory, the MediaTracker class is used to trace the progress of the image and will cause the program to halt, until the entire image has been transferred to the memory buffer. The problem with the standard Image class is the limited accessibility of image data, to overcome this problem the image is converted to a BufferedImage, which allows direct access to the data. All image processing is applied to the BufferedImage by specifying the mathematical manipulation via the BufferedImageOp interface. This interface takes the existing source image, applies the specified operation, and returns the destination image. 5.1.2 Creating the Negated Image The buffered image requires two transformations in order to produce the negated image that will be projected. The first transformation insures that the image is of a grey-scale format, this requires a colour space conversion. The ColorSpace class is a collection of colours that are used by a particular application, the most obvious being the monitor or visual display unit (VDU), an instance of this class is the CS_GRAY constant that represents the grey-scale colour space. Using this constant in conjunction with ColorConvertOp class changes the colour space of the destination image from four components (ARGB) to a single component (alpha) and then specifies an intensity value for each pixel that will define a colour ranging between black and white.

32


The second transformation negates the grey-scale image; this is achieved by using a lookup table. The table is essentially an array that contains the values of the destination pixel colours, which is applied to all the colour values of the source pixels. Since the pixel colour values are stored as bytes, the ByteLookupTable class, a subclass of the LookupOp, is used. The LookupOp specifies the pixel colour mapping from the source to destination image via the lookup table array. Considering that a single pixel value is within the range of 0 to 255, the array contains 256 elements. The inversion is calculated by taking the index value for each of the array elements and deducting this value from 255.

byte negative[] = new byte[256]; for (int i=0; i<256; i++)

negative[i] = (byte)(255-i); 5.1.3 Image Magnification The scale value is determined by obtaining the height of the enlarger head and applying it to the magnification equation described in section 2.1.4: M = (height / 0.05) - 1.0; After the scale value has been calculated the magnified dimensions of the destination image are deduced by multiplying the scale value by the width and height of the original image. This new dimension is then applied to the AffineTransform class, which defines the scale transformation. The scale transformation is then subsequently performed via the AffineTransformOp, which is passed the affine transformation object and the source image, and then generates the enlarged/reduced destination image. To insure that the minimum amount of image degradation occurs during the magnification process, a RenderingHint object is passed to the AffineTransformOp. This object controls the quality of the image during processing and as the term “hint” suggests, it indicates rendering preferences but does not directly control the process. The main problem of scaling an image is that the source and destination images will have a disproportionate number of pixels, therefore pixels that do not have a direct mapping must have their colour value estimated, there are different techniques to resolve this problem. For high quality results, the bilinear interpolation method is employed. This strategy constructs destination pixels by combining the overlapping pixel colours during enlargement/reduction. Although this technique does reduce system performance, the resultant images are of a higher quality compared to other techniques, such as the nearest neighbour algorithm (which uses the colour of neighbouring source pixels that corresponds closest to the destination pixel). Most of the image processing operations that are discussed in the preceding sections can accept rendering hints as parameters, and although the interpolation strategy described above is useful for scaling an image, it will not be used elsewhere. There are a vast number of rendering hints, which provide a contrast between processing speed and image quality, for a number of different rendering algorithms, such as antialising, colour rendering, dithering, etc. The main problem is that not all operating system platforms support the rendering hints [HC00] and the applied hint does not always make a difference to the appearance of the image, for these reasons they will not be used during the remainder of the implementation phase. 5.1.4 Image Focus The focus value can be calculated by obtaining the focal length and the current magnification and applying these values to the focus equation described in section 2.1.5.

33


The convolution operation, performed by the ConvolveOp class, can be used to blur or sharpen an image. This operation takes each pixel of the buffered image and changes the colour depending on two particular factors: the colour of each source pixel and the colour of a predefined number of pixels surrounding the source pixel. The Kernel class is used in conjunction with the ConvolveOp, and determines how the source pixel and neighbouring pixels relate to each other. The kernel is essentially represented as a matrix, which is subsequently represented as an array of floating point numbers. The centre of the matrix defines the source pixel and the remaining coefficients define the neighbouring pixels. The resultant colour is determined by the sum of multiplying the source pixel value by the value of each of the neighbouring coefficients. After experimenting with various matrix sizes, it was decided that a 15 x 15 matrix (225 coefficients) was the most appropriate representation, as it produced a large degree of blurring, while still retaining image clarity, i.e. it was still possible to determine what the image was supposed to represent. Although this is a relatively large matrix dimension, there appears to be no system degradation while performing the convolution operation, and there is no change in performance speed compared to the smaller matrix sizes that were initially used. For the image focus to remain unchanged the sum of the all the coefficient values must equals one. Therefore, if the focal length (FLength) is equal to the calculated focal length (F), then the source value (i.e. the centre of the matrix) will equal one and the surrounding values will equal zero, so that the focus is perfect. When the two focal lengths are not equal, the image will be blurred; the following algorithm calculates the centre and neighbouring coefficients in this situation, which defines the extent of the blurring effect:

float F = (height / M) float centre = abs(1.0 - (abs (F - FLength) / F)); float remainder = (1.0 - centre) / 224; float[] elements = new float[225];

for (int i=0; i<225; i++) {

if (i == 113) elements[i] = centre; else elements[i] = remainder; } Initially there were a few problems with the focus method. The first problem was concerned with the blurring effect being applied to the edges of the buffered image. Because the pixels forming the border of the image do not have all their neighbouring pixels on the image, these pixels are incorrectly evaluated during the blurring process, and are replaced with black pixels, leaving a solid border around the image during extensive blurring. One method of combating this problem was to supply the ConvolveOp with the “no edge” constant which insures that the border pixels are exempt from the operation, this leads to another problem, where the centre of the image can be heavily out of focus, and the border remains in focus. The final solution was to draw a white border around the image before the transformation is applied. The width of the border is equal to half the size of the kernel matrix dimension (in this case 7), as this is the number of pixels from the image edge that do not have all their neighbouring pixels visible. The second problem is related to the enlargement process. A requirement of the system is to change image focus relative to the adjustment of the enlarger head. This process is implemented in the code: when the user moves the enlarger head a method in the Focus class is called to re-calculate the blurring effect and update the image in the Easel class. Although the mathematical aspects are correct, there appears to be no apparent change of the image during enlarger movement, this is because the change in focus is so small that the resultant image change is barely noticeable, especially when the enlarger head is close to maximum height.

34


There were two possible solutions to resolve this problem, the first was to increases the kernel size further which would insure that the focus change is noticeable, but unfortunately this made the extent of blurring unrealistic. The second option was to discard the mathematical approach and approximate the blurring effect. This was achieved by making focus directly proportional to magnification, so when the maximum scale value was applied to the image, the maximum focus value was required to perfectly focus the image. The existing code was easily extended to incorporate this approach, by taking the ratios of the enlarger height and the focal length to calculate the centre coefficient value.

float F = height / 70.0; float ratio = FLength / 120.0; float centre = 1.0 - (Math.abs(F - ratio)); 5.1.5 Aperture and Light Intensity The RescaleOp is responsible for controlling the change in brightness. This class multiplies every colour value of every pixel by a scale factor. A scale factor of 1.0 retains the original image intensity, and the intensity increases or decreases if the scale factor is greater than 1.0 or less than 1.0, respectively. To simulate the properties of lens aperture, it was initially proposed that each consecutive change in f-number would result in the light intensity being halved if the user “stepped down” or double if the user “stepped up”. The aperture position f/8 was chosen as the central setting, i.e. where the scale factor equals 1. Hence, at f/5.6 the scale factor is 2, and at f/11 it is 0.5. Unfortunately, when the scale factor is equal to, or greater than 2, the transformation results in an image which is almost entirely white, removing all image detail, therefore f-numbers f/2, f/2.8, f/4 and f/5.6 are rendered useless. The same problem exists when “stepping up”, except that the image darkens to such an extent that the pixel colours converge to black, again eliminating image detail and removing the functionality of the upper f-numbers, f/11, f/16 and f/22. Therefore the scale factor (s) relating to each f-number has been approximated to within a range of: 0.125 < s < 1.875 (see the table below).

f-number approximated scale factor (s)0 1.875f/2 1.750f/2.8 1.500f/4 1.250f/5.6 1.000f/8 0.750f/11 0.500f/16 0.250f/22 0.125

Table 5.1: f-numbers and corresponding scale factor. Another property of the RescaleOp is the offset value that is applied to every pixel component (C) after it has been scaled [JK99]:

C = (s * Co) + offset

This property has been used to simulate the effect of increasing image brightness as the enlarger head is moved closer to the easel. The value of the offset increases proportional to the reduction of enlarger head height (see inverse square law, section 2.1.6).

35


5.1.6 Saving the Buffered Image Once the simulated lith process is complete, the user may wish to retain the image, which is saved as a JPEG file using the Java Codec class (the class enables image data to be encoded using the JPEG compression algorithm). The codec class is used in conjunction with the JFileChooser object discussed in section 4.2.3.9. 5.2 Image Processing during Exposure Because the exposure process must execute in real time and also enable the user to manipulate the exposure controls (dodging and burning tools) during the process, the Exposure class should be implemented to allow the user to control both operations concurrently. 5.2.1 Multithreading Concurrent activity is achieved via multithreading, the process of allowing individual programs to perform multiple tasks at the same time, where each task is defined as a thread. A thread can control a particular procedure, and run independently from other threads, although there can be synchronisation between them [JF98]. For example, the Exposure class will have a thread that will communicate with the user interface thread in the Easel class. Each thread will have an opportunity to run so that the exposure tools can be moved in the easel window and the Exposure class will respond to this change when it regains priority. This essentially “keeps the user in control” [HC00] by running important code fragments between the two classes. The concept of multithreading is a direct descendant of multitasking, where multiple programs can be working at the same time, via the operating system distributing resources per given time-slice, to provide parallel activity. The Exposure thread will be called from the user interface (UI), after the user presses the start button in the timer window, and will be able to communicate with the UI while it is running. The extent to which the Exposure thread will continue to execute depends upon two factors, the first being the time duration the user specifies in the timer window, the second relates to the user interrupting the thread by pressing the stop button in the timer window. During a thread’s life cycle it can be classified by one of four categories, these are described below: 1. New - when the user interface creates an instance of the Exposure thread, it is declared a

“new” thread, and is allocated the necessary resources by the application but is not executed.

2. Runnable - each thread object has a start() method that is invoked, by the user interface, initiating the Exposure thread and executing the code. During execution the thread will be “running” but is still classified as “runnable.”

3. Blocked - each thread also has a sleep() method that halts the execution of the runnable thread by a specified number of milliseconds. The Exposure thread is halted every second and passes the focus back to the UI so the user can manipulate the exposure tool in the easel window. After a second has elapsed, the Exposure thread temporarily regains focus and updates the exposed image accordingly. The process is repeated until the exposure time has expired or the user interrupts the thread.

4. Dead - the thread is declared “dead” if it stops naturally or if the interrupt() method is called, depending on whether the exposure time has expired or the user presses the stop button in the timer window, respectively.

36


5.2.2 Implementing Exposure using Principles of Animation The implementation and gradual increase of the exposure is based on the principle of animation, although the user does not actually see the progression of the exposed image, as it is processed off-screen. An approach that was initially considered was to use the Timer class (provided by the Swing package) to control each frame of the animation per unit of time. The Timer class would work by taking an Exposure object that implements the ActionListener, that subsequently inherits the actionPerformed() method, and for each second that elapses the actionPerformed() method is called within the Exposure object. If the actionPerformed() method were to contain the code to manipulate the exposing image, calling the method each second will control the gradual progression of the exposure. But, the Exposure class does not contain any Swing components, and because the Timer class will only work with an object that implements the ActionListener (which is primarily used in conjunction with Swing interface components) the use of the Timer is insufficient for this implementation. Therefore, it was necessary to create a timer class that is relevant to the simulation, called ExposureTimer, which is based on the functionality of the Swing Timer class. The ExposureTimer will extend the thread properties that will control the exposure process.

class ExposureTimer extends Thread // based on TimerTest class from [HC00] {

public void run() { try { while (!interrupted() && (time > 0)) { sleep(interval); listener.timeElapsed(this); // the ExposureListener time--; timer.setTime(time); // update timer window } } catch (InterruptedException e){} } }

A new interface is required, the ExposureListener, that can be implemented by the Exposure class as opposed to the ActionListener. By substituting the actionPerformed() method with the timeElapsed() method, the ExposureTimer can perform the same functionality as the Swing Timer and call the timeElapsed() method every second.

interface ExposureListener { void timeElapsed(ExposureTimer t); } public class Exposure implements ExposureListener { public void startExposure() { exposure = new ExposureTimer(1000,timer,this); exposure.setPriority(Thread.NORM_PRIORITY); exposure.start(); }

37


public void timeElapsed(ExposureTimer t) {

this.createExposedImage(); }

} The Exposure class contains two important methods that contribute to the functionality of the ExposureTimer. The startExposure() method creates and executes a new exposure thread. The new instance of the thread takes three parameters, the time duration applied to the threads sleep method (1000 ms), a copy of the timer/clock user interface component (so that the clock display can be updated each second) and a copy of the ExposureInterface instance (i.e. a copy of itself, so the ExposureTimer object can access the timeElapsed() method in the Exposure object). The timeElapsed() method contains a call to another method in the Exposure class, the createExposedImage() method, that performs the image processing on the gradually exposing image, and is described in the preceding section.

Figure 5.1: Sequence diagram showing the method calls involved during the exposure of an image while the user is manipulation an exposure tool. 5.2.3 The Exposure Algorithm Before applying the algorithm, the 8-bit ARGB encoded projected image is converted to a 16-bit grey-scale encoding. This provides more precision in terms of direct pixel manipulation because there is a larger range of pixel values to work with. Grey-scale encoding provides a maximum pixel range of 65535 as opposed to the ARGB maximum pixel range of 255.

38


The exposure algorithm is based on the implementation specified by Duncan Watson [DW01] in “A Darkroom Simulation for Photographic Printing.” The method works by gradually building the exposed image, over a particular time period, by a specific scale factor. Two BufferedImages are required, the projected image taken from the easel object and an equally sized duplicate; the latter will have every pixel set to the maximum brightness value (65535, pure white) to represent the paper before it is exposed. Each pixel of the original image is multiplied by the scale value 0.05 and then subtracted from its corresponding “paper” pixel. In [DW01] the scale factor is specified as 0.01, which is intended to emulate the exposure for conventional photographic printing, but because lith printing requires an extensive exposure a larger value is assigned as the scale variable. A scale factor of 0.05 will require 20 iterations to produce the original image; any successive iteration above 20 would result in an exposed image with darker tones and contrasts. The above method is effective because the projected image is inverted and any dark pixels that are applied to the scaling algorithm will result in light pixels on the “paper” image. Also, the resultant image’s detail is not degraded as a result of applying the scale calculation. 5.2.4 Dodging and Burning during Exposure As already indicated in section 4.2.3.6, the user can select from a range of dodging and burning tools, the implementation of which has already being explained except for one property, the penumbra effect. To create the appearance that the exposure tool selected is casting a shadow onto the surface of the easel and over the projected image, the edges of the tool need to be blurred. This can be achieved by applying the tool image to a ConvolveOp operation with a relatively large matrix size, to produce a convincing blurring effect, which is applied each time an exposure tool is drawn in the easel window. It is now possible to emulate the penumbra effect on the surface of the “paper” image during the exposure process. During exposure, the Exposure thread passes focus back to the user interface, and the user is able to manipulate the exposure tool within the easel window. The instant the Exposure thread regains focus it determines if the easel still contains the exposure tool, and if so, where it is located in respect to the projected image. This is calculated by comparing the coordinate position of the tool relative to the projection. If the tool is not within the bounds of the projection, then the exposure process is conducted as already indicated, otherwise a second exposure algorithm is applied to the partially “exposed” image. The ARGB model defines the colour values of each pixel contained within the exposure tool image. When the image is applied to the ConvolveOp these values are changed, including the alpha value. Because all the alpha values, before the ConvolveOp is applied, are set to 255, after the convolution operation is performed, there is relatively little blurring at the centre of the image but there is extensive blurring around the edges. Therefore, the alpha value will be at maximum at the centre of the tool image and will gradually reduce towards the edges of the image. The exposure algorithm can now be adapted to use the alpha value as a replacement for the standard scale value, by scaling alpha so that it is within the range of zero to 0.05, depending upon the extent of the penumbra.

double scale = alpha / 255; double scale = (1.0 - scale) * 0.05; Basically, if a pixels alpha value is large (i.e. a pixel at the centre of the tool image) then the scale factor will be small, so when it is multiplied by the projection pixel it is obscuring, there is only a small increase in exposure. This emulates the effect of the exposure tool preventing the paper receiving light from the enlarger head. Conversely, if the alpha value is small (i.e. a pixel at the edge of the tool image), then there will be a greater increase in exposure around the outline of the tool, which gives the appearance of a penumbra effect on the exposed image.

39


5.2.5 The “Flashing” Exposure Tool Due to time constraints, the “Flashing” tool option was discarded on account of the complexity of implementing the technique. Essentially, two additional threads would need to be created in order to expose the image to “pure light” (no projection image) for a particular duration of time, before and/or after applying the existing exposure technique described above. 5.3 Image Processing during Development The implementation of the development process, more specifically the image manipulation techniques required to generate a lith print, is based on a tutorial by Marco Pauck [MP01] entitled “How To Create Pseudo Lith Prints Using Digital Image Processing.” The tutorial is intended for use with Adobe Photoshop, or a similar image processing software application, and indicates the various operations to be performed, using the software package, in order to create a “lith-like effect.” Therefore, in order for the simulation to produce a realistic lith print using the classes provided by the Java 2D Graphics API, the image processing operations described in the tutorial must be coded into the application 5.3.1 Implementing development using the Exposure Technique Before discussing the algorithm used to create the lith print, it is important to note that the underlying functionality of the development process is similar to that of the exposure process. The Development class implements the DevelopmentListener interface that contains the timeElapsed() method which in turn is called via the DevelopmentTimer thread each second. The principle functionality of the Exposure object is to obtain the projected image from the Easel object and multiply each pixel by a scale factor, for each second that elapses, to emulate gradual exposure. Where-as, the Development object obtains the resultant exposed image from the Exposure object, and applies the operations specified by the pseudo code below, for each second that elapses:

Open the development window. While (user has not interrupted development) do {

1. Multiply the exposed image by a scale value to emulate gradual development. 2. Pass the scaled exposure image to the Lith class that will apply the lith

algorithm and return the current instance of the developed image. 3. The Development class contains the paintComponent() method because the

gradual formation of the lith image must be visible to the user, so the repaint() method is called to update the current instance of the developed image drawn in the development window.

}

5.4 The Lith Algorithm As already mentioned, the image processing techniques being applied are based on Adobe Photoshop operations, hence the Photoshop functionality will be discussed initially, and then the conversion into a Java 2D implementation. The lith algorithm is contained in the Lith class. 5.4.1 Shadows The first operation that the lith algorithm performs is the separation of the shadows, highlights and mid-tones. The Photoshop “Curves” function is used to perform this task by altering the contrast of the image, as show in figures 5.2 and 5.3.

40


Figure 5.2 [MP01]: Shadows Figure 5.3 [MP01]: Mid-tones and Highlights

The horizontal axis indicates the original brightness of the pixels and the vertical axis indicates the brightness of the pixels for the destination image. For an RGB image the brightness values range from between 0 and 255, but because the exposed image has been converted to a 16-bit grey-scale image, the lith algorithm will need to consider a brightness value range between 0 and 65535. The line segment inside the grid box is used to adjust the contrast of the image (i.e. increasing or decreasing the light/dark areas of the image). For example, the line graph shown in Figure 5.2 indicates how the shadows are generated. Firstly, any RGB value that exceeds or is inclusive of the brightness value 90 (the “input” value) will automatically be set to 255 in the destination image (the “output” value). This process is essentially applying a threshold operator to the image, clipping all the mid-tone values and assigning them the maximum value, insuring that pixels will be converted to very bright highlights or pure white. All the reaming source pixels will be calculated according to the curved segment of the line, between the horizontal brightness scale 0 to 90, which will result in black or very dark grey destination pixels. This curved segment is called the Gamma [APH], and is expressed as a ratio of the logs of the output and input values. The code segment below shows how this operation is implemented in the lith algorithm, using the grey-scale range, which will be applied to a LookupTable in order to map the exposed pixels to the shadow destination pixels.

short darken[] = new short[65536]; for (int i=0; i<65536; i++) {

if (i == 0) darken[i] = 0;

else if ((double)i >= threshold) darken[i] = (short)65535;

else darken[i] =

(short)( (Math.log((double)i) / Math.log(65535.0)) * 65535.0 ); }

The if clause insures that any source pixel that has the brightness value zero will be reassigned the brightness value zero because the calculation log(0) is undefined and would otherwise result in an error. The else if clause performs the threshold operation and insures that if the brightness value is equal to, or exceeds the threshold value, then it is assigned the maximum value of 65535. Finally, the else clause calculates the gamma value of any source pixels that have a brightness value that falls below the threshold.

41


5.4.2 The Grain Effect - “Pepper Fogging” The next stage of the tutorial discusses applying a “grain” effect to the shadow image to emulate the pepper fogging characteristics. An objective of simulation was to provide an additional feature that would allow the user to decide weather pepper fogging should be applied to the lith print image, so this process was investigated further. Again, reverting back to Photoshop to examine the grain effect, the tutorial [MP01] suggests using the USM (Unsharp Mask, see Figure 5.4) function to achieve the desired effect. USM is usually applied to sharpen areas of an image to eliminate extensive blurring by locating and examining pixels that differ from a specific number of surrounding pixels, and then altering the contrast of the pixels accordingly [APH].

Figure 5.4: Photoshop’s USM function. Figure 5.5: Photoshop’s HSB function, see section 5.4.3.1. The amount variable indicates the percentage increase in contrast applied to the pixels that are examined. The radius specifies the number of surrounding pixels that each individual pixel is compared against. The threshold is the level of contrast, which if a pixel exceeds, will be sharpened according to the amount value. An advantageous side effect (in terms of the “pepper fogging” lith-effect) of the threshold variable, is that it will introduce random noise if the level is declared relatively small. By setting this value to zero, all pixels are sharpened, and a large proportion of noise is generated. Because all the pixels are considered when applying this operation, the ConvolveOp can be used to perform the sharpening, and the radius value of 10.0 can be specified via a 10 by 10 matrix, with each coefficient assigned the value 1/100. To enhance the grain effect, the grain image is then combined with the original shadow image, using a darken algorithm. This procedure involves comparing each pixel of the base image (in this case the shadow image) with the corresponding pixel in the source image (the grain image). Any base pixel that is lighter than the source pixel is substituted for that of the source pixel. If the base pixel is identical or darker than the source pixel it remains unchanged. The darken operator was implemented by simply comparing brightness values for each shadow pixel with the corresponding grain pixel, and making the necessary alterations to the shadow image depending upon the results of the comparison. Although the process of applying grain is theoretically a good idea, a decision was made to exclude this operation from the lith effect due to impracticalities. The problem with the grain procedure is that, if the shadow image has a low contrast (i.e. light shadows), then the effects of the gain on the image are not always apparent. Also, repeatedly applying a BufferedImage to a ConvolveOp with a 10 by 10 matrix is a time consuming operation, which can dramatically slow down the development process. Considering that there are already three

42


image manipulation operations to be performed per second during development, and the application of the grain is not always effective, it was therefore dismissed from the lith algorithm. A refinement of the grain effect, possibly investigating alternative coefficient values and running the lith simulation on more powerful PC’s, may provide more consistent results. An option could be provided for the user to decided whether the grain effect is applied depending upon the specification of the machine that is running the simulation. But, due to time constraints, these possibilities were not investigated. 5.4.3 Mid-tones and Highlights In comparison, the mid-tones and highlights line graph shown in the example Figure 5.3, performs a less complex operation by essentially clipping the dark tones of the source pixels that fall below the threshold brightness value 90. The brightness values above the threshold are applied to a linear scale within the range 90 and 255. The code segment below shows how this operation is implemented in the lith algorithm, using the grey-scale range, which will then be applied to a LookupTable. The for-loop calculates the linear scale ratio, and by adding the result to the threshold value, insures that all brightness values below the threshold are automatically clipped.

short brighten[] = new short[65536]; for (int i=0; i<65536; i++)

brighten[i] = (short)(threshold + ( (double)i / (65535.0 / (65535.0 - threshold))) );

5.4.3.1 Multicoloured mid-tones The next stage of the lith algorithm involves applying the characteristic “warm” colours to the mid-tones. In Photoshop this is achieved by converting the grey-scale image to the HSB model using the Hue/Saturation operation (see Figure 5.5). The HSB colour model is defined by three components: hue, saturation and brightness. The hue represents the colour transmitted from the surface of an object and its value is defined as a degree within the range 0o to 360o. Saturation represents the strength of the colour, with respect to the amount of grey-scale, in proportion to the hue value, and is defined as a percentage. Finally, the brightness indicates the intensity of the colour and is also expressed as a percentage. The Java 2D API cannot construct images to be defined via the HSB model, but the Color class provides a series of methods that allow the conversion of RGB to HSB and the reciprocal of this operation. It must first be noted that before this process is applied, the grey-scale image is reverted back to an RGB model, the reason for this being that the Color class does not provide a method to convert a grey-scale colour value to HSB. The code fragment below shows how the multicoloured mid-tones are generated. The nested for loops traverse through each pixel of the lith image, passing the individual red, green and blue values of the pixel to the RGBtoHSB() method, that returns an array containing the corresponding HSB representation. The HSB data is then modified to create the mid-tone colours and reapplied to the lith image.

WritableRaster lithRaster = lith.getRaster(); ColorModel lithModel = lith.getColorModel(); for (int i=0; i<lith.getWidth(); i++) {

for (int j=0; j<lith.getHeight(); j++) { int[] argb = new int[4]; lithRaster.getPixel(i,j,argb); float[] hsb = new float[3];

43


Color.RGBtoHSB(argb[0],argb[1],argb[2],hsb); if (hsb[2] <= 0.90) { int color = Color.HSBtoRGB(0.085f,0.3,hsb[2]); Object data = lithModel.getDataElements(color,null); lithRaster.setDataElements(i,j,data)

} } }

In the Photoshop tutorial, the suggested values used to create the “warm” tones are 30o for the hue and 30% for the saturation. After experimenting with alternative value combinations for the two variables, it was decided that the values specified yielded the best results in terms of the most lith-like effect, therefore are the values used in the simulation. The first difference between the standard HSB model and the Java 2D HSB model is that Java’s hue, saturation and brightness values do not conform to the standard format, each value is specified as a decimal value within the range 0.0 to 1.0. Obviously, this can easily be resolved by scaling the standard HSB values so that they fall within the decimal range. The hue value can be scaled by 360o (30o = 0.085) and both the saturation and brightness can be scaled by 100% (30% = 0.30). The second discrepancy between the two HSB models is that when paint packages, such as Photoshop, colourize a grey-scale image using the HSB model, there is a particular range of brightness values that are exempt from the conversion procedure. This range of values is called the “fall-off” and is a pre-defined constant (although for non-grey-scale images the fall-off can be altered). This property insures that only the mid-tones are colourized and the highlights are retained, which conflicts with the Java 2D HSB conversion that does not have a fall-off value, and so applies the conversion to both the mid-tones and the highlights. Therefore, it was necessary to implement, and experiment with, different fall-off values to exclude the highlights from the conversion process, this is expressed via the if statement within the loop, which insures that any pixel with a brightness value above 90% retains it original RGB colour. Any pixel with a brightness value below or inclusive of 90% is applied to the hue and saturation “mid-tone” conversion defined above, is then transferred back to an RGB format using the HSBtoRGB() method, and finally reapplied to the lith destination image. 5.4.3.2 Combining Highlights, Mid-tones and Shadows The final stage of producing the lith image involves combining the shadow and mid-tone/highlighted images. The first method that was considered involved superimposing a partially transparent shadow image onto the mid-tone/highlighted image. This is achieved by blending the colour and alpha values of each pixel from the two images using a composite rule that specifies how the values are combined. The Porter-Duff rules are a selection of composite operations that are entirely dependent upon the alpha component. The resultant pixel colours and alpha values, after the rule has been applied, are determined by the following equations [JK99]: Pixel colour = (αs * fs * cs) + (αd * fd * cd) Alpha value = (fs * αs) + (fd * αd) Where αs and αd are the source and destination alpha components, cs and cd are the source and destination colour values, and fs and fd are the source and destination fractional definitions that are defined specifically by the composite rule being used. The Java 2D API implements eight

44


of these rules, the most appropriate of which is the source-over-destination composite rule, that blends the source image (in this case the shadow image) on top of the destination image (the mid-tone/highlighted image). In this instance, the fractional values are defined via the following expressions: fs = 1.0 and fd = 1.0 - αs. The Graphics2D class contains a method that can apply a composite operation to the drawing surface, the setComposite() method, which takes an instance of the AlphaComposite class as one of its parameters. An AlphaComposite object is defined via a composite rule and alpha component; this class is also part of the 2D API. This procedure insures that the source image will be rendered with its opacity reduced by a percentage specified by the alpha value and then combined with the destination image using the composite rule. But, there are various drawbacks associated with using the composite rule approach to combine the two images. The first problem is concerned with how the composite is applied and how it affects the realism of the lith development process. Although the composite is defined as an image combination operation, it also uses the principles of probability in order to determine if the source pixel should be used, or given preference, over the destination pixel. By assuming the alpha value is the probability that a pixel should be used [HC00], during the early stages of the development process the mid-tone/highlighted alpha value could be greater than the shadow alpha value, which subsequently means it has precedence over the shadow pixel. During development, the user should observe the shadows appearing before the mid-tones begin to gain formation. But, using the composite operation (and depending on the extent the image has been exposed) the mid-tones gradually form in the early stages of development and then the shadows suddenly appear when the alpha value of the shadow image pixels surpass those of the mid-tones. This resulted in an unrealistic development process. In an attempt to combat this problem, different composite rules and alpha values were considered, but this lead directly to the occurrence of the second problem. Attempting to understand how the changing rules/values affected the destination image became an increasingly complex task. This was extenuated by the fact that results can depend on whether the composite operation is performed directly to the drawing surface or rendered off-screen and whether the destination image has an alpha channel or not, in which case the composite rules can apply their calculations differently. Hence an alternative approach was considered. The second method uses the principle of direct pixel by pixel multiplication. This instantly overcomes the problems of the composite technique because multiplying the base pixel colour by the source pixel colour results in a destination pixel that is always darker than the original base colour, therefore the shadows will always be rendered before the mid-tones are formed. Another advantage is that if the base colour is white, the destination pixel will remain unchanged. This is useful as it maintains the separation of the highlights and shadows, one of the essential properties of the lith effect. The 2D API does not provide a multiply operation for a BufferedImage object, but it is relatively straightforward to calculate the multiplication of each individual pixel, this is shown in the code fragment below:

for (int i=0; i<lith.getWidth(); i++) {

for (int j=0; j<lith.getHeight(); j++) { double[] shadowSample = new double[1]; double[] highlightSample = new double[4]; double[] lithSample = new double[4]; shadowRaster.getPixel(i,j,shadowSample); highlightRaster.getPixel(i,j,highlightSample); for (int k=0; k<4; k++) lithSample[k] = shadowSample[0] * highlightSample[k] / 65535.0;

45


lithRaster.setPixel(i,j,lithSample);

} }

The loop traverses through each pixel location of the resultant lith print. Both the shadow and mid-tone/highlighted images are of the same dimensions, so the corresponding shadow and highlight pixel values are obtained from these images, respectively. Because the shadow image is grey-scale and the highlight and lith images have RGB encoding, each of the three RGB highlighted pixel components are multiplied by the shadow pixel and then scaled by 65535. This insures that the destination pixel of the lith image is within the range of 0 to 255. Figures 5.6 and 5.7 show examples of similar lith prints developed in the simulation with different contrast levels (see the next section for more details concerning contrast characteristics of a lith image). Although the resultant lith image is inflicted with a degrade in image detail due to the application of the multiplication operation, it is negligible unless closely examined, and is still a more effective and realistic approach to development than the composite operations. 5.5 Contrast Control Although contrast control is typically associated with the exposure of a lith print, it is implemented in the lith algorithm code, the reasons for which are indicated below.

Figure 5.6: highlights = 35% Figure 5.7: highlights = 95% As described in section 2.2.2, printing paper is available in a series of grades that have different levels of contrast (i.e. separation of light and dark tones), and are defined via characteristic curves. One of the objectives of the simulation was to provide the user with a selection of different paper grades for them to experiment with in order to create a wider variation of lith prints. Initially, a drop down menu was considered, via which the user would simply select a graded number, that had a corresponding contrast value, which would be substituted into the lith algorithm. But, during the development of the “lith-effect” code, it became apparent that a better approach was available. As already mentioned, the shadows, mid-tones and highlights are separated using two LookupTables, the implementation of which is based on Photoshop’s “Curves” function. Each curve operation has a threshold value that determines the dark and light contrast levels in the resultant print, therefore, a feature was built into the simulation that allows the user to alter the threshold values directly.

Figure 5.8: Development Control frame

46


Figure 5.8 shows the development control frame, which contains two JSlider bars, that the user can manipulate to specify the level of shadow and highlight contrasts in the resultant lith print. Each JSlider is divided into one-percent intervals within the range 0% to 100% and the threshold value can be within the range 0 to 65535 (because the exposed image has 16-bit grey-scale encoding). So, if the user selected 50% on the shadow JSlider and 70% on the highlight JSlider, the threshold values would be 32768 and 45875 respectively. This approach provides the user with 10000 possible contrast characteristic combinations providing more choice and functionality, it was also relatively straightforward to implement, by simply passing the threshold values to the Lith class and substituting them into the LookupTable declarations.

6. Testing 6.1 Usability Testing Sections 6.1.1 to 6.1.3 describe the most important design modifications that were made to the Lith Printing Simulation prototype, throughout the iterative design process, that were a direct result of user testing. Section 6.1.4 Describes the deployment of the test plan and the results accumulated from the final stages of user testing. 6.1.1 Synchronisation Problems during Real Time Exposure A problem that was highlighted during user testing was the occasional unresponsiveness of manipulating the dodging and burning tools during the real time exposure process. As the user excessively moves the position of the tool around the easel window two discrepancies occur. Firstly, the movement of the tool appears to slow down as the Java 2D graphics component repeatedly attempts to redraw the tool image. Secondly, the user interface thread fails to relinquish its control from the easel frame, effectively preventing the timer from progressing. The latter problem causes the exposure process to temporarily stop until the user releases the exposure tool from the mouse event. This problem was partially resolved by applying synchronisation to the easel class. When two or more threads require shared access to the same object, or access to the same method declarations, problems can occur if the same objects and methods are called simultaneously by the multiple threads. Although it was difficult to establish the exact cause of the problem, the most viable conclusion is that when the user moves the exposure tool, the setToolPosition() method is called in the Easel object to update the tool co-ordinate data in the ExposureTool object. At the same time, the Exposure object can call the getToolPosition() method from the Easel object (the position is required so that the tool object can be applied to the exposure algorithm). So, as the user moves the tool across the easel window the setToolPosition() is constantly being called, subsequently the co-ordinate data is constantly being updated, which will cause the UI thread to deadlock and prevent notification of the exposure thread and also prevent the getToolPosition() method being called. To prevent a deadlock situation, the getToolPosition() is labelled as “synchronized” in the Easel class. When the Exposure class calls the method it essentially locks the object, preventing other method calls interrupting the current operation. Once the Exposure object has obtained the co-ordinate data, the object is unlocked and the user can continue to move the exposure tool. Although the responsiveness of the exposure tool can still be relatively slow (the responsiveness differs across different operating systems and workstation specifications), the Exposure thread does not consistently deadlock.

47


6.1.2 “Off-line” Exposure processing While observing the user during testing, it became apparent that they became disinterested during the exposure process when not utilising an exposure tool. Basically, the user is expected to watch the timer gradually tick away until it reaches zero (or until the user decides to stop the timer). Obviously this is not an idea predicament, especially if the exposure time is more than a minute, in terms of usability. Therefore, it was decided to incorporate an “instant exposure” option that performs the exposure process off line as opposed to real time. The user specifies an exposure time and presses the start button on the timer as previously indicated. But instead of performing the image processing technique approximately every second, the “instant” image processing operation is performed in a continuous loop, with the number of iterations corresponding to the number of seconds specified. During all iterations of the loop, the Exposure class still has to perform the same image processing operations, so although the exposure time will be considerably reduced, it will still not be “instant,” especially for long exposure times. Therefore, the user needs to receive some form of indication that the exposure process is being performed and when it has finished. An advantage of the image manipulation loop is that, while it is processing, any other user action is placed in an event queue until processing is complete. Initially, to provide feedback to the user, the mouse pointer was changed to a clock symbol to indicate processing, but because the loop essentially locks all other operations, the user cannot halt processing by pressing the stop button in the timer window. To enable the user to stop the exposure process, but still prevent other user actions from being performed, the Java Swing ProgressMonitor tool can be implemented. The ProgressMonitor consists of a dialog box that contains a progress bar. When the dialog is displayed it retains focus over the parent component, in this case the simulation user interface, which prevents any other user actions. Although that ProgressMonitor utilises a thread, its only purpose is to check the current iteration of the exposure loop, in order to compute the completed percentage of the exposure operation and subsequently update the progress bar. The progress bar closes when the task is complete or if the user presses the cancel button, which will halt exposure. Name The Progress Dialog. Problem The user needs to perform the exposure process quickly and be

provided with information relating to the progress of exposure. Usability Principle Provide Feedback Solution A progress bar indicates the gradual progression of exposure over time

and the percentage of completion. Enables the user to interrupt the exposure process and prevents any other user actions with the simulation interface.

Figure 6.1: The Progress Dialog User Interface Design Pattern

48


6.1.3 Rate of Development A suggestion made by a user, who has experience with photography, during testing, was that they felt the gradual development of the image was too excessive and that it did not provide enough choice in terms of the variation in resultant prints. The scale value of the development process is 0.1, which relates to ten passes before the image is fully developed (in terms of the darkest tones being visible to the user). Although the development period of the actual lith process is a relatively time consuming process, it would not be a good usability attribute to apply actual development periods that can take up-to half-an-hour. Therefore, an option was built into the simulation that enables the user to select either “Quick-Time Development” that applies the scale value defined above, or the so-called “Real-Time Development” that applies a scale value of 0.01. The latter option takes 100 passes before the image is fully developed, which should take approximately two minutes to process, but will provide a greater range of possible resultant prints. This option provides a balance between speed of performance, and greater user preference, in terms of the desired goals. Name The Development Speed Option. Problem The user requires more control over the rate at which the image

gradually develops over time. Usability Principle Adaptability Solution A development speed option that enables the user to select a

development time via a radio button.

Figure 6.2: The Development Speed Option User Interface Design Pattern 6.1.4 The Lith Printing “on-line” Help Facilities To measure the usability attributes of the Lith Printer, and ultimately predict the quality and learning potential of the simulation, a tutorial and help system has been built into the application that will be used to perform usability testing. The tutorial is available in HTML format via the user selecting the help option from the menu bar. This will launch the default web-browser and display the tutorial files (if a web-browser is not installed or there is an error, a simple Java based HTML navigator has been developed that loads the tutorial files into a JFrame using the JEditorPane which can display documents in HTML format). The tutorial is divided into two parts: 1. The first part provides a description of the user interface components that can be

manipulated by the user and the various options available in the simulation. It also includes a comparison of the simulation with the actual darkroom processes, to enable the user to gain a better understanding the different stages of development i.e. the significance of aperture and exposure, etc. Obviously, this is aimed at the novice user, who has no experience with the simulation or the relevant aspects of photography.

2. The second part provides a step-by-step example, instructing the user how to project, expose and develop a lith print. This part of the tutorial will used in conjunction with the Usability Measurements defined in section 3.5 to determine if the users goals have been satisfied.

49


6.1.4.1 The Lith Print Tutorial Four individuals performed the tutorial (the same individuals were used to test each prototype of the iteration), with one of the participants having experience working in a darkroom environment. The step-by-step guide is defined below:

1. Select File → Open from the menu bar. Navigate to the “images” directory in the Lith Printer home directory and open the “wooden_house.gif” image file.

2. Select Options → Exposure → Real Time Exposure from the menu bar. 3. Select the enlarger window. Reposition the enlarger head to a height of 65.0cm by

dragging the enlarger head object down the enlarger column. 4. Select the focus window. Rotate the focus dial so that the focal length is set to 100mm. 5. Select the aperture window. Use the directional arrows to adjust the brightness to f-

number 8. 6. Select the easel window. Move the projected image so that it is perfectly aligned with

the bottom right-hand corner of the easel frame. Then adjust the horizontal and vertical arms so that there are no white paper borders surrounding the projected image.

7. Select the square dodge tool from the exposure tool window. Set the dodge tool to maximum coverage by dragging the tool object in the enlarger window towards the enlarger head. Finally, position the dodge tool to the right of the projection in the easel window.

8. The easel window should now correspond to the screen capture shown in diagram 1. 9. Select the timer window and set the timer display to 40 seconds. 10. Start the timer. 11. Gradually move the dodge tool right to left across the easel, for roughly 25-30

seconds, and stop approximately ¾ over the projected image. Select the ‘X’ button in the exposure tool window to remove the exposure tool from the easel. Wait for the timer to stop.

12. Select the develop button in the development window. 13. Stop the development process when the shadows have reached their darkest contrast,

i.e. there will be areas of black tones that separate the light tones. 14. The developed image should now correspond to the image shown in diagram 2.

Diagram 1 Diagram 2

6.1.4.2 Tutorial Results The tables below indicate the measurement evaluation for the three main procedural tasks of the lith print process: projection, exposure and development; and correspond to the tables defined in section 3.5. The most important attributes, with regards to the results, are highlighted in the tables. The Current level attribute indicates the average score the users attained when testing was performed on the previous iteration of the prototype model. The

50


Observed Results attribute tabulates the score attained by the expert and three novice users and the Result attribute is the averaged value of the Observed Results.

Measurements Observations Value Usability Attribute Manipulation of the Enlarger components. Measuring Instrument The user is expected to set the magnification, focus and

brightness according to the example given in the tutorial. Tutorial

Value Measured The ability of the user to successfully alter the enlarger head, focus dial, and aperture dial.

Range: 0 - 2

Current Level Problems adjusting the focus dial. 1 Worst Acceptable Level The user is unable to adjust any of the interactive

components. 0

Target Level The user can adjust the interactive components, but the magnification, focus and brightness values are incorrectly specified

1

Best Possible Level The user can adjust the interactive components and the magnification, focus and brightness values are correct.

2

Expert User 1 Novice User 1 2 Novice User 2 2

Observed Results

Novice User 3 1 Result 1.5

Table 6.1: Enlarger Manipulation Usability Measurement Results

Throughout the iterative development process, the users have been able to consistently manipulate the interactive components to the required level of accuracy, with the exception of the focus dial. Initially, the focus dial was controlled by simply clicking on the dial image and then dragging the mouse in any direction to make the dial rotate, when the rotation reached the maximum focal length of 120mm (360o) it was automatically reset to zero. This was deemed too confusing by the users, as the dial continued to rotate in a clockwise direction, as opposed to reaching the maximum value and then rotating in an ant-clockwise direction to reduce focal length as a real dial would behave. This feature was built into the interface: by clicking on the dial and dragging the mouse to the right the dial moves in a clockwise direction, by dragging the mouse to the left the dial moves in an ant-clockwise direction. When the maximum and minimum values are reached the dial is prevented from rotating any further until the user moves the mouse in the opposing direction to rotation. Unfortunately this failed to completely resolve the problem. If the user moves the mouse rapidly when manipulating the dial, because the mouse pointer is prevented from moving any further than the confines of the screen boundary, the user essentially runs out-of space to continue rotating the dial. This is highlighted in the results, as the best possible level was not obtained after the previous prototype reached the target level. Apart from this minor problem, the enlarger components adequately fulfil the goals and requirements of the user.

Measurements Observations Value Usability Attribute Exposure Process Measuring Instrument The user is expected to set the timer, start the exposure

process, and then manipulate an exposure tool, as indicated in the tutorial.

Tutorial

Value Measured The ability to perform the exposure technique and control the exposure tool.

Range: 0 - 5

Current Level Problems manipulating the exposure tools during the exposure process.

3

Worst Acceptable Level The user is unable to start the exposure process or manipulate the exposure tool.

0 - 1

Target Level The exposure process is initiated and basic control of the exposure tool is achieved.

2 - 3

Best Possible Level The exposure process is initiated and the user is able to 4 - 5

51


perform all the required exposure tool commands, such as movement, scaling, rotation and removal. Expert User 4 Novice User 1 4 Novice User 2 2

Observed Results


Table 6.2: Exposure Process Usability Measurement Results The result obtained from the exposure process just exceeded the target level, and marginally improved on the previous usability level. Although the users did not experience any fundamental difficulties, the synchronisation problems that are indicated in section 6.1.1 hindered their performance during the process. Because the simulation was considerably slowed down during exposure, specifically the movement of the exposure tool, the user simply relinquished control of the tool as a means of resolving this problem. Overall, the test users understood the application of the tools and were able to perform most of the tasks specified in the tutorial to a reasonable degree of accuracy.

Measurements Observations Value Usability Attribute Development Process Measuring Instrument The quality of the lith image after development in

comparison to the expected image provided in the tutorial. This will assume that the Exposure Process has already been completed.

Tutorial

Value Measured The visual appearance of the image. Range: 0 - 5

Current Level No specific problems. 4.5 Worst Acceptable Level The image is not developed or the developed image is

totally underexposed or overexposed so that there is no image detail apparent to the observer.

0 - 1

Target Level The image has been correctly developed, with an adequate range of shadow/highlight separation, but is distinguishable from the example given in the tutorial.

2 - 3

Best Possible Level An obvious shadow/highlight and black/colour/white split of the developed lith image that corresponds very closely with the example given in the tutorial.

4 - 5

Expert User 5 Novice User 1 5 Novice User 2 4

Observed Results


Table 6.3: Development Process Usability Measurement Results The development process consistently performed well under user evaluation, probably due to the simplicity involved, because all the user is expected to do is examine the gradual development of the image and then press the stop button to halt the process. But, the validity of this measurement is questionable because it depends directly upon the correct application of the exposure process and the effectiveness of the lith algorithm. The former has proven to be successful from the results defined in table 6.2 and the latter has undergone extensive evaluation during implementation. Therefore, the development process can been considered an extension to the exposure process usability measurements. Hence, the overall usability and learning potential of the simulated lith effect can subsequently be considered: (3.25 + 4.5)/2 = 3.875.

52


6.2 Specification (“Black Box”) Testing The specification based testing was a relatively straightforward task on account of the limited input set. There are only five variables defined that allow the user to exactly specify the input value: the enlarger head height, focal distance, the horizontal and vertical position of the easel sliders, and the burn tool ratio. Each variable has a specific range of values, the “boundary” [JW00], that it is permitted to accept. Any value that exceeds this range must be caught by the user interface and prevented from being applied to the simulation. This is vital for the variables that control the image manipulation; for example, the enlarger head height must not exceed 70.0cm to prevent the maximum magnification of the projection from being miscalculated. Because all the input values are numerical A logical assumption would be to check for negative and character input values. But as already indicated in the design section 4.2.3.8, the DoubleTextField object automatically rejects any non-numerical input.

Variable Boundary Input Expected Output Output Any value

between 0.0 and 70.0

The enlarger head will be repositioned. The magnification will be calculated and applied to the projected image in the easel window.

Correct Enlarger Height (E)

0.0 <= E <= 70.0

75.0 A help window will be displayed confirming the input is out of range.

Correct

Any value between 0.0 and

120.0

The enlarger focus dial will be repositioned. The focus value will be calculated and applied to the projected image in the easel window.

Correct Focal Length (F) 0.0 <= F <= 120.0


Correct


34.0

The vertical arm will be repositioned

Correct Vertical Easel Arm (V)

0.0 <= V <= 34.0


Correct


49.0

The horizontal arm will be repositioned.

Correct Horizontal Easel Arm (H)

0.0 <= H <= 49.0


Correct


Correct


90.0

The dialog bow will close indicating it has accepted the value.

Correct

Burn Tool Ratio (R)

10.0 <= R <= 90.0


Correct

Table 6.4: Specification Testing Results Although there are other data inputs, such as aperture and contrast control, these are all controlled by JSlider bars, which have built-in input boundaries predefined by the minimum and maximum value ranges. The Specification testing also extended to other forms of input,

53


such as selecting options from the menu bar, but have been omitted from the report due to space restrictions. For example, opening a file would require many different boundary tests depending upon the situation, i.e. a file may not exist, it maybe be corrupted or of the wrong file format, etc. 6.3 Implementation (“White Box”) Testing The implementation test sets were derived from an examination of the program structure; i.e. examining the code and evaluating all the paths that are executed in a sequential order [MR94]. Due to the large amount of code and the time restrictions during testing, it was an unrealistic proposition to perform an extensive evaluation of the code. Therefore the implementation testing has been applied to the next level of functionality by considering important structural points in the program. For example, the linear sequence of commands which are executed during the exposure process between starting and stopping the timer. The structural elements identified for the exposure process are defined in the flow-graph shown in figure 6.3. Performing implementation testing proved useful because it highlighted points in the program code that required exception handling. For example, the segment in the code that determines whether the timer is set above zero or whether a projected image is available for exposure, is a prime example of a process that needs to catch user errors. If the exposure process is initiated without a projected image, then the simulation will throw a run-time exception by attempting to perform image manipulation with null image data.

Figure 6.3: Flow-graph for the Exposure Process

Another important feature that was initially overlooked, but was made apparent during implementation testing, was the manipulation of the enlarger components during exposure, for example, altering the magnification of the projection while the timer is still running. The initial

54


method of resolving this problem was to lock the interface component to prevent the user altering the variables. This proved relatively straightforward for the interactive components, simply declaring a Boolean variable “lock” that if “true” restricted the mouse events being applied to the components. But proved more difficult for the Swing JComponents, such as the JSlider and DoubleTextField, which could not be disabled. The second method was for the user to manipulate the components and the subsequent alterations being applied directly to the exposing image. This was considered too complex because not only would the exposure algorithm have to detecting the manipulation of the exposure tools in the easel window but also every other user action that was performed. This would not be problematic for focus and aperture operations, but if the projection was magnified and repositioned or the paper was resized, then the exposing image would have to be scaled appropriately which would require complicating the exposure algorithm further and would also dramatically degrade real time performance. Therefore a compromise was reached, where-by the user can manipulate the components during exposure, but this has no impact on the resultant image. This is not an ideal solution because it does not replicate real darkroom procedures, but provides an adequate restraint for the purposes of the Lith Printing simulation.

7. Evaluation

7.1 Examination of original Objective In the analysis section, a task list was presented that identified the objectives of the Lith Printing Simulation, after extensive user analysis had been performed. The table below tabulates and reconfirms these objectives, indicating the extent to which they were implemented in the final application. Task Description Implementation

1 Choice of negatives Complete 2 Control of darkroom equipment (enlarger, focus, aperture) Complete 3 Adjust paper size and position of projection Complete 4 Selection of paper contrast grades Partial* 5 Specify exposure times (control of a timer device) Complete 6 Exposure tools (dodging, burning, flashing) Partial 7 Real time exposure Complete 8 Adjust development solution intensity Partial* 9 Real time development and “Snatch Point” Complete

10 Lith effect algorithm Complete 11 “Pepper fogging” No 12 Tracing movement of paper through the development process No 13 Post development toning No 14 Help facilities Complete 15 Graphics package facilities (load, save and print) Complete 16 Java Applet version of the simulation No

Table 7.1: Evaluation of tasks 7.2 Combining Contrast Control and Solution Intensity* A requirement that was conceived in the early stages of development was the ability to change the contrast grades of the paper (Task 4), which would result in the recalculation of the Characteristic Curve, determining the separation of the light and dark tones. Because the lith algorithm uses contrast curves to separate the shadows and highlights it seemed appropriate to build contrast control into the lith procedure. Obviously, this does not emulate real

55


photographic principles, because contrast is primarily concerned with paper grade and exposure, however a key factor relating to contrast control in lith printing is the “function of exposure vs. development irrespective of the grade of paper user” [TR98]. The highlights of the lith print are specifically controlled by the exposure and the shadows are controlled by the intensity of the development solution (Task 8). This provided sufficient evidence to relate paper contrast with solution intensity and combine both processes in the simulation. The implementation of contrast control is given in section 5.5. 7.3 Suggestions for Improvement of Simulation The tasks that have been label as “Complete” have been implemented in the simulation and have had full justification, explanation and evaluation in the previous sections. But, it is necessary to provide a brief explanation concerning the objectives that were partially completed or omitted from the final version of the simulation, and also provide suggestions for future improvements and amendments. 7.3.1 Tracing movement of paper through the development process This objective was never fully considered or realised during the iterative design process, the main reason being that the remaining development solutions, namely the stop bath and the fixer, were never implemented. The prime concern during implementation was to create a lith algorithm that produced a realistic lith-effect during the development of the print; future implementation would require expansion of the algorithm to incorporate the visual appearance of the developing image in the different development solutions. The original concept of “tracing” the movement of the paper was based on the idea of “drag and drop.” For example, the user selects a paper icon that is located at the base of the enlarger object in the enlarger window and then drops the icon in a developer tray object by dragging it into the development window. Once the development process is complete, the user can continue to drag and drop the paper between the remaining tray objects. The Java programming language provides a drag and drop facility as part of its AWT package, which is specifically designed to transmit data between a number of Java applications, but the same technique can be used to transmit data between internal frames of the same application. Elements that are to be transferred (in the case the paper icon) can be defined as a DragSource object and the components that are to accept the dragged object can be defined as a DropTarget object (the development trays). The internal frames that are involved in the drag and drop routine would implement the DragSourceListener and DropTargetListener respectively. These listeners provide method routines that can detect and accept a drag and drop operation, analyse the format and data of the dropped object, and also provide feedback to the user. The drop() method is called whenever a user completes a drop action and could contain the exception handling that, for example, prevents the user moving the paper icon to the fixer tray before it has been passed to the developer tray, this would be indicated to the user by changing the status of the mouse pointer. A possible difficulty in implementing this feature is that Java’s drag and drop functionality currently only supports file handling and the transference of text. To drag and drop images, the image encoding would need to be converted to a text format, in a similar way to the encoding of e-mail image attachments into plain text using the MIME (Multipurpose Internet Mail Extensions) conversion [HC00]. 7.3.2 Refinement of the Exposure Class The synchronisation issues that exist between the Exposure thread and the user interface thread, when the user manipulates the exposure tools, is the main design problem that prevents the simulation attaining the best possible level of usability.

56


Figure 7.1: Observe Design Pattern

The use of the Observer design pattern could provide a more efficient approach to the structure of the class hierarchy. This design pattern defines “a one-to-many dependency between objects so that when one object changes state, all its dependants are notified and updated automatically” [GHJV95]. The easel object would act as the observer and pass a request to the exposure class, which would determine if the exposure tool could be manipulated, then pass back notification to the easel (shown in Figure 7.1). Currently there exists only one-way communication directed from the exposure object towards the easel object, essentially attributing all control to the exposure thread, which could explain why the easel thread occasionally deadlocks, as it has no direct communication with the exposure thread. 7.3.3 Advanced Exposure Tool Features The “Flashing” tool was omitted from the final implementation due to the complexities of expanding the exposure algorithm to incorporate this feature (a full explanation is provided in section 5.2.4). Although the existing exposure tools performed extremely well during testing, more functionality could be introduced to provide the user with a greater variation of options during exposure. The main feature would be for the user to define their own dodging and burning tools. One method would be to load the tool image using a file dialog similar to the existing method of loading a negative image. But this must assume that the user has saved the tool image in GIF format, and that the transparency option has been applied, so that only the outline of the tool is visible and not the background colours. Another method would be to include a simple drawing program in the simulation that allows the user to create, save and apply tool objects directly to the easel. 7.3.4 Toning and “Pepper Fogging” The inclusion of colour toning and fogging would require additional refinements to the lith algorithm. As detailed in the implementation section, a fogging operation was defined that applied random noise but introduced system degradation during the exposure process, obviously this is an area for further investigation. A method of applying toning would be to use the HSB colour model to change the hue and saturation of the mid-tones of the lith image so that they conform to a particular colour range, for example, a gold toner would produce a range of light blues or purples. Further expansion could include the emulation of sepia toning and bleaching processes to control the colours of the completed lith print. 7.3.5 Applet Version of Simulation Initially, it was proposed that an applet version of the Lith Printing Simulation would be developed so that it could be distributed amongst a larger number of users over the Internet. This would have proved useful during usability testing to provide a greater test user domain, but the objective had to eventually be rejected. The first problem encountered was that the user interface was relatively complex, in terms of the number of internal windows and user interactions that occur, which made the conversion to an applet version increasingly difficult because of the limiting factors of embedding a single program into a web-page. To resolve this problem it is possible to create “pop-up window” applets that are contained within a JFrame.

57


Experimentation with this approach proved to be unsuccessful because the simulation was slow to download and also displayed warning messages (that are part of the web browser security features). But the most fundamental drawback of using applets is that the most popular web browser programs, such as Internet Explorer and Netscape, do not have the latest Java version or all the features implemented, respectively. So, unless a user has installed the Java Plug-in browser tool [SUN3], some of the more sophisticated elements, such as the Swing components, cannot be used in an applet version of the simulation.

8. Conclusion During the development of the Lith Printing Simulation there were two primary objectives that needed to be fulfilled: 1. To create a tool that was capable of teaching the concepts of lith printing and darkroom

procedure to the user. 2. To define a “lith-effect” algorithm that could emulate the visual properties of a lith image. Both of these objectives have been satisfied to a certain degree of success and have been combined in the resultant program to provide a Computer-Based Learning application that can also be used as a digital image processing tool. The learning potential and usability of the simulation was evaluated by continual user testing, the results of which indicated problems with the existing prototype, which were resolved in the next successive iteration of design and implementation. The results obtained from the final evaluation of the application indicated that the users, the majority of whom had no prior experience with photography, were able to follow the darkroom procedure and produce a lith print image to a high level of accuracy. The application interface provides an adequate visualisation of the photographic equipment required to create a lith print, most specifically the enlarger device, and also provides a detailed “on-line” tutorial pertaining to the purpose of the interface components. The tutorial was central to the usability of the simulation because it defined the testing methodology and also compared the simulation procedures with their equivalent darkroom procedures. This indicated to the users not only how, but also why, these procedures are necessary. The true usability test would be to examine how well the users performed in a real darkroom environment creating actual lith prints. The implementation incorporated most of the task requirements but some of the more advanced features, such as the “flashing” tool and the “pepper fogging” effect, were omitted due to programming complexities. A disadvantage of the design, which negatively influenced the usability of the simulation, was the real time exposure technique that degraded system performance when the user manipulated the dodging and burning exposure tools. This problem would probably benefit from a complete redesign of the multithreading interface and related classes. Another important feature was the implementation of the gradual development of the lith image over time. The user is able to alter the development speed and also determine the “snatch” point of the print. Although the advanced development features were restricted due to time constraints, future amendments to the lith effect would be to visualise how the image reacts when introduced to the remaining solutions such as the fixer and stop bath, and post development processes, such as colour toning. The development of the lith algorithm was based on a tutorial [MP01], providing a step-by-step guide, indicating the relevant digital image processing required to emulate the lith effect. Using the Java 2D API to construct equivalent image manipulation operations in the program code proved to be successful approach to defining the algorithmic properties. Although some of the operations were removed from the algorithm, such as the USM function that was initially used to produce the “fogging” effect, this was for performance reasons not for

58


implementation difficulties. Additional features were built into the algorithm, for example, the variable contrast control that enables the user to specify the intensity of the shadows in relation to the range of highlight intensities. Overall the Lith Printing Simulation provides a basic introduction to a difficult photographic technique and eliminates the time consuming, expensive and unpredictive nature of the actual process.

9. References

[AH97] Darkroom Source, Any Hughes, 1997, http://www.darkroomsource.com [AO01] What is Computer Aided Learning (CAL)?, Andrew Oliver, LTDU: Learning Technology Development Unit, 2001, http://www.herts.ac.uk/ltdu/learning/whatiscal.pdf [APH] Adobe Photoshop Help Files, Adobe Photoshop v5.0 [BRJ99] The Unified Modeling Language User Guide, Grady Booch, James Rumbauhgh and Ivar Jacobson, Addison Wesely, 1999 [CW93] The Creative Darkroom Handbook, Chris Wainwright, Cassell, 1993 [DFAB98] Human-Computer Interaction, Alan Dix, Janet Finlay, Gregory Abowd, and Russell Beale, Prentice Hall, 1998 [DW01] A Darkroom Simulation for Photographic Printing, 3rd Year Project, Duncan Watson,

2001, http://www.dcs.shef.ac.uk/teaching/eproj/ug2001/pdf/u7dww.pdf [FJWC01] Usability Basics for Software Developers. Xavier Ferré, Natalia Juristo, Helmut Windl and Larry Constantine, IEEE Software, pg. 22-29, January/February 2001. [GHJV95] Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison Wesley, 1995 [GM98] JAVA: First Contact, Roger Garside and John Mariani, Course Technology, 1998 [HC01] Core JAVA 2 Volume I - Fundamentals, Cay S. Horstmann and Gary Cornell, Sun

Microsystems Press, Prentice Hall, 2001 [HC00] Core JAVA 2 Volume II - Advanced Features, Cay S. Horstmann and Gary Cornell,

Sun Microsystems Press, Prentice Hall, 2000 [JF98] JAVA Distributed Computing, Jim Farley, O’Reilly & Associates, Inc., 1998 [JK99] JAVA 2D Graphics, Jonathan Knudsen, O’Reilly & Associates, Inc., 1999 [JL96] Visualization and HCI: A brief Survey, Jonas Lowgren, 1996, http://citeseer.nj.nec.com/377176.html [JN93] Usability Engineering, Jakob Nielsen, Academic Press, 1993

59

http://www.darkroomsource.com/

http://www.herts.ac.uk/ltdu/learning/whatiscal.pdf

http://www.dcs.shef.ac.uk/teaching/eproj/ug2001/pdf/u7dww.pdf

http://citeseer.nj.nec.com/377176.html


60

[JN94] Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier, Jakob Nielsen 1994, http://www.useit.com/papers/guerrilla_hci.html [JR94] The Handbook of Usability Testing, Jeffery Rubin, Wiley Computer Publishing, John

Wiley & sons, Inc., 1994 [JW00] What is Software Testing? And Why Is It So Hard?, James A. Whittaker, IEEE Software, pg. 70-79, January/February 2000 [LR01] Building Imaging Applications with Java Technology, Lawrence Rodrigues, Addison

Wesley, 2001 [MGI] Photo Gallery Volume 1, MGI Software Corporation, www.mgisoft.com [ML93] Basic Photography 5th Edition, Michael Langford, Focal Press, 1993 [ML92] Advanced Photography 5th Edition, Michael Langford, Focal Press, 1992 [MP01] Lith Printing - Some Personal Experiences, Marco Pauck, http://www.pauck.de/marco/photo/lith/lith.html [MR94] Software Testing, Marc Roper, McGraw-Hill, 1994 [NM90] Heuristic evaluation of user interfaces, Jakob Nielsen and Rolf Molich, 1990 [SUN1] 2D Graphics Tutorial, Deborah Adair, Jennifer Ball and Monica Pawlan,

http://java.sun.com/docs/books/tutorial/2d/index.html

[SUN2] Java Advanced Imaging API, http://java.sun.com/products/java-media/jai/index.html [SUN3] Java Plug-in, http://java.sun.com/products/plugin/ [TR98] The Master Photographer’s Lith Printing Course, Tim Rudman, Argentum, 1998 [TS00] The Jessops Darkroom Book, Terry Scott, Jessops, 2000 [WG99] Graphics Programming with JFC, David Wall and Arthur Griffith, Wiley Computer

Publishing, John Wiley & sons, Inc., 1999 [WT00] Interaction Patterns in User Interfaces, Martija van Welie, Hallrard Troetteberg, 2000, http://www.cs.vu.nl/~martijn/patterns/PLoP2k-Welie.pdf [WVE00] Patterns as Tools for User Interface Design, Martija van Welie, Gerrit C. van der Veer, Anton Eliens, 2000, http://www.cs.vu.nl/~martijn/gta/docs/TWG2000.pdf [XF01] Incorporating Usability into an Object Oriented Development Process, Xavier Ferre, 2001, http://www.hci.uu.se/~jg/UCD2001/Ferre.pdf

http://www.useit.com/papers/guerrilla_hci.html

http://www.mgisoft.com/

http://www.pauck.de/marco/photo/lith/lith.html

http://java.sun.com/docs/books/tutorial/2d/index.html

http://java.sun.com/products/java-media/jai/index.html

http://java.sun.com/products/plugin/

http://www.cs.vu.nl/~martijn/patterns/PLoP2k-Welie.pdf

http://www.cs.vu.nl/~martijn/gta/docs/TWG2000.pdf

http://www.hci.uu.se/~jg/UCD2001/Ferre.pdf

Documents

Lith Printing Simulation Paul Nicholas Whysall PRINTING SIMULATION.pdf · 1.2.1 Lith printing is difficult? 1 1.2.2 Time consuming 2 1.2.3 Expensive Process 2 1.2.4 “Pepper Fogging”