Photon Calibration Release

The direction of developing of Munipack during last half-year has been strongly influenced by application of Munipack on data archive in Ondřejov Observatory. I had developing a set of scripts which are suitable for processing of large archives of frames: Astromill. Currently, Astromill is prepared for the particular case, but I plan more general utility, at least for peoples having good grasp in computer programming.

Developing of Astromill contributes tree new important features into Munipack:

Photometry Calibration

The very precise calibration of the Ondřejov archive leaded to deep improvements in the calibration. The maximum precision can be only reached when colour calibration is carefully prepared, which me forced, to construct own catalogue for observed fields because there is no a photometry catalogue which covers all the sky with required precision.

An impact of (un)precise of various calibration methods may be illustrated on light curves, all night observation, which I prepared for new version of light curves tutorial. The best results are achieved by the way:

• (approximate) calibration of a carefully selected reference frame against to a catalogue (standard field stars) in absolute fluxes.
• And follow up calibration of all other frames against to the reference.

Much better results can be reached with construction of own catalogue from all frames. It is challenge for me. Preliminary version is implemented in AstroMill. It averages frames and corrects colour extinction. Unfortunately, Munipack is not offer such tool for the task now.

Flat-fields

I've very sad news. All flat-fields which has been generated by flat utility were wrong. At least, they was been imprecise.

All the previous implementations used only robust averaging of the frames with scaling. Both the average mean and the dispersion were scaled independently. It's important for series of twilight shots.

I developed a new algorithm which scales only levels because dispersion is scaled together (thanks to property of photon noise) for known gain. Flat-fields are constructed in two steps:

• averaged flat,
• new scaling against to the flat and new averaging.

The precision is order of 1/1000 and as the side effect, gain can be estimated during the process.

Packages Repository

Thanks to official availability of wxWidgets in version 3.0 since June 2014 (link), and including of the wxWidgets libraries in ordinary releases of Ubuntu and Fedora, I updated build scripts for preparation of DEB and RPM packages. So the bundle installation way is not more required (and is obsolete now) and the standard way for installation of packages is supported and recommended. There is nothing to block including of Munipack into main GNU/Linux distributions, I hope.

Also I prepared own repositories for Ubuntu and Debian enabling easy installation and automatics system updates.

Nights Without Convergence

I spend many sleepless nights during preparation of last release of Munipack when no convergence occurred up to morning blue hours. The new feature, which I developed, was improvement of the robust algorithms which implements join estimation of location and scale parameters of statistical distributions.

With a presumption of Normal (Gaussian) distribution of data, the location parameter (centre of distribution) is independent on its scale and moreover, the estimate of the scale by conventional methods (standard deviation, mean of absolute deviations) is optional and naturally guaranties minimal noise and maximal information. Processing of data with other distributions, which we are supposing when robust algorithms are applied, also requires estimate of its scale (standard deviation) of the distribution together with the location.

From numerical mathematics point of view, this is a standard task. One can use the method of maximum likelihood, the likelihood function will be constructed and its minimum is determined to get parameters. Another standard way is to derive a gradient of the function and use an appropriate numerical library to locate minimum from an initial estimate.

Unfortunately, I revealed during the sleepless nights, that the gradient way can fail when the original function is not quadratic (opposite to the least square method). In this case, the false (artificial) features are appearing and I spend nights by looking for its convergence criterion.

Square of gradient of the function

The final result, on figures, is self-describing. When initial estimate of the gradient method falls inside of pit, on the left from the artificial throat, a method converges. When we are starting on the right, the algorithm is non-convergent or with minimum in infinity.

Negative logarithm of maximum likelihood function

A non-gradient method without derivatives locates the minimum easy and unique (and unfortunately slowly).

As the result of all the sleepless nights, users of Munipack benefits in less scattered estimates of averaged biases, darks, flats, sky backgrounds, photometry calibrations,…

Closing doors

I'm closing Munipack's site on Google Code because separation on development and stable sites was source of confusing for many users. The content of wiki has been merged to main site and Mercurial repositories will be sometimes updated.

Together with the change, I thinking also about closing of mailing lists and Google plus page which are practically abandoned.

Photon Rain

I am pleased to announce the availability of next release of Munipack. This release is 0.5.4 and named Photon Rain because I developed the implementation of the photometric calibration which satisfy my wet dreams for the first time.

The developed implementation along with the new matching algorithm are superseding importantly of Classical release.

The implemented features are two extremely difficult tasks:

• transformation between photometric systems
• full photometric calibration

Even more, the fundamental quantity used for calibration are photons (magnitudes has been omitted). The photon approach enable us use of amazing properties of both Poisson's and robust statistics.

The calibration implements all single-filter calibration against to a catalogue and the multi-filter simultaneous calibration with the photometric system transformation matrix. Also the photometric system transformation can be easy determined from observations. Magnitudes are implemented just for compatibility.

Photometry enhancements

Developed a new approach to photometry reductions on base of observed counts and expected photons. Using of basic of Poisson's statistics and added statistical robustness.

Implemented calibrations of single-filter observations along with multi-filter case. The photometry system transformation is developed.

For Details, see Photometry Overview.

Astrometry enhancements

Astrometry is also important part of enhancements.

• Removed superfluous loops (speed-up about 100x), matching has additional criterion for similarity of observed counts and expected photons (improve robustness in crowded fields where stars can be easy interchanged, also reduces back-tracking tree and therefore importantly improve the algorithm speed).   The computing of   angle between stars in normal space is included as an independent quality test. The star sequences are closed paths now to reduce length of sequences and improve robustness.
• UCAC4 is now default astrometry catalogue.
• Proper motion is introduced.
• Just stars with valid aperture photometry are used for matching (all detected sources had been used and the approach may produce a lot of garbage for improperly corrected images).

Other enhancements

The release includes also these enhancements:

• Developed a new approach for frame photometry pre-corrections (bias, dark, flat). Renamed (and redesigned) modules for the corrections. A single command  for the corrections (replacing darkbat and flatbat) has been introduced.  It is implemented possibility of masking of a part of image.
• Basic FITS header modifications are implemented including to update of header's  keywords. A FITS file can be dumped to a text file and restored again (useful to create of tables).
• Internal FITS tables has different column naming schema to be more compatible with Virtual Observatory conventions. Also some command-line options has been modified for that reasons.
• For known data sources, the long options (--col-ra, --col-mag ..) has default values and ones can be provided optionally.
• Structure of both FITS tables and extensions has been changed drastically  and any older preprocessed data are no more compatible (!) with files produced by this version.
• Building system - Building scripts (in dist/) has been improved to separate the installation to independent bundles (packages) and as the system-wide   one. There is also possibility to install Munipack without wxWidgets.
• Developed light-curve (or any quantity) time series FITS-flavor format as a simpler version of SimpleTimeseries.
• GUI updated to match modern desktop conventions (for GNOME 3/ Gtk 3+).
• Huge expansion of documentation.

Corrected problems:

• using of shell-environment variable containing substring DATE-OBS
• A negative declination is recognised as a number (not as a command-line   confusing switch).

Known Issues:

• GUI has only minor improvements (=practically none).
• None from New features has no support in GUI (except new photometric quantities box in side panel of View).
• There are problems with non-English locales. Numbers with commas (replacing dots) are still recognised unsatisfactory (the behaviour is perhaps random and very difficult for testing by myself).

Warning (!)

Many, really many, changes has been prepared against to previous releases. Please, check carefully every self-evident presumption about usage, command-line parameters or data formats.

New Photo Preprocessing

This year St. Václav's day and long weekend I dedicated to develop a new approach to a photometric preprocessing in Munipack. My body had treated from flu and cold so I spend a long time at terminal.

As the photometric preprocessing I means photometric corrections:

• correction for dark current (dark frame),
• removing of preamplifier offset (bias),
• correct a variable light response of (CCD) detector together with whole optical system (flat-field).

Munipack's older approach on the corrections has roots in '90, when we acquired dark frames for every exposure time. The bias is included in both scientific and dark exposure and the bias correction is naturally included in boths. The same approach is valid for both scientific and flat frames.

New approach is modeled as following the widely reccomended method in today. A photometrically corrected image I^c_ij is computed for every input image I_ij as
  I^c_ij = (I_ij - t D_ij - B_ij) / f_ij,
where i,j is an index of a pixel, D_ij is a dark frame t is ratio of exposure times  of I and  D. B_ij is the bias and f_ij is normalized flat-field frame (to save absolute photometric fluxes):
  f_ij = F_ij / 〈F_ij〉.
〈F_ij〉 means averaged level determined by robust mean.

I think the change does not cause any controversy. More over:

• The older approach is still available when bias is treated as zero.
• From previous point of view, the approach is just primary a new façade for users. More easy user's usage.
• User is not confused. The method is exactly the same as textbooks describes.
• Important parts of algorithms are the same, changes in functional parts are minor.
• Observation time save. A long-exposure dark would be prepared and applied to all shortest exposures (also on longer ones, but the noise can devalue frames).
• Bias exposures are very short, so acquisition of a lot of biases it is not too time consuming.
• Processing tools has improvements in use of previous data products and no temporary reduction of frames are created.

This is practically a complete new implementation of preprocessing routines. Of course, all my previous experiences are also included. The work is currently uploaded to Mercurial repository and will be available in a first issued public release.

New Generation Release

I finished modernization of Munipack the engine during this spring. By the way, the incoming release fully replaces of the classic edition 2009. All the functionality is recovered again (and many many other is added).

All the current functionality has origin in all-inclusive representation of FITS (images has added all processed data as the additional HDU). On the base I prepared new versions of:

• astrometry,
• photometry,
• listing of data (star catalogues, light curves),
• composition of images.

The classic edition tagged as 0.4.2 is to be supposed obsolete now and its functionality is fully superseded.

Now, Munipack is prepared as to be suitable for regular data processing since this release. Please be careful, really extensive testing is still necessary!

Many of the implemented features has GUI unfinished (unprepared).

Astrometry

Astrometry part has been improved in many points:

• advanced GUI dialog,
• batch GUI dialog,
• the matching has been theoretically studied and the algorithm is practically developed from scratch,
• the robust fitting part has been improved by more simplifying and fine tuning of the algorithm,
• GUI contains visualization of matching:

Robust Algorithm

Very important improvement is included in the robust algorithm, the core of all robust estimation. Since this release, I used estimate of median by a fast algorithm by Dijskra (see Wirth (1976)) which can get n/2-th element of n sequence. One is excellent for many data (over twenty) but the ignorance of the correct definition of median (which is mean for even) has poor impact on estimate in case of a few points.

The algorithm of median (scatter) estimation is newly modified. For a few points, the median is estimated using of a sorted sequence (with sorting ~n*log(n) complexity) and the definition. For many points, the algorithm is unchanged and by using of the fast algorithm (with ~n complexity).

Results seems more precise and stable.

Localization

There is an unsolved problem with localization. Many my colleagues has installed localized version of a GNU/Linux distribution which is confused by a decimal dash (no decimal point) in real numbers so the underlying software (wxWidgets) must use locale rules to convert numbers to the right format. So I prepared a (untested) code to be locale-friendly.

Unfortunately, there is no complete solution of the problem. There are many examples where the points must be left: VO related and FITS header must contains only ASCII characters.

Other changes:

• HTML documentation updated to HTML5,
• Docs has been restructured and extended for description of completed features and tutorials,
• Helping utilities konve and picko has been removed from main tree and are available as independent applications (but included to binary version),
• backup strategy replaces FITS conventions and implements the standard GNU backup behavior,
• better processing of output filenames in batch,
• improvement and bugfix in displaying of images,
• created a photometry GUI dialog,
• rewrite of munilist (added listing of all objects,..) and kombine (works with spherical coordinates which enable geometrical transformations and mosaicking),
• updated for a new versions of g++/gfortran and wxWidgets,
• patchelf utility needed for binary distribution has been fully replaced by -rpath option,
• clarified verbose/pipelog prints.

Summer Plans:

• update GUI + add GUI for remaining features,
• a library for image/color processing (common to fitspng) (?),
• use slalib.

Acknowledgment

Many thanks for my students which has been first testing persons of new versions. Many errors has been identified and corrected during the testing period.

Konve and picko

I separated utilities konve and picko from main Munipack's source tree. Sources of both converters are unmaintained and I'm expecting just only small interest about its. On the other side, there are probably huge archives of frames in these formats and the existence of the utility may be important.


Both utilities can be easy used by hand (from command line). An integration to munipack/xmunipack is not planed (although one is easy).

Moreover, I prepared also:

• GNU autoconf/automake machinery (but simple compilation by gcc will does the same job).
• creating of DEB based packages (is there somebody who will do it for RPM based?)
• Homepages: konve and picko
• source is maintained under Mercurial vs.

Renoir's: A Girl with Watering Can.

Astrometry Release

It's right time for an another development snapshot of Munipack. I have no time and no strength to stay in intense developing during our semester period. Before two months of stagnation, I issuing a rolling progress of Munipack.



General notes

The issue is still experimental. The debugging is switched on by default. Don't be confused from a lot of mash prints.

Many improvements in image loading, image manipulation or safe thread handling leads to more usable and stable application.

Also many improvements in GUI has been done. The most important is remove of left panel (selector of HDU) in Viewer and adding of zoom and coordinates panel. The image zoom is probably more important than the selector. The toolbar buttons must be relative small because users can prefers no labels to ones.

Practically all main features are (at least partially) currently developed, I plan to publish new issues more frequently.

Astrometry

The current issue is focused on astrometry. I developed a GUI and improved importantly astrometry methods. Also support for Virtual Observatory has been included:

• New matching algorithm on base of back-tracking has been developed.
• Dialog GUI for astrometry. Users can directly change parameters and see results of the modifications.
• Added (unfinished) GUI dialog for aperture photometry and object detection.
• First steps toward to direct editing of FITS files has been implemented as a support of saving WCS to HDU.

There are three modes of operation:

• Manual specification of set of full parameters.
• Fitting of predefined of set of parameters.
• Matching against to a known catalogue.

Planed features:

• astrometry directly derived from an image (transfer from image) by fitting of two images by hand (?)
• add object name resolver (coordinates position by name)
• using of WCS-library for support of more projections and more precise algorithms
• solve relative coordinates calibration for wide-field images by digital camera, or precise relative (mutual) positioning of images

Virtual observatory support

This issue is a first which supports VO. Just only cone search and simple analysis of VOtable is implemented. Because there is a poor support of VO in C/C++, I created a parser of VOtable on the top of the wxWidgets interface to Expat library.

Plans:

• object name resolving
• image, spectra and time series (?) search implementation

Munipack's FITS files

There are two important changes in FITS files representations. The color format of FITS has been changed during this developing period. The format is more clearer now (see colorfits specification).

Additionally, I rewrote all older subroutines to store all output information as photometry and object position as FITS tables. The tables are added as a additional HDU of processed images. The advantages are:

• less chaos, additional information are partially hidden for user
• the information are directly accessible for processing
• due to binary representation, there are no formatting complications for very small or huge numbers

Generally speaking, the FITS files are more suitable for code to code data transfer than complicated set of text files.

Binary packages

Binary packages are created for deb and rpm based distributions now. Older binary packages has been abandoned due (mainly) to dependency hell and on base of an user feedback.

The packages are created for main current distributions. A deb is designed for latest Ubuntu and Mint and rpm for Fedora and openSUSE. The packages are relative universal (just only widely used libraries (libc, libgtk) in latest versions are required. The choice satisfy over 70% users. Any latest widely-spread distribution does not contain wxWidgets in unstable branch flavor needed by Munipack.

Configuration files

All configuration files has been moved to ~/.xmunipack/. Additional changes are planed.

The place is not in conformance with Free desktop recommendations, but there is no support for the rules in wxWidgets.

wxWidgets update

Munipack is using the unstable branch of wxWidgets now. It is absolutely necessary because stable branch does not supports event handling for console applications. That means that CLI cannot correctly run and work with external processes.

Minor advantages of use of unstable branch are: spins supporting of double values, more flexible event handling (using of Bind), thread safe (really working!) logging functions.

Also the external process handling and pipe-lining has been rewrote (practically from scratch). The real pipe-lining like a shell is supported via chain of external processes which interacts with next and previous ones via captured standard input and output processed by its overwritten class methods. Noteworthy, the running of external process (or pipe-lining and so on) is implemented extremely poorly probably by all toolkits or under other platforms.

*

Munipack has been tagged on version 0.5.2 during Oct 19, 2011.

New Format of Color FITS for RAWTRAN, FITSPNG and Munipack

Long-term experiences with processing of color FITSes has leaded me to drastic change of color-storing format. The separation of single-color bands to FITS image extension is really wrong way. It is less natural than storing in multi-dimensional single array. The data are logically grouped together with meta (header) information.

However, main reason for the change has been simplifying of manipulations with color images. The simplifying is really drastic. I removed hundredth of code lines and a lot of (potentially) buggy code.

Another important change is replacement of COLORTYP to CSPACE describing of colorspace of stored color image. I suppose, the new keyword is more mnemonics. See also description of the exact structure Color FITS format.

The changes are included since versions 0.3.0 of rawtran and fitsng and 0.5.2 of Munipack.

Coloring release

Munipack development notes

Version naming

I had introduced new naming schema for releases. The naming will be inspired by the crucial development feature.

Naming of the current release is emphasizing development of color handling utilities (coloring, color tuning, color space conversions, etc.).

Release period

Last stable release has been issued on 2010, February.

I think the period is really very long.

The current release does not includes color related features,

but many other important improvements. Namely,

one offers a new command-line interface. So the issue naming would be also

like "commander release", "general failure".;)

In addition, I forget many details developed half year ago, of course.

Also many crash reports (via build-in dialog) are due to errors in binary release which I fixed months ago. So it would be more useful to issue binary releases more frequently. In ideal case, one will immediately follow implementation of an important feature development.

Homepage design

I had modernized a schematic design of the homepage. CSS has been extensively used. The design is probably inspired by the design of guide for MS Fortran Powerstation 1994 edition. By my memories.

Also I tried to apply the rules used in classical typography to Web. The detailed application is not possible, but many rules can be simple used. The most visible is limiting number of characters in a single line on 80 characters. It may look little bit uncommonly, but I think the reading is more comfortable.

I've worry about use of float elements (tables and images) in a Web page, which ugly breaks text flow. On the other side, the placement of all the elements on bottom or on separate pages is more disturbing. I'm expecting some progress in future.

The interesting navigation's post about typography (but no idea but from the examples has been used).

I had try to use rules:

• book-like design
• column width of 80 characters
• column width of 80 characters
• minimized number of used fonts

XML serialization

When I implemented the archive and DND functions, I developed a XML serialization of FITS header, structure and thumbnail data (contents of ~/Munipack). The concept is partially similar to VO table format. The XML files (including thumbnails in png) can be easy pushed over tcp sockets, streams etc.

Sub-processes

This release is also proof of concept for invocation of external binaries within GUI session. The GUI is a controller (GUI wrapper) for the binaries. All working utilities (conversion of raw pictures, coloring, dark, flat averages and corrections) are implemented as sub-processes of GUI (via wxExec function, which is probably just only wrapper of exec(3) family functions under unix).

This concept separates GUI and working parts. Also importantly reduces complexity of full package. The utilities communicates via standard input/output. Therefore, there is a wide flexibility in replacing of required subroutines. Also it would be easy to use of the utilities under another environment (Web, etc).

The successful prove of the concept is probably the most important experience of this release.

Plplot

All plotting has been rewrote to use plplot library. This is just preparation for a more power-full plotting tools.

Displaying improvements

In previous release, images has been rendered by passing of every pixel to routines as single argument. The way looks slow. The rendering needs call of two or more functions (tone + color) which may be slow (in order of percent). More important aspect is display in progress. The extensive calling of events for every pixel to indicate progress is very bad idea. Therefore images was displayed when full frame rendering was completed. That may be stressed for user, which expect results immediately.

Therefore, I rewrote displaying in progress to tiling. The image is split-ted on tiles with suitable 137x137 (fine structure constant) pixels. Hence, rendering function works on whole array (not on single pixels). The rendering results can be displayed continuously (only a few events will usually needs) which is more comfortable for user. The rendering naively simulates a progress bar.

Another improvements is pre-scaling of images. One leads to rendering already scaled image. It importantly speed-up tuning of large pictures.

The speed for normal size gray images is satisfactory. Commonly, eye does not recognize any blinking (flickering). The rendering times are usually under 0.2 sec. Unfortunately, the tiling is clearly visible on color images because transformations are more expensive. Rendering may take seconds.

New installer

The most visible change is use of ESP package manager which provides graphical installer similar to widely known installers of Windows or Mac OS worlds. The installation is pretty straightforward. All files are installed to /opt. There is no possibility to change the place.

By the way, the google-chrome deb package installer does the same job. It is designed to unpack a set of binaries to /opt. The installer also create appropriate links to binaries and run xdg tools to add google-chrome to the global menu and desktop.

The graphical installer does not offers ideal way to install when package system is available. In future, it would be better distribute binary packages (deb,rpm?) as well as.

EPM installer (setup) has included fltk library. Also needs some binary libraries (in proper version number!) included in system (png, jpg and X-libs). Is there a way how to link its statically?

Binary bundle

I spend very long time with developing of a new build script.

The script is relative solid and easy to use. So the generation

of a new binary release binaries will not too bother to me.

See dist/builder.sh.

The linux packaging systems (deb, rpm,... packages)

are really great ones. Unfortunately, there is really many

linux distribution and combination of various libraries

and tools. Distribution of third-party tools is really big

strange not satisfactory solved yet.

The crucial point is library dependency. Theirs placing and presence

is important for run. The library mutual cyclic dependencies can

cause big problems for binary distribution.

So, I has choose the way for the distribution:

• All files are placed to /opt/munipack. The hard-coded installation directory is required by EPM.
• The distribution includes libraries out of typical distribution set (wxWidgets and plplot). The libraries also would correctly set compilation options and versions.
• Some binaries (and .so libraries) sets rpath. Usually the rpath is hard-coded during compilation. The path is different from installation path. Therefore, I replace the rpath by patchelf utility (see http://www.eyrie.org/~eagle/notes/rpath.html).
• The distribution script is dist/builder.sh

A Graphical User Interface for Munipack

I had started work on the graphical user interface (GUI) for Munipack year ago. The issue of a first public experimental version including the GUI is ready for downloading. Thus, I think the time to resume of my selected skills with the GUI development is coming now.

Why GUI?

Steps towards development of GUI ripened inside me for a long time. The last story which rouse me was processing of large data sets of images from our digital camera. I scaled by manual way its intensities which was produced a very long sequence of commands with fine-tuning options.

Screenshot of my older terminal

Other reasons:

• simple complex visual manipulation with FITSes
• processing of astronomical data by my students during migrating from another platforms
• it is really shame that we have not a simple astronomical data manipulation tool in 21. century
• command line utilities needs a lot of experiences to work with
• I want save my skills with data processing (any kind of description is not satisfactory with respect to a dynamic actions, a white paper is not a way).
• More simple and interactive way of operations on images.

Not all the aims are included in current versions, but they are planned.

Inspirations

I started work with long time experiences of using ds9 and Gaia. Both are my personal favorites. Unfortunately, both does not fully supports my needs and also the reasons above. Initially, I started work on GUI as a modernized copy of ds9. Lately, I abandoned the way but many of features introduced by the tools are presented.

As a first step, I coded Help window as a simple copy of Gnome's Epiphany browser which can be used to display on-line help. Epiphany was one from first clear designed web browsers.

A help (large)

The Browser window with thumbnails is similar to another Gnome's utility - Nautilus, the file browser.

A browser (large)

The dynamical behavior during image rendering/loading is similar to iPhoto. The load of large images can take many seconds and user is confused when see only a blinded menus or controls. So I used the hook: Firstly display appropriately scaled icon and display a rendered image later. This gives effect of "working application" without confusing of its user.

A view during loading (large)

The design

I designed GUI practically randomly in early phases. A lot of features I'd take from ds9 or Gaia. After some period of frequent redesigning, I found the document Apple Human Interface Guidelines and afterward I cleared concept. By my opinion, the chapter Characteristics of Great Software is on base of work and ideas of Jef Raskin.

The key principles:

• Keep everything simple as possible.
• Don't distract the user from his/her ideas which working on.
• The user is not a programmer. It is expert in astronomy and I is not (not want to be) an expert in programming.

See J.Raskin's rules.

In astronomical processing, the user thinking in absolutely different working framework or technical terms (for example: spectral distribution, black holes, fluxes) than a programmer. So I tried design the GUI in that way. For example, a FITS file is displayed as a tree structure similar with single parts representing every HDUs. User can easy show info about image as well as image itself.

Don't expect that the GUI will cover all functionality of command line utilities.

The programming language selection

The code of Munipack has been developed in Fortran up today. I used Fortran 77 in early days, but now is everything except munimatch coded in Fortran 90. Unfortunately, there is no graphical toolkit for Fortran.

I selected C++ after forethought. The C only is too primitive and too difficult for GUI programming. The Pascal or Ada has poor support of libraries. Go looks attractively (is like C++ with garbage collector) but is not matured yet and also has no support for graphical toolkit.

I abandoned Java, Python, Ruby, etc. for theirs very slow run and needs of a virtual machine. Also, I can not hustle users for installing some additional exotic virtual machines when they have running CPUs. By my opinion, it is very bad idea to write a image processing utility in interpreted language. The counterargument that the development is more fast is fake. I spend approximate same time while developing in Python and C++ under wxWidgets.

Also, theirs run-time speed is important. All interpreters are slow, really slow. The pull of menu is a great action spending many seconds.:) The replace of sub-elements in a window induces a pause for cup of coffee.:) But users have no time. User wants to see their results immediately. The one is less important in GUI elements but it is really important while displaying of large images. The image must be recomputed (rendered) before every displaying.

The operation must be done on CPU because I have not found a way how to done it onto a graphical card (if there is the way, I think OpenGL specification doesn't supports my needs). To illustrate the computations , please try code with loop over 1000x1000 pixels with a simple operation like sum of two real numbers in various languages. I got: C++ under 0.1 sec, Java, Python a few seconds. Because the operations are done very frequently the interpreted languages are unusable for me.

The toolkit

Alternatives for graphical toolkit:

• Gtk+ - With Gtkmm+ may be useful. But relative rapid development and non-platform looks doesn't fit my needs.
• Qt - controversial license. Development depends on one company. Unaesthetic look.
• GnuStep - Very attractive alternative witch offers look, control and behavior like Mac OS X. Moreover it is programmed in Objective-C. Unfortunately, graphical look under Linux is like one from the past.

All others are unmatured and too simple (Fltk, fox, ..) or they are in too many retro-style (Motif, Athena ..).

Finally, I selected wxWidgets. The toolkit offers many amazing features.

Two crucial features for me:

• Portable (multiplatform). It can be run under many possible environments including Unix, Mac OS X, Windows, smart phones.. The library is as the unified layer between portable code (developed by my) and a native toolkit. Impressive! So it looks as a native application. Many additional features like portable configuration support, filesystem managements and many more helpers are implemented.
• Memory management. wxWidgets has two approaches to memory management. Graphical widgets (like windows, controls, dialog.. elements..) are created as pointers and destroyed by the library itself so memory management is done by library itself. Second way is implementation of reference-counting into library core. Therefore all my data I'm using as reference (not pointers) without risk of memory leaks. Both techniques practically does a kind of automatic garbage collector. The memory is checked via valgrind.

The GUI core

I spend a large working time with:

• design and implementation of FITS representation on the top of cFITSIO. I developed a set of C++ classes as representation of a general FITS file. The implementation can be used as a simple library for cFITSIO. CCFits library does not fit my needs.
• I'm using two sets of classes. First represents a original FITS file and the structure is fully used in View window. Second represents a FITS meta object containing only headers and icons without memory consuming bitmaps or tables. The structure is used in Browser window.
• GUI design (see rest of the post).
• Any interaction between different windows controls is implemented by all modern window systems via events. Unfortunately, the implementation is very primitive. Single object sends events to another specified object but it is very difficult to sent the signal to various objects, gets a response and vice versa. The basic idiom used in this context is model view-control. I'm using some ideas of its for displaying of images. But I developed it by little another way and independently.
• Using of threads. One from big problems when I solved. The windowing system runs handlers for prepared actions without interruption. If any action takes longer periods (over 0.7 sec) user can see that the application hangups. This is very confusing behavior. The right way, how to solve, is via independent threads. The application responses very quickly and it pleasure for use when threads are used. It is very nice when more than one CPU (or core) is installed. Than both threads can run on different CPUs to importantly speed up the application.

During hungup (large)

The GUI design

I choose untypical (with respect to ds9 or Gaia) layout as result on many experiments. The View window is divided onto two pars. The left is a control panel where a structure and additional info (histogram, size) of FITS is displayed and the right is for displaying of a contents. The window can show all images, tables and header.

The geometry is ideal for modern monitors (commonly in 16:9 format, Xerox Alto computers are very rare to meet today) when a maximal area of image can be displayed without compromises. The left part is near of other controls (menu or toolbar) to meet a right ergonomy (my personal preference is the close button on the left).

Two important improvements over the ds9 and Gaia are included:

• The image is fitted on the size during load (like iPhoto's). This speed up loading of large images and also the image is completely and perfectly prepared for a quick inspection.
• The image is automatically scaled in intensity. The user probably will see mostly details on the image.

Some controversy can be creating of separated windows for tuning and detail view. Many peoples don't like the behavior. I checked both alternatives, the dialogs included in tabs in control area and the separated windows. Perhaps, the including is too restricting. The windows has limited space so you can't freely move or size windows. The layout and labels must fit the space. You can't have opened both windows together etc. A useful discussion can clarify the layout.

A detail (large)

Bugs

The current version is relative stable but it was not tested on wide range of software configurations or operating systems. Therefore I expecting a lot of bugs to fix.

The are two channels to report any bugs:

• The issue tracker under Google code. You must have OpenID account to use it. You can also use the tracker to request of new features.
• When application crashes, the application shows an dialog with a log which can be used to directly report to my ftp server. The log can contain some private information. Please check directly that the info can be read be me and when you will accept to pass a (really) small info about your configuration, please send the report.

A crash report

You are also welcomed to Munipack's Google groups where you can report bugs or discuss more detaily other aspect of Munipack and the astronomical processing.

Discover of a New World

The detailed structure of FITS files reveals a new world for me. With help of the one, many FITSes shows unexpected additional features. Do you know that DSS images has two parts? The use of the parts is trivial not a complicated. The structure of FITS is displayed as an integral part of FITS world so users are not surprised by the complicated structure. Especially, it is important during inspection of any unknown file.

Horse nebula (large)

Unimplemented features

• List mode (don't show icons, show table with files) in Browser. It is probably useless, because thumbnails are not visible. I'm hesitating with its support.
• Orthogonal intensity scaling. The well behaving applications has orthogonal controls. That means, that when one tune a quantity, other quantities are not affected. Unfortunately, the intensity scaling in not implemented orthogonally. The image is brighter of darker by using of both sliders. I have no idea how orthogonalise it.

Please, keep in mind that everything can be changed.

Astrometry Calibration

I added experimental support for astrometry to Munipack. It is primary designed for astrometry on CCD. So only gnomonical projection and affine transformation (shift and rotation) are supported yet. Both limitation can be freed in future releases.

The astrometry code is available in GoogleCode now.

The algorithm

I coded my own implementation of the widely-known "Astrography plate

measurement" (Smart & Green, Tagg).

On input:

The table with Right Ascension,Declination (from any catalogue) and corresponding measured rectangular x and y coordinates for every object.

The algorithm:

1. Get center of a picture in pixels as half of both sizes.
2. Estimate a center of projection in spherical coordinates by mean.
3. Project spherical coordinates to rectangular ones.
4. Estimate scale as mean ratio between distances of projected and measured distances of objects.
5. Estimate angle of rotation between projected and measured coordinates by using of property of scalar product of vectors.
6. Compute the transformation by some minimization method with starting values given by items 3,4 and 5.
7. Check offsets between center of projected and measured coordinates. If one is too great, does better estimate of the center of projection and repeat from item 2, else finish.

On output:

Precise coordinates of center of projection, scale and position angle of image. Optionally, statistical parameters.

The described algorithm is relative general, so it can be easy modifies for another projections or more complex transformations of rectangular coordinates like distortions, pincushion, etc.

The algorithm is iterative due to fact that we need known the center of projection before we have calibrated image. Usually, only tree iterations are required.

The Robust Algorithm

The real-world usable algorithm needs to be robust. Small deviations can cause only small variances in output parameters. Outliners has only small fluency on the solution. The simple example of the use of robust method can be found in Launer & Wilkinson: Robustness in statistics: proceedings of a workshop (1979) or in Numerical Recipes. Munipack implements robust mean estimator in lib/statistics.f90 as rmean. Another use of the robust algorithm is on straight light fitting.

I applied the basic schema of robust algorithms to the above algorithm:

1. Estimate median of absolute deviations (MAD) using of minimization of absolute deviation (Nelder-Mead).
2. Use method of maximal likelihood to estimate the proper transformation.

Astrometry implements module in astrometry/astrometry.f90. The estimation of MAD is loop around nelmin. The maximum likelihood is loop around Minpack's hybrd.

The fitting is decomposed on tree single steps (estimate of center of projection, scale and affine transformation) so we works in parameter sub-spaces (we are not fitting all the parameters together). Numerical experiments gives me more robust behavior and more precise solutions than simultaneous fitting of all parameters. By my opinion, it is results of (non-)ignoring of their cross-correlations. It is interesting that QR decomposition does not solve the problem.

The algorithm is optimized on precision not on speed. So for a lot of objects may be slow.

The Low Precision Algorithm

The robust algorithm can be used only for many object (ideally for tens of stars and more). The absolute minimum is five stars. I'm supposing that sometimes will be required astrometry for less stars. In this case, I'm switching to a simple algorithm which uses median only to estimate of required parameters.

For two stars, the transformation can be determined, but is is not possible to estimate uncertainties of parameters. It is not possible to estimate scale or rotation for only single star.

Input/Output "protocols"

I choose an unusual way to set an input and get an output data. The stream input is a text file consists a set of lines (records) with the same structure as FITS headers. By the user point of view, the routine performs as a transformation filter. The text file on input is modified by replacing and adding new lines to the output text file.

The output structure is perfectly suitable to be directly writable to a FITS header in standard WCS format. We need an external utility to merge of the output lines to an existing FITS file. Munipack provides munifits tool for the task.

It is possible to add another type of output, but I think, there is no other widely used standard astrometric format. If the way will successful, I'll reimplement it for remaining utilities of Munipack.

The style can be little bit strange but absolutely the same as standard e-mail handling. An user interface (Thunderbird, elm, ..) creates well formatted input file and pass it to a SMTP daemon. The daemon (or its successors) delivers its (as copying filter) to a recipient and some client decode its. Note that many Unix utilities uses the same idioms (sed, awk,...). The main advantage of the style is a simple modification of format, also back and forward compatibility. [http://catb.org/~esr/writings/taoup/].

The protocol is in detail described in included manual page and test example.

An example of calibrated image with UCAC2 displayed stars. Thx. Mr. Pavel. Large size.

Munipack vs. Mercurial

I uploaded Munipack's source version tree to Google's Mercurial repository a few minutes ago. The step has been invoked by idea to provide of a public access of current code changes via Google's version repository. Munipack's archive is accessible on Google's code:

http://code.google.com/p/munipack/source/checkout

I'd used classic CVS before two weeks ago. Unfortunately, Google doesn't offers CVS, so I explored SVN, Mercurial and Git. Therefore I explored these version systems. By my opinion, SVN isn't step forward. Features of both (CVS vs. SVN) overlaps and the turnover practically offers only different codes (aliases) for operations.

Both Mercurial and Git are acceptable and with an excellent design. The selection Mercurial vs. Git is really difficult. Finally, I selected the Mercurial only for its wider portability, which is really important for me (and also for Mercurial's simple usage and nice guide).

Beginning experiences are really amazing. The most important for me is absolute free modification of the code. It's possible to work on two or more parts of code together, so I can simply focus on an problem (feature) which I'm thinking about. The development is more free from causality now and I can do more risky actions without any fear.

The publishing of source code make a possibility to simply provide of two branches of Munipack. A stable branch created from a taged running version tree and a development branch with an experimental code.

Also, it opens door for an independent developing...

Homepage, community and distribution update

Since February, I'm working hard on new properties of Munipack. A long-time fine tuning of parameters of fitspng was the initial impulse for me. I spend a lot of time (hours) with selection of appropriate values to get a naturally looking picture.

Of course, this is fault of any command line interface. So I've started working on a GUI to Munipack. It inspired me to did some additional changes.

I think, that is one of ways to pass my photometric experiences to next generations. A software in action, together with a source code, may help me describe all details of methods. They will illustrate more preciselly than a natural language. Any white-paper or a web article can't fully describe implementation details. From this point of view, Munipack is a part of my mind and experiences.

Homepage

The past-looking homepage of Munipack has been replaced to a new one. Its style is improved version of Nightview's homepage. All pages are static and they are generated directly from my version system one per day.

I also moved main Munipack site to this new address:

http://integral.physics.muni.cz/munipack/

to highlight connection between Munipack and Masaryk university using of .muni.cz domain. The original name is inspired by DAOPHOT originated at Dominion Astronomical Observatory. The -pack suffix means that a set routines isn't focused only to a specific photometry task.


Community site

I founded Munipack's side on Google code:

http://code.google.com/p/munipack/

The site provides two important tools. Wiki which can be used by anybody to write some descriptions, experiences or to summarize some procedure of data processing useful for others. I'm expecting that the wiki will used generally for astronomical image processing. I'm will very gladly when Munipack will used for the processing.

Google code also offers a bug-tracking system. It is an ideal place for reporting bugs and feature requests. I think that will provide for me some better arrangement of development needs.

I think that a mailing list may be very useful to Munipack. So I also founded the Google group for Munipack:

http://groups.google.com/group/munipack-users/

Again, It is intended for a general discuss about the astronomical photometry and I will greet with using of Munipack for this work.


Binary distribution

While average Munipack user is not familiar with a code compilation process, I'm providing binary distribution packages. At the time, only Linux 32-bit and 64-bit packages are generated from Munipack's source tree. The installation itself is really simple like installation of a Linux game. Unfortunately, the distributed binaries occupies a lot of space because they must contain wxWidgets, libpng and cfitsio libraries.

The binary distribution tree stores two sets of binaries. The bin/ directory contains statically linked routines. They will work without any system setup. Opposite with this, the lib/munipack/bin/ contains shared binaries which needs libraries linked against in a system or a specified directory. The setup is done via a shell script in bin/ directory.

Binary installators are created with help of Makeself utility. The packaging itself is done on base of ideas published in that article: Linux Game Development by Troy Hepfner.

The output binaries will probably work on any modern Linux. I haven't resources to directly prepare of packages for a specific Linux distribution like Ubuntu, Mandriva, Fedora etc. The script to generate of the binary packages is included in source distribution in dist/.

In any case, I still recommends source code installation including compilation itself. The advantages are:

• smaller binaries, optionally with tuning
• better setup of optimization, be faster

Especially, the compiled binaries are smaller and uses system libraries (usually optimized). They are occupied both less disk storage and a computer memory. The optimization on a target platform and a processor can significantly speed up of run. Especially using of advanced instructions (SSE,..) on 32-bit processors, which are not switched on by default, can be important.

Also, I strongly recommends use of Intel Fortran compiler (ifc) which strongly boost run. Unfortunately, binaries created by ifc can't be freely distributed. Ones are created by GNU tools: gfortran and C, C++ compilers.


Warning

Munipack is in rapid development phase now. You can find bugs, a strange behavior or something like this. Also anything can be changed.

Mandriva's repository of Munipack

Petoš is maintaing himself a repository with some useful software for Mandriva 2009.0. A presence of the current version of Munipack including dependencies (mostly cfitsio) is good news for us. The repository is easy available. Use the command

urpmi.addmedia "Petos" http://physics.muni.cz/~petos/mandriva/2009.0/i586 with media_info/hdlist.cz

to add it to your sources. The repository is for 32-bit branch (i586) . Packages doesn't contains any description and a digital sign. Ones are required to be used together as whole repository (not as independent entities).

BIG THX!

Note. The distribution of binary packages is generally a good idea. But the horrible fragmentation of unix world make me impossible to maintain (at least) some great Linux distribution (Debian, RedHat/Fedora, Mandriva, SuSE, Gentoo,..), *BSD (Free*, Net*, Open*) or Solaris. In despite of the worry, I speculate about this way.

Strange ls & fork

This weekend, I rewrote internal parts of some (darkbat, flatbat, autoflat, meandark, kombine) utilities. The utilities are internally divided into two parts. A wrapper part made interaction of a second part (core of execution) with its environment and user. The core itself provides a required functionality. The wrapper runs the core as a sub-process and both parts communicates via a pipes (output of wrapper is connected to input of core) I did it by a module coded myself (primary for Nightview). The code uses system call fork (along with related ones). Now, It has been replaced by popen system call to simplify and standardize of wrapper's code. The change include some lost of efficiency of code (a shell is invoked) but additional occupied resources are insignificant.

My code to run sub-process work correctly but it has some in-advantages:

• the code is non-standard (developers usually abuse on ones)
• it's complicated to use (requires to use of more complex code)
  

The most important reported error appears for environments with system PATH variable set-up without current directory (without dot). The system reports (Thx to Kočka, M.Zaťko) following strange error:


$ ls * | mdark @
MEANDARK Version 0.1, Copyright (C) 1997-06 F.Hroch, Masaryk
University,Brno,CZ

Subprocess execution failed: No such file or directory: mdark.bin


Nevertheless, both mdark and mdark.bin has correct permissions and the same parent directory. To solve the problem, simply add dot to your system path (for bash: export PATH=$PATH:.) or install any newer version of Munipack.

The separation of code to the wrapper and the core has mostly historical reason. Fortran didn't supported UNIX environment up to version Fortran 2003. All implementations contains some unofficial extensions but it may be syntactically different (for example ifc, g95, gfortran,g77 vs. SUN's Fortran). The separation also provide another additional advantages. The core can be used separately as a part of another great code without any connection to a command line fronted (represented by the wrapper). For example, the core can be easily used in some graphical or web environment.

Also, I found some confusing behaviour of system command ls (list of files in directory). When ls is aliased in zsh (bash?, tcsh?) by the way

ls='ls -F --color'

(color is crucial) we get this really strangle error reporting


$ ls -F --color image.fits | mdark @
MEANDARK Version 0.2, Copyright (C) 1997-08 F.Hroch, Masaryk University,Brno,CZ

image.fits:
The following error(s) has been occured:
input file URL is missing closing bracket ']'
could not parse the input filename: (ffopen)

Of course, it is due to hidden escape sequences which doing output list coloured. I have no idea how to suppress it or how recognize these color marks on input. You has been warned.

Munipack stable release

Yesterday, I finished work on a simple script to make of a regular release of Munipack. Geeks from Fedora Astronomy group included Munipack in their release. Unfortunately, they used a really historical version (it may come from past century). I think, it is due of may unconventional designing and releasing of Munipack (also Nightview) versions. New versions are generated once per day from cvs repository as nightly builds. Many of peoples are supposed that it is a development version only and it isn't suitable as a production release. It isn't true, but all peoples suppose it due to the naming scheme.

To suppress any confusion, the version issue is improved to a conventional naming scheme from now. The "stable" release will be also generated from cvs repository. The generation will less frequent (only once per month), the archive will named as munipack-0.4.?.tar.gz with incrementing only last digit. Also, the archive will generated if the following rules will be satisfied:

• the last changelog record is older then approximately 35 days
• the changelog records are different

I think, it will prevent incrementing of minor version without change of content and it will give me some time for developing and bug-fixing of a new code (you can still use of nightly builds in meantime).

A ridge of algorithms

I spend some time with the growth-curve method during last days. Its looks nice, but relative hard to control.

Some side product of the game is comparison of the original Stetson's algorithm for estimate of the arithmetical mean with new ones. To get mean, Stetson have introduced some rejection-type algorithm. I've no more detailed information about it - there is no reference in source code or a paper. Opposite with this, Munipack estimate of the mean by a method on base of minimisation of a general function. It minimises function in shape of the least-square near of minimum and suppress it to zero otherwise by method of the maximum like-hood. The chapter describing of a robust statistical methods in Numerical recipes is an ideal start point to get detailed view to this field. A source code of Munipack uses of those ideas, but it doesn't describe it. The new estimator has been included to Munipack approximately eight years ago.

I compared of the estimators on case of the ridge of magnitude on differences of following apertures. Both three-dimensional graphs shows number of the differences in cells specified by apertures and its value's ranges. The horizontal (x) axis takes magnitude differences, the horizontal (y) axis takes size of aperture and vertical (z) shows the number of values in that bin interval. The top side of the data cube shows projection of the number of values to a plane. Colors of the histogram maps number of points: dark - near zero, light - near maximum (hundred).

Muniphot's ridge

Stetson's ridge

Both images looks similar. Only one difference is a small systematic shift of the ridge to negative region on Stetson's graph. It is about 0.01 in magnitude, so I think, it is not important in real situations. Perhaps. It may means that the new method for the mean estimations works little bit better.

Ridges height strongly depends on aperture. Small values gives perfect estimation against apertures greater that fifteen (in my case) when the the histogram shows no peaks. The characteristics may be important for growth-curve fitting.

As test data for both graph, I used combined image of M67 as in previous post. However, graphs of ridges looks differently (gnuplot's pm3d feature has been used on graphs here). It is due of my mistake during data processing. The previous perfect ridge with strong peaks at large apertures comes from many zero's differences of bad magnitudes of 99.999. Keep smiling.

How aureole shades stars

The photometry (magnitudes of stars) produced by Munipack is an aperture photometry, which means that a magnitude is determined only as a sum of a flux inside an artificial aperture. The aperture photometry is sufficient for a relative comparison of stars. It should be very useful in many applications like observing of variable objects (variable stars, asteroids, afterglows,..), but there are many of additional requirements (calibration of photometric system, precise photometry,...) in which the aperture photometry start to fail.

Briefly, an image of a star is theoretically a point, but Earth's atmosphere and telescope's optics spread the point to a blob with Gaussian central part and an outer parts showing an "aureole". The problem of the aperture photometry is our ignorance of outer radii which may include an important fraction of a total flux. If we will ignore the aureole's flux, any magnitudes will depends on atmospheric conditions (seeing spreads stars with dependence on its air mass or a night) and on magnitude of the magnitude (A golden rule of differential photometry is to compare objects with similar magnitude). It means that precise photometry requires more sophisticated approach.

Described problems bothers CCD's photometrics for a long time. They are described in articles of classics at 80'. Howell(1989) points to properties of the aperture photometry for differently bright stars. He shows that total flux of bright stars is determined relative precise, but any small error in determination of background for any faint star strongly affects total fluxes. The solution of the problem did published Stetson(1990) in that great article. He developed a method on base of cumulative distribution of magnitudes of stars (in astronomical dialect the grow-curve method). Please read the paper, I have no time to transcribe it here. The most important ones (from my point of view) are: The grow-curve method is complement to PSF method (PSF <=> precise relative magnitude, grow <=> precise calibrated magnitude). The model of cumulative profile of the star as an integral of PSF can be described by a sum of analytic functions (Gaussian, exponential and Moffat - Moffat is generalisation of Lorentz).

The grow-curve method for a large radii can be described by Moffat's function ~1/(1+r^2)^A (A=2 for Lorentz). We suppose that all stars on the image has the same cumulative (grow-curve) profile (integral of PSF modeled by Moffat). To construct of the mean grow-curve for all stars with no matter to its brightness, Stetson uses ratio of fluxes in et sequentia of apertures, eg. the following differences of aperture's magnitudes.

M 67

I try it on image of the M 67 open stellar cluster exposed on 2008-02-26 at R filter via 0.4m telescope at HaP MK Brno. The standard Munipack run has been done. About 250 stars has been found. The results included in graph in fashion of the Stetson's article are included.



I take out of these basic fact from the graphs:

• The scatter of the points is relative great over five magnitudes (not all are included). It is due to random errors, disturbance of magnitudes of overlap stars, wrong determination of background for faint stars.
• A pretty description of magnitudes displays frequency of magnitudes in an interval of difference magnitude and apertures. There is a spine visualising of most frequent values of the variables. I'd pleasure from behaviour of the spine at large radii where the values converges to zero. It means that the robust mean algorithm used in Munipack to determine of sky level is really good.
• The graph show differences about 0.1 magnitudes at radii usually applied to photometry. The function is not a profile itself. It means that the difference between a real and determined magnitude will a few tenth of magnitude. In other word, the calibration of Munipack's aperture magnitudes will depends on actual observation conditions and the calibrations derived from the magnitudes will contain an systematic error which will be depend on magnitude of a star.

Visualisation of found stars

A long time, munipack's user calls for better visualisation of data processing. Their flustration probably leaded to creation of clones like CMunipack or some others "data visualisation" utilities. Today, I had uploaded to CVS a small script as a wrapper around ds9. The script generate region file (with a basic overlay graphics elements) for ds9 and invoke one with this file. It plots circles with centres at founded stars (included in .COO file). The circle radius is determined by mphot.opt's parameter fwhm of star or it is defaulty set to 3.


A similar script created Thorman for gaia 6 years ago. Both can be found in script directory. Both will not be instaled by make install. If you want its, copy ones to your */bin directory.

A hang-up under Ubuntu

Today, a hang-up of munimatch under Ubuntu and gfortran compiler has been found during work on processing of globular clusters images. Munimatch hang-ups with the listing on output:

f@filip:/tmp/munipack/munimatch$ mt ref=m5_06R.SRT m5_06V.SRT

Match files : m5_06R.SRT -> m5_06V.SRT

Matrix : 1.0025209128 -0.0000284573
0.0000284573 1.0025209128
Shift : -38.8969865074 18.3495641725
Scale : 0.9975158490

The parent process has been consumed of all CPU time and indicate no progress after a while. Experiments under Gentoo shows equivalent behaviour.

The detailed inspection of source code revealed problem on this line:
do while(.true.)
read(1,'(T7,2F9.3)',end=970,iostat=ii) x,y
i = i + 1
...

The code fails when an error occured (during line read when format is different) and iostat sets error variable to a non-zero value. The replace of the line with equivalent code

read(1,'(A)',end=970,err=970) RADEK1
read(RADEK1,'(T7,2F9.3)',iostat=ii) x,y

corrects of the hung-up problem. The experience shows that the intel ifc compiler, g77 and sun's fortran compilers work without any problems. It may be a bug in gfortran compiler. (Moreover, additional, an index range error has been corrected also.)

Update. The described bug has been corrected. Excellent work! Thank you!