Difference between revisions of "AstroImage/SRS"
| Line 71: | Line 71: | ||
==2.1 Product perspective== |
==2.1 Product perspective== |
||
| − | The goal of this project is |
+ | The goal of this project is to develop a processing chain of image stemming from spotting scope (post-processing software). |
==2.2 Product functions== |
==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. |
||
| − | This product must be able to TODO |
||
| Line 86: | Line 86: | ||
==2.4 General constraints== |
==2.4 General constraints== |
||
| + | * The software must be developed in Python, with Kivy for the UI. |
||
| − | TODO |
||
| + | * Each set of input images are images RAW or FITS |
||
| + | * output images are TIFF or FITS |
||
| + | |||
==2.5 Assumptions and dependencies== |
==2.5 Assumptions and dependencies== |
||
Revision as of 23:14, 5 March 2016
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 Processing of Dark (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.2 Creation of Master Dark (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.3 Processing of Flat (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.4 Creation of Master Flat (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.5 Calibration (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.6 Debayerization (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.7 Registration (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.8 Overlapping of lights (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.9 White balance (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.10 Adjustment of the contrast (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.11 Noise deletion (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.12 Deletion of the light pollution (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
3.2.13 Deletion of the green dominant (in Structured Natural Language)
Function:
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
- Natural language sentences (with MUST, MAY, SHALL)
- Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
- Mathematical Notations
- Tabular notations for several (condition --> action) tuples
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.