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
| 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 document is to present a detailed description of the astro images processing software. 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. This system 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 objective of the telescope. The objective of DARK pictures is to capture defects (noise and interfact) which degrade the LIGHT image.
- MASTER DARK : It is 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 is 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 is obtained by combination by sigma reject with normaliation. Normally 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 produces by the electronics of the camera.
- RANDOM NOISE : Electronic noise which is totally unpredictable
- SKY GLOW : Noise caused by the light pollution
- READ NOISE : Noise caused by the download of the images
- 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 (post-processing software).
2.2 Product functions
This product must be able to realizing the entire 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.1 External interfaces
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 & 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 function
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
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 White balance (in Structured Natural Language)
Description: White balance (WB) is the process of removing unrealistic color casts, so that objects which appear white in person are rendered white in your photo.
Inputs: pixel array
Source:
Outputs: pixel array
Destination:
Action:
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.7 Adjustment of the contrast (in Structured Natural Language)
Description: Adjust the image contrast
Inputs: pixel array, gain value
Source:
Outputs: pixel array
Destination:
Action: There are various algorithms :
- 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:
Post-condition:
Side-effects:
3.2.8 Noise deletion (in Structured Natural Language)
Description: Removing noise from a picture
Inputs: pixel array
Source:
Outputs: pixel array
Destination:
Action:
- Use a median filter
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.9 Ajustment of the saturation (in Structured Natural Language)
Description: Correct the saturation
Inputs: pixel array, gain :
- 0.0 creates a black-and-white image.
- 0.5 reduces the color saturation by half.
- 1.0 causes no change.
- 2.0 doubles the color saturation.
Source:
Outputs: pixel array
Destination:
Action:
- P = sqrt( RedPixel*Pr + GreenPixel*Pg + BluePixel*Pb )
- NewPixel = P+(pixel-P)*gain
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.10 Ajustment of the luminosity (in Structured Natural Language)
Description: Correct the luminosity
Inputs: pixel array, gain
Source:
Outputs: pixel array
Destination:
Action:
- pixelArray^gain * (vmax-vmin)^(1-gain)
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.11 Deletion of the light pollution (in Structured Natural Language)
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.12 Deletion of the green dominant (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
Non functional requirements:
Pre-condition:
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.