 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 803 |
|
This is a fairly detailed description of the areas of development that are expected for the next year or so in Image Analysis. A subset of these will be targeted for the second release (see above). Some of this will not be of general reader interest. The time estimates are generally bare minimums to get something rudimentary going.
1 week [nebk]
1 week [wnb]
Create a Glish coordinate tool and manager. Currently we have a higher level tool, the coordinate system.
2 weeks for something rudimentary [nebk]
Some more work needs to be done to provide C+ + classes for general manipulation of Gaussian parameters (e.g. converting from pixel coordinates to world coordinates). In particular, the issue of getting position angles correct in a non-linear coordinate system needs to be addressed.
1 week [nebk]
With the above work, we also need to improve the packaging of the coordinate conversion functions available to the user. They are not very satisfactory currently.
1/2 week [nebk]
There is currently no statistical error handling in AIPS++. This area needs substantial thought and effort. E.g. automatic propagation of errors.
Big job.
A lot of things can come under this general heading (including convolution).
Develop a class on top of the Lattice FFT classes to handle FTs of images. Binding to image tool.
1 week [nebk]
Other filtering functions.
weeks
The ImageRegrid C+ + class needs further development to handle unlike coordinate systems.
3/1 weeks [nebk or mh]. mh has developed ImageRegrid beyond its checked in version to make progress towards this.
The image module needs to write history information as appropriate. This needs to be some central facility in AIPS++ which does not yet exist.
?? week [drs or gvd]
Some effort needs to be extended to improve some of the image tool interfaces. Possibly more custom GUIs, or some actual repackaging of functionality.
Some of this is already coded in DOimage.cc and can be moved out. 1 week [gvd]
1/2 week [gvd]
Two items here. The Regionmanager needs to be able to manipulate masks. We must also provide general capability for changing the values of masks (e.g. make the central quarter if this mask True). These two things may well be combined.
2 weeks [nebk]
The current scheme by which regions and coordinate systems are combined needs to be reworked. We need to use the above mentioned new Coordinate tool and use it to define regions of interest.
2-3 weeks [nebk]
There is an (unlikely) ambiguity problem with coordinate systems and regions that must be resolved.
1 week [nebk]
Generate new region types; ellipsoid, zonal, point.
2 weeks [nebk]
Some work to improve Regionmanager interfaces, both CLI and GUI. For the latter, extension and concatenation needs improving.
1/2 week [nebk]
Maybe try and eradicate entirely our pixel-coordinate based regions, or improve flexibility of compound regions in their ability to combine pixel and world regions
2 weeks [gvd]
This code needs to be moved from the image DO into library C+ + classes.
1 week [nebk]
These C+ + classes were written before the Display Library or any of the Glish based pgplot plotting widgets were available. The plotting is done with direction access to the C+ + pgplotter object. Some effort needs to be put in to rework these so that the plotting is controllable from Glish, or that a Glish pgplotter object can be passed through to the C+ +. 2 weeks [nebk]. Something from drs on the pgplotter.
In addition, IS and IH should be restructured into a base class that works on Lattices, with a derived class dealing with coordinates for images.
1 week [nebk]
There is no dedicated polarimetry software in the image analysis suite. Although the image calculator can make up for this deficiency at a basic level, some real development work needs to occur here.
This functionality must move from the image DO into C+ + classes.
Perhaps it should really become part of ComponentList [rm]
1 week
C+ + classes need to be developed to provide the ability to modify an image by a model (e.g. gaussians, disks etc). Binding to images to be developed.
weeks Probably this should be done in the ComponentList tool [rm]
C+ + classes need to be developed to provide general convolution of images by parameterized functions. Probably also high- level Glish tools will also need to be developed matching these classes. Binding to image tool to be developed.
Should share much development with convolution by functions (above)
Some capability should be developed for automatic source finding in images (bottomless pit of activity).
2 weeks minimum for something rudimentary [wnb]
Currently the image DO only works with real images. It should probably be templated to handle complex images too. There is more work in ensuring all of the functions work with complex images than actually templating the DO itself.
1-2 weeks depending on trouble with application code [nebk]
The basic fitter functions well. It needs to be extended as follows, in order of priority.
2 weeks [nebk]
1/2 week with above library class development [nebk]
Develop a tool analogous to Imagefitter (or maybe combined with it) to handle fitting of 1-D spectral components.
1 month [nebk]. Class fitting development should come from Bob Garwood (for dish).