AstroImage/SRS

Read first:

• http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
• http://en.wikipedia.org/wiki/Software_requirements_specification
• IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

Document History

	Version	Date	Authors	Description	Validator	Validation Date
	0.1.0	18/01/2016	RACHEX, GERRY, BLANC	Creation of this page	TBC	TBC

1. Introduction

1.1 Purpose of the requirements document

The purpose of this SRS document is to provide a detailed overview of our software product, its parameters and goals. This document describes the project's target audience and its user interface, hardware and software requirements. This document is intended for both the stakeholders and the developers of the software.

1.2 Scope of the product

This software system will be a Astro Images Processing System for Amateur astronomers. It will be designed to preprocess and process astronomical images. By maximizing preprocess and process efficiency, the system will meet the customers’ needs while remaining easy to understand and use.

1.3 Definitions, acronyms and abbreviations

• LIGHT : It's a gross astronomical image (not preprocessed). It contain lots of information about celestial objects, but also many electronic noise or artifacts which degrade the image (thermal noise, random noise, sky glow, read noise, etc., dusts on the matrix CCD or on the filters, cosmic rays, passages of artificial satellites or falling stars, sometimes a gradation caused by the light pollution or internal or infrared bright reflections)

• DARK : Image ideally taken at the same temperature, binning and even with the same exposure time as LIGHT images, but with the cover in front of the telescope objective. The goal of DARK pictures is to capture defects (noise and interfact) which degrade the LIGHT image.

• MASTER DARK : It's important to take a series of at least about fifteen images DARK and to combine them by sigma reject without normalization to make a MASTER DARK. It's this the one who will allow to correct the presences of noises, space rays and other defects on the LIGHT.

• FLAT FIELD : Images taken by a surface or a bottom of sky enlightened uniformly. These images will serve to capture gradations, dusts, vignetting present in our LIGHT images.

• MASTER FLAT : It's obtained by combination by sigma reject with normaliation. A good MASTER FLAT corrects the images of dusts and vignetting of the optics and certain gradients. But he is not compulsory and can sometimes degrade the image.

• THERMAL NOISE : Hot pixel caused by the thermal noise produced by camera electronics.

• RANDOM NOISE : Electronic noise which is totally unpredictable

• SKY GLOW : Noise caused by the light pollution

• READ NOISE : Noise caused by the image download

• DITHERING : It consists during the acquisition of the images, to move slightly the telescope of some pixels between each of the LIGHT images to create a light movement between the images. We can so eliminate totally artefacts (hot pixels, space rays, tracks of plane, meteors, etc.) during the combination(overall) by SIGMA CLIP (SIGMA REJECT).

1.4 References

IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

1.5 Overview of the remainder of the document

The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.

2. General description

2.1 Product perspective

The goal of this project is to develop a processing chain of image stemming from spotting scope (processing software).

2.2 Product functions

This product must be able to realizing the processing chain of the astronomical images. These functions will be retailed in the corresponding section.

2.3 User characteristics

Users of this product are amateur astronomers, who have some knowledge in astronomical image processing and computing. But these users aren't experts in these two domains.

2.4 General constraints

• The software must be developed in Python, with Kivy for the UI.
• Each set of input images are images RAW or FITS
• Output images are TIFF or FITS

2.5 Assumptions and dependencies

This project haven't any assumptions and dependencies

3.Specific requirements, covering functional, non-functional and interface requirements

3.2 Functions

3.2.1 File RAW reading - Demosaicing (in Structured Natural Language)

Description: File RAW has to undergo a demosaicing

Inputs: File RAW

Source:

Outputs: Array of pixels

Destination: Image processing functions

Action:

• Open the File
• Apply a demosaicing algorithm to obtain an image
• Transform this image into array

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2.2 Creation of Master Dark (in Structured Natural Language)

Description: Dark fields capture the inherent noise to the CCD array, which we would like to eliminate so the sensor doesn’t contaminate the light we’re collecting from the night sky

Inputs: Set of Darks (set of pixel array)

Source:

Outputs: MasterDark (pixel array)

Destination: Calibration of Lights & Creation of MasterFlat

Action:

• Create a sigma reject array from all of them, entry-by-entry

Non functional requirements:

Pre-condition: All pixel arrays must have the same size.

Post-condition:

Side-effects:

3.2.3 Creation of Master Flat (in Structured Natural Language)

Description: Flats are images portraying the sensitivity of individual pixels in the frame, which is illuminated uniformly

Inputs: Set of Flats (set of pixel array)

Source:

Outputs: MasterFlats (pixel array)

Destination: Calibration of Lights

Action:

• Subtract the master dark frame
• Normalize all frame
• Create a median array from all of them, entry-by-entry.

Non functional requirements:

Pre-condition: All pixel arrays must have the same size.

Post-condition:

Side-effects:

3.2.4 Calibration (in Structured Natural Language)

Description: Subtract a MASTER DARK of all the LIGHT images to remove the electronic noise and divide the resultant image by the MASTER FLAT FIELD to correct the difference of pixel sensibility

Inputs: MasterDark, MasterFlatField, Set of Lights (pixel arrays)

Source:

Outputs: Set of lights (pixel array)

Destination: Registration of Lights

Action:

• Use masterflat and masterdark to clean up each light frame : (Light - MasterDark) / MasterFlat

Non functional requirements:

Pre-condition: All pixel arrays must have the same size.

Post-condition:

Side-effects:

3.2.5 Registration (in Structured Natural Language)

Description: Combine a set of lights in one to obtain more information and delete deviants pixels and interfacts (satellites, airplanes, etc.)

Inputs: Set of lights (set of pixel arrays)

Source:

Outputs: Light (pixel array)

Destination: All image processing functions

Action:

• Translation and rotation of lights relative to a reference light (all the images have to be perfectly superposables)
• Combine these lights

Non functional requirements:

Pre-condition: All pixel arrays must have the same size.

Post-condition:

Side-effects:

3.2.6 Adjustment of the contrast (in Structured Natural Language)

Description: Adjust the image contrast

Inputs: pixel array, gain value

Source:

Outputs: pixel array

Destination: All image processing functions

Action:

• Logarithmic correction : result = (vmax-vmin) * gain * log2(1 + pixelArray/(vmax-vmin))
• Gamma correction : result = ((pixelArray / (vmax-vmin)) ** gamma) * (vmax-vmin) * gain

Non functional requirements:

Pre-condition: The Image must be an RGB pixel Array

Post-condition:

Side-effects:

3.2.7 Noise deletion (in Structured Natural Language)

Description: Removing noise from a picture

Inputs: pixel array

Source:

Outputs: pixel array

Destination: All image processing functions

Action:

• Use a median filter

Non functional requirements:

Pre-condition: The image must be an RGB pixel array

Post-condition:

Side-effects:

3.2.8 Ajustment of the saturation (in Structured Natural Language)

Description: Correct the saturation

Inputs: pixel array, gain

Source:

Outputs: pixel array

Destination: All image processing functions

Action:

• P = sqrt( RedPixel*Pr + GreenPixel*Pg + BluePixel*Pb )
• NewPixel = P+(pixel-P)*gain

Non functional requirements:

Pre-condition: The image must be an RGB pixel array

Post-condition:

Side-effects:

3.2.9 Ajustment of the luminosity (in Structured Natural Language)

Description: Correct the luminosity

Inputs: pixel array, gain

Source:

Outputs: pixel array

Destination: All image processing functions

Action:

• pixelArray^gain * (vmax-vmin)^(1-gain)

Non functional requirements:

Pre-condition: The image must be an RGB pixel array

Post-condition:

Side-effects:

3.3 Performance requirements

Performance requirements define quality and security rather than response time for system functionality. Indeed, computation times required for the algorithms of astronomical image processing are long. It's more important to have a software working correctly, that a software quickly working. The optimization isn't our main purpose.

• User satisfaction : The software is such that it stands up to the user expectations.
• User friendliness : The sofware must be easy to learn and undersand for a not expert user.
• Image quality : The sofware has to keep the initial image quality.
• Error handling : Response to user errors and undesired situations has been taken care of to ensure that the system operates without halting.
• Safety and robustness : The software is able to avoid or tackle disastrous action. It safeguards against undesired events, without human intervention.

3.4 Logical database requirements

The system doesn't use a database.

3.5 Design constraints

There aren't factors in the client's requirement that may restrict the choices of a designer. But there are some standars that must be followed; standard that shares a lot of image processing software (whites balance, color palettes, histogram, etc.). Respect these standard allows this software to be easily taken over by the user.

3.6 Emergent system properties and quality characteristics

• Maintainability : The system is being developed in Python whith an object oriented programming, so it shall be easy to maintain.
• Reliability : Specify the factors required to establish the required reliability of the software system at time of delivery.

4. Product evolution

This product must be thought to evolve in time, in order to become more successful. These evolutions include the implementation of new processings algorithms or algorithms more efficient, but also all the interface evolutions.

Our code must be planned to facilitate these evolutions.