hroch's diary

Konve and picko

2012-01-15T21:17:00.000+01:00

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

2011-10-22T02:05:00.001+02:00

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

2011-06-07T09:41:00.004+02:00

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.

Photon rain statistics

2011-03-15T10:38:00.005+01:00

Following discussion with Mr. Pavel concerned on likelihood analysis of Fermi's data (see also the general description of likelihood analysis) and a creation of an illustration for Practicum, I created a toy model demonstration of capture of photons by event-counting area detectors. The key property of a fictions detector is to collect photons during unique time-samples by increasing pixel value in a random place. We can metaphorically designate the model as a photon raining detector.

More precisely, the algorithm can be represented as (sources: ccdnoise.tar.gz):

start
generate random X coordinate
generate random Y coordinate
add +1 to pixel on X,Y
back to 0.

(All, that's all).

The probability of capture of an event in the time period is given by Poisson distribution

p_k (fT) = (fT)^k e^(fT) / k!

the p_k is probability of capturing of k-photons during time period T when averaged flux is f photons per time unit
the events are statistically independent (photons doesn't interacts)
consequence is that the zero, one, or more photons can be captured in a single pixel during T

Final results has been displayed in following animations. Both show imaginary detector on the left and empirical distribution - histogram (number of detections in a given level) of photons.

Shortly after star animation.

The first animation shows state shortly after start of raining. We can see:

the noise in start is relative huge, noise disappear with time
the mean gray goes from black to (light-)gray
the distribution histogram is highly non-symmetrical shortly after start
mean of the distribution increases proportionally to time
the distribution metamorphosing from Poisson to Gaussian

Second animation shows status on a long-term scale:

the noise is strongly reduced, practically disappear with time
the noise is not visible at end of simulation (uniform color)
the width of distribution increases with time,
but relative uncertainty decreases as sqrt(t)/t suppressing noise
distribution histogram approaching Gaussian, very nice illustration of the law of large numbers

Note that imaging has been set to show increasing mean during first animation and reducing relative noise during second animation.

After long time animation.

Along with the animations, I computed mean and standard deviation of rain. The results are in graph. The standard deviation is perfectly fitted by square root. One is excellent demonstration of the important property of Poisson distribution.

Barnard star constantly in motion

2011-03-04T22:11:00.008+01:00

Just next short update to those posts Barnard in time and Continuous motion of Barnard's star.

Animation of proper motion of Barnard star.

Track of Barnard star since 2001.

Coloring release

2010-10-17T13:43:00.005+02:00

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

Continuous motion of Barnard's star

2010-03-04T13:57:00.006+01:00

Some time ago, I published the article about visualising of the proper motion of Barnard's star. Now, I had added images of next two years. As we are expecting, the position of the object is nicely predictable.

The last two images (years 2008,2009) are taken during autumns opposite to solstice's images at 2005,2006. Any shift due to parallax is not visible. Simbad gives value for parallax about 0.5" which can be visible with our instruments. By my opinion, when we will more carefully selecting time between exposures.

Barnard's star images has no unique brightnes due to different observing conditions.

Barnard's star motion between 2001 and 2009. Full field of view.

A Graphical User Interface for Munipack

2010-02-11T00:22:00.008+01:00

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

2010-01-15T22:35:00.005+01:00

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:

Get center of a picture in pixels as half of both sizes.
Estimate a center of projection in spherical coordinates by mean.
Project spherical coordinates to rectangular ones.
Estimate scale as mean ratio between distances of projected and measured distances of objects.
Estimate angle of rotation between projected and measured coordinates by using of property of scalar product of vectors.
Compute the transformation by some minimization method with starting values given by items 3,4 and 5.
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:

Estimate median of absolute deviations (MAD) using of minimization of absolute deviation (Nelder-Mead).
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.

Fitting of Straight Line

2010-01-05T21:01:00.009+01:00

One from most trivial problems of statistical regression analysis is fitting of a straight line. I selected this well-known problem to illustrate

usage of Minpack library to least square fitting by the least square method (LS) together with
usage of robust statistical methods and also to prepare
a simple reference example for testing of any software.

All required code can be found in the archive. Please read README for detailed description of included files.

Reference Data and Solution

As data for a working example, I selected a tabulated values for a straight line from excellent mathematical handbook: Survey of Applicable Mathematics by K. Rektorys et al. (ISBN 0-7923-0681-3, Kluwer Academic Publishers, 1994). The data set is included in the archive as line.dat.

Normal equations:

 14*a +  125*b = 170
125*a + 1309*b = 1148.78

and LS solution:

a   = 29.223
b   = -1.913
S0  = 82.6997
rms =  2.625
sa  =  1.827
sb  =  0.189

Using Minpack

Simple usage of Minpack in LS case is straightforward. One calls hybrd (Jacobian is approximated by numerical differences) or hybrj (must specify second derivatives) and one pass a subroutine to compute vector of residuals in a Minpack required point. Minpack uses Powell's method which combines location of minimum with conjugate gradient method (locate minimum in direction of most steeper slope) far from minimum and Newton's method (fit the function with multidimensional paraboloid and locate minimum by intersection of tangent plane with coordinate axis) near of minimum.

For the straight line, we define

a + b * x_i

and minimizing of sum for i = 1 to N:

S = ∑ (a + b * x_i - y_i)²

The vector for Minpack is

∂S/∂a = ∑ (a + b * x_i - y_i)
∂S/∂b = ∑ (a + b * x_i - y_i)*x_i.

The Jacobian is than

∂²S/∂a²    ∂²S/∂a∂b
∂²S/∂b∂a   ∂²S/∂b²

N          ∑ x_i
∑ x_i       ∑ x_i²

All the sums can be found in minfunj in straightlinej.f90.

The call of hybrj search for a minimum of the function. On output, the located minimum is included in fvec and I added a code to compute covariance matrix to estimate statistical deviations of parameters and their correlation.

With gfortran I get the solution on 64bit machine:

....

minfun: par =   29.22344    -1.91302  sum =  82.68976
minfun: par =   29.22344    -1.91302  sum =  82.68976
hybrj finished with code           1
Exit for:
algorithm estimates that the relative error between x and the solution is at most tol.
qr factorized jacobian in minimum:
q:

0.10769513068469699       0.99418396628934158
-0.99418396628934158       0.10769513068469688

r:
152.97596122677001        1371.8039727109779
1371.8039727109779        17.656368881644468

inverse of r (cov):

0.25799238244686612      -2.87651125847342495E-002
-2.87651125847342495E-002  3.20772561895261684E-003

covariance:

1.7777772679919355      -0.19821501231688973
-0.19821501231688973      2.21038374592466315E-002

No. of data =           14
solution =    29.223435764531654       -1.9130248056275454
with dev =    1.3333331421636287       0.14867359368511487
residual sum  =    82.689756238430220
rms =    2.6250358130641160

The results must correspond (within precision of tree digits) to the reference solution. As we can see, there is a great discrepancy in deviations of parameters. The Minpack's estimation is little bit optimistic. I think that is due to difference between matrix inversion (which is usually used) and Minpack's covariance estimation. On the other side, the values are the same from practical point of view.

Just for information. The inverse matrix (all by Octave) of Jacobian in minimum is (inv(.))

 0.4846353  -0.0462792
-0.0462792   0.0051833

and the QR factorization ([q,r,.]=qr(.)):

q =
-0.995472   0.095060
-0.095060  -0.995472

r =
-2.0541e+00 -1.2576e+02
0.0000e+00  -1.3150e+03

The Q matrix columns are base vectors (eigenvectors) of solution (the principal axes of covariance ellipsoid) and the diagonal elements are estimates of eigenvalues values (major and minor semiaxes of the ellipse) [l,v]=eig(.).


l =
-0.995457   0.095208
0.095208   0.995457

v =
2.0447e+00   0.0000e+00
0.0000e+00   1.3210e+03

The second supplied routine straightline.f90 does the same work but without explicit knowledge of the second derivatives. The Jacobian is estimated by numerical differences.

The solution can be also done via lmdef, lmder routines in Minpack. It is equivalent to presented solution but doesn't offers generalization toward robust methods.

Robust Fitting

The reference robust fitting procedure is included in rstraightline.f90.

The fitting is logically divided onto two parts. The first part implements minimizing of sum of absolute deviations to get robust estimation of proper solution and MAD (mean of absolute deviations). There is little change with respect on LS because minimizing function have no derivation in minimum. We need another method without using of derivatives. I'm using code prepared by John Burkardt, namely using Nelder-Mead Minimization Algorithm (simplex method). I slightly rearranged the code to nelmin.f90.

The resultant parameters are used to obtain MAD by looking for its median by a quick way algorithm described in Niklaus Wirth's Algorithms + Data Structures = Programs.

The solution is than passed as start point for hybrd which is the second part. The minfun is similar to non-robust version. Only difference between predicted and computed solution (residual) is not directly used, but a cut-off function is used (Tukey's function). This small change does robust fitting itself.

.....
medfun: par=   30.57930  -1.918842   sum=   29.9467137
medfun: par=   30.57930  -1.920842   sum=   29.9506577
ifault=           0   29.940157123526994
t=   30.579306941153348       -1.9198428764730142
4.3939266204833984        2.9615066
minfun: par =  30.57931  -1.91984   sum =  106.17691
.....

minfun: par =  29.24548  -1.91425   sum =   82.69177
hybrd finished with code:           1
Exit for:
algorithm estimates that the relative error between x and the solution is at most tol.
qr factorized jacobian in minimum:
q:

-0.10942034931424138      -0.99399556696996860
0.99399556696996860      -0.10942034931424133

r:

29.315789045435952        295.17538616058539    
295.17538616058539           4.3667770003656630

inverse:

5.3177769129754946      -0.52802747846866527
-0.52802747846866527      5.24418460845494372E-002

covariance:

2.7756865626932967      -0.27561118127052436
-0.27561118127052436      2.73727405045027551E-002

No. of data =           14
solution =    29.245477844988198       -1.9142493591979692
with dev =    1.6660391840209812       0.16544709276533920
residual sum  =    82.691772460937500
rms =    2.6250678159642766

The output values are practically the same as in non-robust case. Only the difference is estimation of parameter's deviation. I'm using the formula recommended by Hubber (1980), eq. (6.6) p. 173.

The real power of the robust fitting can be easy demonstrated by adding any outlier (point with really different value) to the set, for example, a point with coordinate 10,100. Try to see the robust algorithm in action. It should be practically the same while non-robust solution gives some strange values.

Minpack Fortran Interface

The original Minpack is written in Fortran 77. I'm using modern Fortran (Fortran 90, 95 or 2003) which supports better type checking via interfaces. I prepared such interface which is included in Archive as minpack.f90 and must be passed to compiler during compilation. The module did not changed original API to Minpack routines to prevent any programming errors. So you also must pass to the routines "working arrays" (wa). One is used in modern Fortran more elegant way as automatic arrays (arrays allocated automatically when subroutine is entered and deallocatedon its exit).

Estimation of an initial solution

The solution will not depend on starting point only in linear case. Every complex real) case will lead to non-linear solution with a lot of local minimums which will attract the simplex or the gradient (Powell's method) to a "wrong" solution. To locate global minimum (eg. required solution), I recommends use of genetic algorithms as predictors of a global minimum. The genetic algorithms will locate right minimum with a low precision and we can use some modification of above codes to determine the minimum with required precision.

Photo Gallery

2009-12-25T13:08:00.002+01:00

Recently, I created a photo gallery with my personal photos. The gallery is fashioned only as preview for fast look-up. It contains only non-processed images. I think that it would be better than current state when I'm buffering images somewhere on disk(s). Images which waits for detailed image processing (panoramas, various image operations, etc), can be public available by this way.

The gallery is generated as a static web pages by llgal. The generation is very fast. It needs only manually download images from camera and running of some scripts. I have checked also photon which do similar job, but neither full-evening hacking didn't fit my requirements on

appearance and functionality.

All images, in the galleries, are generated from RAW Canon files by dcraw and convert (Imagemagic). As output format, I choose JPEG to importantly reduce image sizes for fast browsing. The quality is poor, but images are small.

for A in *.CR2;

# from RAW to 1000x666 pixel JPG

dcraw -c -f -q 3 -w -h $A | convert - -geometry 1000 ${A%CR2}jpg

# add copyright

composite -dissolve 30 -gravity SouthEast copyright.png ${A%CR2}jpg ${A%CR2}jpg

done

An important parameter for dcraw is -w which set color temperature from parameters supplied by a camera. It is important: when I have set the color temperate to a different one, my older images are toned to red. That is because of dcraw default uses 6500 (for D65 illuminant). I have set the temperature according of Sun (5700) which is bad idea because of illuminant D65 have no thermal spectral flux density.

I'm adding a signature to every image as L.Lessig recommends. The signature itself is created as a muster by the command:

convert -size 80x17 xc:none -font Courier-Bold -pointsize 14 \

-stroke black -strokewidth 5 -annotate +4+12 '© F.Jetel' \

-fill white -blur 0x4 -stroke none -annotate +4+12 '© F.Jetel' \

and added with composite command (above in processing loop) to images. The signature image has transparent background (xc:none), and some decoration (options -stroke and -blur). The signature is partially transparent when it added to images to suppress thickness (-dissolve).

For documentation purposes it is important include useful information about images. Unfortunately, JPEGs created by dcraw conversion has removed an important information as a time of exposure etc. So I'm adding selected exif information to JPEGs via exiftool:

exiftool -tagsfromfile "%d%f.CR2" -r -ext jpg .

From files prepared by the described way, it is possible create of a gallery by the command:

llgal -f --exif "FileName,ImageWidth,ImageHeight,CameraModelName,CreateDate,ExposureTime,ISO,FocalLength,LensType" --title "Geminidy 2009" --cf

Also, for updating of list of galleries, I'm using the command:

llgal -L -S --exclude copyright.png --title "Photo Gallery"

That's all. Please, change the name in copyright when you will copy my scripts to your galleries.

Munipack vs. Mercurial

2009-12-10T00:24:00.002+01:00

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

2009-07-19T23:32:00.003+02:00

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.

Recent progress in RAWTRAN

2009-03-28T18:19:00.003+01:00

There is a summary of last progress in rawtran (see previous posts: Dec 2008, Jan 2008).

I specified more precissely of the definition of the FITS color format. Be inspired by PNG format (libpng), I introduced a new keyword to the first dummy header

COLORTYP

by PNG_COLOR_TYPE_* to be setup to (string) value RGB for color FITSes. It will be useful for any software to easy recognize of the color format. Also the definition require additional condition on size of the images that is required to be equal for all color bands.

Another change is replace of the CBALANCE header keyword in header by the keyword COLORBAL (COLOR_BALANCE) with the same meaning. I think, it will be put better understanding to users. The CBALANCE is now obsolete and I don't expect any back-compatibility.

I added another type of conversion. The new type 4 produces multi-band FITS file including of all four Bayer colors in separated FITS image arrays. The type provides absolutely raw access to RAW data. It is another multi-band FITS different of the color type.

Some additional changes has been included to rawtran recently:

Cleanup of code.
CREATOR keyword.
EXIF information by dcraw is written in the header block with "begin" and "end" delimiters to be simple parsed.
Update of man page.
Run-time detection of dcraw.
A switch to pass additional parameters to dcraw.

It is still uncertain of the true meaning of Daylight and camera multipliers provided by camera and its meaning on a color white balance.

This post is a small virtual present to anniversary of FITS format which has been established exactly 30 years ago.

Crumbling walls of Děvín

2009-01-26T01:56:00.009+01:00

We had a trip onto ruins of Děvín (Dívčí hrad aka Castle of maid aka Maidberk aka Maidenburg) on mount of Pavlovské vrchy (Pálava, Pavlov's mountains) at Saturday.I acquired a panorama view of dam Nové Mlýny and a part of South Moravia with on top of the crumbling walls. A small village near center of the image is Dolní Věstonice, where prof. K. Absolon found the prehistoric nude sculpture now known as Věstonická venuše. All area under the mounts has been the first part of human settlement on Moravia.

The panoramatic view from Crumbling walls of Děvín. The large version by RAW pictures can be compared to one by JPEGs adjusted by Canon EOS 30D. Is a pastel better than reality?

We also visited a next airport near of Strachotín. It has a nice horizon profile. Unfortunately, a gas station is on the east. Any zodiacal light has not been detected again and the Venus's shadows may be visible, but not by us.

Two Venuses on west in large. The zodiacal light is not visible (?) due clouds.

Pálava at night. Děvín is at peak on left. The clouds on right over Pálava are illuminated by Mikulov town.

Lights on east. The most intensive source is probably a gas station.

Brno on horizon on north at distance about 30km.

Thx for nice accompany to Maceška.

Approximations of a sidereal time

2009-01-18T00:38:00.005+01:00

A precision of computation of a sidereal time has been arouse curiosity of me during last days. So I experimented with formulas on the page Approximate Sidereal Time. I compared of computed GMST, the low GMST version ( GMST = 18.697… + 24.0657…D) and GAST with data by Horizons ephemeris. The enclosed graph represents of final results. The functions shows residuals of the computed sidereal times minus Horizons's ephemeris in time the interval from 2000 to 2050. For example, the red line represents of the difference: GAST - Horizon.

Comparison of sidereal time approximations. Click for SVG version.

As we can see that GAST is a perfect approximation for general purposes. But the GMST's approximations are also acceptable. The GMST is not corrected for a nutation with period of 18.6 year and one is nicely visualised by a big wave. A rapid wave superposed onto the nutation period is demonstration of annual orbit of Earth. Strangle breaks at 2006.0 and 2009.0 are effect of the adding of leap seconds. The low precision GMST approximation has visible differences, with respect to GMST, only at the end of the time interval.

Conclusions

To compute of sidereal time with low precision use of the low precision formula: GMST = 18.697374558 + 24.06570982441908 D, where 18.697… is sidereal time of the reference time 2000-01-01 at 0 UT, 24.0657… is a ratio of synodic and sidereal periods of Earth and D is days (and its fractions) since the reference time.

To compute of the sidereal time with high precision use of the algorithm for computation of GAST.

An evening with Venus

2009-01-03T21:38:00.005+01:00

The extraordinary brightness of Venus as the evening star invoke many assorted fantasies. Lovers dreams about a paradise on the Venus, which is an island in the universe darkness. For peoples believing on Martians, Venus setting appears as a landing of its spacecraft. Venus looks as in fast motion, especially, when Venus is observed in some clouds. Venus setting can be also very impressive for painters, photographers and astronomers. The magic performance of ambient light, twilight sky, surroundings and Venus itself offers the absolutely extraordinary experience.

I spend one evening with Venus by observing of the setting and many days and evenings with processing (and related business) of acquired images. My primary goal of the observation was pointed on visual demonstration of an astronomical refraction. The follow-up processing has been inspired me to mining more information from collected images.

Snapshooting

To acquire of nice sequence of refracted Venus, I selected Kotvrdovice's airport what I visited some time ago. The place offers relative good altitude about 560 meters over sea level, so I expected perfect horizon together with a separated place available by a car. Kojál top at proximity has the no separation, place to parking and is close to a road. The expecting Venus setting point is situated in direction of south part of Moravian Karst with low air (light) pollution.

View Larger Map

I pitch my tripod at point 16:47:20.1 E, 49:21:52.1 N. The place is on a rural road and on a local ridge near of a hunter's hide. The first snapped image shows a scenery at moment after my arrival.

The first image.

I manually grabbed a set of images for every minute with start about 15:35 UT and finish at 17:18 UT (but see next note!). Total 101 images has been acquired. Canon EOS 30D has been used with lens EF-S 18-55mm, f/5.7 without any zoom, ISO 1600, a minimal diaphragm. Exposures times has been changed during a light fade of the twilight as I completed into the table:

15:35-15:49 15 1/100
15:50-16:00 9 1/10
16:01-16:15 13 1/2
16:16-16:39 23 4
16:40-17:18 38 8

An air view to Kotvrdovice's airport. The hide is on left part between the airport's facility and a wood. Kojál transmitter at left top corner, a village Krásensko at top, a small part of Senetářov and Kotvrdovice on right edge from top to bottom (in this order).

Time non-synchronisation

Unfortunately, I forget done any time synchronisation of a interval clock of the camera before or after of the trip. So precise time synchronisation is lost forever. Fortunately, I check of time on my mobile phone at start of observation but for information purposes only, without required (on second) precision. It means that all times are considered to be inaccurate (± 30sec). The relative precision is better than 1 sec.

Preprocessing

I acquired all images manually by clicking of button on Canon's body. So I expected that the images can be each other shifted. Therefore, I used the translation property of a cross correlation of Fourier transformation of images to precise co-add of all images to same origin. So, I created of the forward FFT of reference and working copy images. The Hanning window function has been used for bottom part of original images. The phase-correlation and backward FFT followed. Finally, shifts has been computed as centroids of delta function-like peak.

Shifts has been released only for integer segments. I expecting that precision would be not grow, if a non-integer shifts will be used and interpolation would be degrade sharp features of the output image.

An example of sum of images with and without shifts is shown on the zoomed subimage. The image on the left is simple co-add of all images while the right image shows shifted and co-added images. In my opinion, the careful preprocessing leaded to a little bit sharper picture.

The displacement of color layers worked well when I used all colors together of weighted by white multiplication factors (eg. on grayscale images). Initially, I tried to get shifts for every color layer individually and than compute the mean between its. I expected a fine shift due to Bayer mask, but the shift showed some random behavior as a perhaps product of a noise.

The final image has been created by a method analogous to Iris function ADD_MAX by Ch. Buil. Simply, the output image is not only sum (or mean) of two images but one gets the brighter pixel of images. The method grows intensity of a potentially moving inter-image object (Venus). Without this, the Venus trace will be lose on evening sky. However, final colors of the (variable) sky background may be very strange.

The white balance parameters provided by the camera gives not satisfactory color balance. Therefore I equalized the image by hand. Usually on a white object on images like Venus or by automatic way with -fr parameter of fitspng.

The most important part of the processing is on base of my specific routines. I'm attaching link for an inspiration.

Venus setting on 15 Nov. 2008 . This composed image shows track of Venus (central body) above south-west horizon at Kotvrdovice's (CZ) airport. The chain of pearls has origin in short exposures of Venus in one-minute intervals. We can see that the finish of observed path is raised with respect to expected (by following of beginning part) one. It is exhibition of the astronomical refraction of the light in Earth's atmosphere. The track also shows decreasing of amount of the light and its reddening during the setting. Both effects are product of scattering and absorption of light in air. Read the post for detailed description.

Astrometric calibration

The astrometric calibration has been done by Gaia software on grayscale version of one of latest images including some stars. The calibration shows that a projection of the lens is gnomonical with precision better than 2-3 arcmin/pixels. A scale is 0.0165 deg/pix = 0.99 '/pix (minute per pixel). A field of view is 29°×19°. The center of the calibrated image is at coordinates 19:13, -26:00 at 17:17 UT (time epoch). Equatorial coordinates has been rotated about 25° to image's coordinates. The image itself is rotated around vertical (horizontal coordinates) by approximate 1°. The parameters are visualised on the image:

Astronomical refraction

The main goal of my work is to show effect of the astronomical refraction. It can be easy obtained by observing of any point source in time, but when the object downwards really slowly with acute angle to horizon, the observed path may be visibly deviated from non-refracted one. The deflection is nicely demonstrated on annotated images:

Technically, the refraction can be described on a graph of dependence between the observed and the true (not affected by the refraction) zenith distance of some object. The expected values has been computed by a standard way from linearly interpolated coordinates of Venus by NASA's Horizonts. It agrees with values by Xephem.

Measured coordinates has been derived from grayscaled images. I estimated centroids of Venus by the weighted mean. The error of the determination is order of tenth of pixels/arcmin.

The next step is computation of the zenith distance (or elevation) of Venus. In principle we can use two methods:

Plain. Using by a scale and a simple geometry, we determine distances in pixels of Venus and horizon. The Euclidean geometry with only rotations and translations is used.
Gnomonic. Using by known rectangular coordinates and the gnomonic transformation, we determine equatorial coordinates together with transformed to horizontal coordinates.

Both methods may include some systematic errors. Simple plain geometry has known deviations from spherical coordinates when angles gets values over five degrees. The gnomonic transformation fits spherical coordinates by the better way, but we are not sure that our object lens display some scene by the expected way.

The results of both methods of determination zenith distance from photographic plate are plotted in refraction graph. The plain method shows nonlinear great residua and it is clearly unusable. The gnomonic method is little bit better but there are still great differences.

I also plot of Bennett's approximation of the refraction formula according to Astronomical Algorithms by J. Meeus. Other simple refraction laws on base of tangents of the zenith distance (one or tree order) are unusable in the range of observed quantities.

The visible discrepancy between the approximation and observation has unclear origin. The statistical errors are visualised by random noise. I notices relative higher noise on beginning of observation how it vanished when the ratio of signal to noise is growing. I expected that the refraction will affected by some clouds near of the horizon. Nevertheless, the appropriate part of the measured curve is nicely smooth.

The discrepancy is not due to uncertainly on time determination (the change a few minutes minute slightly modified profile but not importantly). It is also valid for changes in an atmospheric pressure and an ambient temperature.

Only for information, I tried to fit the data by any way. A final fit is a set of points tightly reproducing of the Bennett's approximation. The fit has two free parameters: The relative time between the astrometry approximation and observation times has been changed relative about minute (this is principally incorrectly). The change leaded to a little bit deflection of refractive curve so the profile is more similar to the Bennett's approximation. As second free parameter, a vertical shift of 7 pixels/arcmin has been used (also it is uncorrected again).

My own hypothesis of explaining of the measurements is a non-precise model of the (gnomonical) projection. Firstly, I assumed that the projection is gnomonical on full area of the chip. The assumption may be wrong. The gnomonic projection strongly deforms area elements far from center of projection. Therefore, manufacturers can use any different kind of the projection. For example, some "mean" between the gnomonic and a stereographic projection may be used. Secondly, the fitting routine of Gaia assumed such model of the gnomonical projection which have different scales in Right Ascension and Declination, but my images are deformed in some another direction. The images are squeezed in the vertical direction by the refraction. It leads us to use of a model which will be correctly describe the refraction during of gnomonic projection determination. Simply, we can say that the vertical scale will not be more linear, but it will varied with the zenith distance. The construction of the model will not complicated but I abandoned its due to some uncertainty in the time determination and due to low number of stars near of horizon, so I assume, that the corrected method will not give significantly better results.

The refraction itself is a very fascinating field of applied optics. I recommends visit of wikipedia page and pages of Andrew T. Young about refraction.

Photometry

When the light of a setting object pass trough layers of atmosphere, the observer can detect an exponential attenuation of light together with a color change of the object. Both effect are clearly visible on composed image above.

I think than more better visualisation is represented by a standard photometric analysis of images. By the way, I done an aperture photometry by obvious method (simpler version of one implemented in Munipack). The output magnitudes has been normalized by exposure time and calibrated by the known extratmospheric visual magnitude (again by Horizont) of Venus in G band. I didn't used color balance factors and subtract of a dark frame because the ambient temperature varied about ten degrees. I only subtracted a bias of images which I assumed on level 128 for a RAW image.

The spectral sensitivity of Canon EOS 30D is not available. Therefore, I assumed that the property is similar to one of EOS 300D. I approximated the sensitivity in R band by Gaussian with its center on 600 nm and its half-width about 30 nm, G band as then rectangle with the height 100% and in the range 500 - 600 nm and B band as the rectangle with the height 75% and the width 430 - 480nm. By the way, I get correction color indexes as 0.27, 0, -0.38 for R, G, and B magnitudes and a black body on the temperature of Sun. The reliability is low, so the color indexes may contains systematic deviations of order of tenth magnitude.

The instrumental magnitudes has been calibrated via extinction lines in range of 9 to 30 airmasses. To estimate of the airmass I used formula by (perhaps) Young(1994) , see also article on wikipedia. The least square fitting gives following values extinction coefficients in all bands:

B 0.188± 0.003
G 0.114 ± 0.004
R 0.090 ± 0.003

The first part of graph doesn't follow the extinction law and the magnitudes are perhaps absurd. I think that this is the demonstration of effect described in my previous post. It is simply due to extremal height level of background with comparison to the light signal of Venus.

Sky's brightness

The last graph shows surface magnitude of sky near of top of my images (at elevation ten degrees). I selected a rectangular angular area with constant position. The selected magnitudes shows expected profile. The uncertainty may by a few of tenth of magnitude. The values in minimum are a few magnitudes over natural sky. It may be due to really dark sky when the camera detect thermal noise only or the sky may be illuminated by a near village or a town. Note that when Venus set, the Moon has raised on opposite point of the sky.

Color index

The last graph shows dependence of color indexes on time. I note that the numbers has different base than classical astronomical color bands. Only relative changes can by surly determined from the profiles.

The profiles of Venus shows strong evidence for reddening as we expected from visual determination. The graph shows that the reddening may by two magnitudes which mean 5x more light in blue is absorbed or scattered.

The color index of the sky is strongly different. It means that blue sky has arrived more red color. The color of sky is not more blue during a night. This is also bring out the color of the sky on composed image. The sky color is some kind of mean of the color index.

Thx to Fantom for many suggestive ideas.

The post is dedicated to Vladimír Znojil, my diploma thesis supervisor, which died on 29 Dec. 2008.

Improvements in FITSPNG.

2008-12-23T23:32:00.007+01:00

With two appendixes.

Fitspng has been originally developed as an utility for a fast conversion of FITS images to PNG format. It is required for our Monteboo data archive for observed image display in an usual internet browser. The conversion can be also required for example for color imaging (look forward).

Some time ago, I did the conversion by two steps: to8bit utility converted normal (16-bit) FITS to 8-bit with an intensity scaling and convert (utility by Imagemagick) done FITS to PNG conversion. The way have been simple for me (I didn't have learn of libpng API) but one is slow due to high system load and storing of middle product on hard disk.

A long time (two years at least), the functionality satisfies of me, but now I have new ideas and I extended functionality of fitspng with respect on rawtran utility and some new knowledge.

Color images

If a multi-color FITS or tree normal (gray) FITSes is passed to fitspng as file to convert than 8-bit color png is created by the algorithm:

Fits is opened and recognized as multi-color FITS. All color bands are loaded.
The median and mean deviation of positive differences is computed on 10x10 grid (to speed-up the estimation) for every color band. The computation is abandoned when user specified the -fl switch.
These estimated parameters are merged with an user specification by -fr switch. Also white balance is setup via CBALANCE FITS keywords of every band or by -w switch.
Than every pixel is scaled by specified intensity profile, supplied parameters and white balance.
The file is saved as color PNG with RGB colors (without alpha channel). (May be useful add the alpha to image?)

There are two important requirements for the colorization. A simple way how to convert images from a digital camera processed to FITS by rawtran will be:

bash$ rawtran -t 2 IMG_666.CR2 > color.fits
bash$ fitspng color.fits > color.png

Of course, the direct way by ufraw or dcraw will be faster, but you can't apply some enhancing on images and mouse clicking may be really time consuming.

The most important application is on color composing of image data of CCD. The composition itself for tree images in R,V,B filters can be simple:

bash$ fitspng m1_R.fits,m1_V.fits,m1_B.fits > m1_color.png

The default setup of parameters will produce relative nice images but for more nicer images will be need some fine grained tuning via -fX, -w and by specifying of one from transformation functions: asinh, log (magnitude), error function, sqrt and linear transformation. The setup of various parameters by -fX is usually required when a histogram has and non-usual profile (always for non-stellar images).

If you requires nice publishable images, it is absolutely necessary to done basic processing like, dark and flat field correction and detailed photometric analysis. Ideal way is looking for A0 type (not saturated) star and balancing of the images by hand or by -w.

Note, that all single images has its own header with defined keywords which can/are be different. If any keyword is duplicated we get only the first match.

The multi-color FITS has structure:

FITS
+-----------------------------------+
| Primary array - dummy |
+-----------------------------------+
| Extended array - R image |
+-----------------------------------+
| Extended array - G image |
+-----------------------------------+
| Extended array - B image |
+-----------------------------------+

Intensity (flux) scaling

Inspired by Christian Buil, I had implemented asinh intensity profiles together with logarithmic, square root, error function and reimplemented the linear profile. Results are really nice. The profiles are presented on images. BTW, the intuitive color conversion curves which I used with ufraw are similar.

The conversion can be described as an function between output and input data. The input intensity I can be integer or real number without specified range. The output O level has integer range 0 .. 255. The I is transformed to O by

O = f0*f(x) + z0

where f0 is a scaling constant and z0 is black level. The function f(x) can be one from list:

asinh(x)
log(x)
erf(x)
sqrt(x)
x (f0 = 1)

The argument x is computed by a linear transformation

x = (I - t)/s

where t is a "mean" level and s is "mean" deviation. Values t are estimated by fitspng by median of grid pixels with separation of ten pixels (med). The s is determined by the same way on the same set but from positive deviations of t (not from absolute deviations as usually) (mad). Both parameters are corrected by constants u,v:

t = med - 3*mad
s = mad/15

The specified intensity transformation is a product of black magic on images and it can't be derived from an exact axioms. It empirically describes usual parameters of histograms of astronomical images.

The asinh magnitudes are used as photometric product of the Sloan sky survey. They recommends of use of the magnitudes in Lupton et al.(1999) and for color imaging in Lupton et al.(2004).

Working with full directory of images

Fitspng is ideal utility to done fully automatic conversion of fits images. It can be useful for fast look analysis in anyimage viewer or simple file browser. The thumbnails can be generated by command:

bash$ for A in *.fits; do fitspng -a -s 5 $A > ${A%fits}png; done

The switch -s resize the image 5 times.

How to create an animation

If we have images in png format, it is trivial to create an animated gif (with 50 milliseconds delay between images) via convert command of Imagemagic:

bash$ convert -delay 50 *.png animated_sky.gif

Larger animations is preferred to save to mpeg format. It can be created with small script:

---
#!/bin/bash

I=0
for A in *.png; do
for B in $(seq 1 25); do
I=$((I + 1))
N=$(printf "img%04d.png" $I)
ln -s $A $N
done
done
ffmpeg -f image2 -i img%04d.png animated_sky.mpg
---

The ffmepg requires 25 frames per second (at least 10 fps) so we create 25 times links on a single frame. The conversion requires relative small images with approximate size of a post stamp (about 800x600).

Notes.

I spend some time with optimizing of fitspng for speed because the conversion of normal size image gets a few seconds. Unfortunately, any hooks in main cycle are insignificant and, perhaps, the all actions consuming approximately the same part of execution time. The conclusion is that any (great) numerical operations has negligible fluency on execution duration. It is possible to visually inspect of the duration with setup of -v (verbose) switch.

I'm little bit confused about use of keywords of FITS files. They can be defined arbitrary and fitspng can produce fake outputs. I think that the most important is CBALANCE. Fortunately, the keyword can be replaced by -w switch. All others will only put wrong of description of image included in PNG file. The used keywords are listed in source fitspng.c.

The utility is coded in standard C but the coding style is old Fortran like without extensive usage of some user defined types and complicated structure of functions. I believe that the style is fine for coding and long time maintained of filter type utilities. I will not lost in function tree.

I'm expecting additional changes in future.

Examples of images

First image is composed exposition of field of NGC 7635 (Bubble nebula in Cas) acquired during summer 2006 by me and Exebece on MonteBoo Observatory (0.6m refl.) and HaP MK Brno (0.4m refl.) by non-enhanced cameras ST-8 and ST-7 in R filter. The image has been created by composition of 1084 images of total exposure time 95540(!) seconds. The images has intensity scaled by asinh and linear profiles. The differences are most remarkable at central part. The central star is saturated on linear scale, while faint details are visible.

Bubble nebula NGC 7635. Linear intensity profile.

Bubble nebula NGC 7635. Asinh intensity profile.

Second example shows Dumbell nebula (M27) exposed on MonteBoo (0.6m refl.) by Janapka two months ago. It is composition of 3x11 exposures (3x440 sec) in R,V,B filters by our enhanced ST-8 camera. The images has not flat-field corrected.

Dumbell nebula M27. Linear intensity profile.

Dumbell nebula M27. Asinh intensity profile.

So, I strongly recommends use of asinh intensity profiles.

Post scriptum. Scaling to preserve all colors

Dumbell nebula M27. Asinh intensity profile.
Scaled by intensity. Note better preserving of colors.

The paper Lupton et al.(2004) recommends as an optimal way to scale of output image by intensity rather than every single color. You can use the -f switch to invoke it. The key difference with respect to single color scaling is coloring of the saturated objects. The intensity scale algorithm preserves color ratio in (output) saturated regions. The saturated stars have approximate colors opposite with the white color of previous algorithm. Of course, really (on CCD chip) saturated stars are white again. Unfortunately, the saturated stars can create a strange color defect. To remove it, use another black magic.

Post scriptum. I forget attach a graph of all profiles. Please look on the linear (red) and the logarithmic (blue) and asinh (light green) profiles which ideally "interpolates" beween its.
SVG version.

Download of FITSPNG.

Improvements of RAWTRAN

2008-12-20T23:41:00.009+01:00

While work on processing of set of images of Venus setting (I will it show soon), I found important bugs and revealed some possible improvements in rawtran utility. Moreover, I also found that only the type zero (default) conversion has worked correctly for all versions up to today. The default choice have composed four RGGB pixels of the Bayer color mosaic to one big grayscale pixel by use of unique weights for separate colors.

The Bayer mosaic is defined as red, blue and two green pixels arranged to rectangular matrix. It means that the number of different colors is tree but we have four pixels on detector matrix. Two green pixels are reserved for single color. Now, we have two choices for output intensities: sum of the pixels or their arithmetical mean. The sum gives precise value in integer numbers but one is two times greater than value of other colors. Opposite with this, the mean gives values of the same order as the red and blue pixels unfortunately with a rounding error as result of conversion between real and integer numbers. I think, the use of the mean and real numbers in FITS should be considered as a smooth alternative when a lot of disk space is available. Also sum of two greens and double values of red and blue can be a nice alternative for 12bit and 14bit A/D converters while we are storing data in 16bit FITSes. The arithmetical mean is the most simple alternative with small lost of precision. Please leave a comment about a preferred way to solve the controversial point.

Color weights

As the first noticeable change, I mention about the color balance (weights) used for conversion of a color based to a greyscale image. Generally, the conversion is done by the formula

I = w_R*R + w_G*G + w_B*B

where I is grayscale intensity, R,G,B are proper intensities in appropriate filters and w_i are a suitable weights. The choice of w_i depends on problem to solve. The setup of w_i is supplied by your camera according to spectral profiles of color device elements and to light conditions of an acquired scene. The photographers perhaps uses the term "white color balance" for the procedure, because it can be easy established by balancing of the coefficients on a white. Now, the camera setup is default. The previous versions used w_i = 1 without possibility to specify by hand. Note that both setups are useful in different situations. The camera supplied setup is ideal for images represents intensities close to reality. The 1's weighting can be useful for detailed spectral examination of images.

The color weights are derived from camera supplied data in field "Camera multipliers". The four numbers B1 B2 R1 R2 are used to estimate of color balance as:

w_R = R1/R2,
w_G = 1,
w_B = B1/B2.

The green band is supposed as basic unit and both remain are relatively scaled. The numerical values agrees with ufraw data. I don't know why also provided "Daylight multipliers" are not used for the reason.

For type zero the image is grayscale and the value is indicated by keyword FILTER which is set to GRAY. Weight factors are not directly included in keywords.

Multi-color fits

The most important change in the code is connected to multi-color (band) fits images. Previous versions has been badly decoding of Bayer's mask (the colors has been swapped). I corrected the bug and changed structure of resultant FITS files.

The effect of correct separation of colors can be easy showed on the image of the spectrum of a white source (data projector) observed through a rainbow glasses (famous paper - diffraction foil glasses). Look on included image for details. I'd correctly decoded the structure of image color mask on the image.

Color image and separated color bands.

Since recent issue, the multi-color FITS has following structure: the dummy primary image array (the header without any data) and tree color (band) extended images. Every header of the extended data contains a new keywords FILTER indicating one from set RED, GREEN, BLUE and appropriate color weight factor included as CBALANCE. Other new keyword EXTNAME is the same as FILTER and can be directly used to select the filter. For example, with ds9 you can directly select blue band by the command:

bash$ ds9 x.fits[BLUE]

The same selection can be done also as x.fits[3]. The file names uses the extended file name syntax introduced by cfitsio library.

Note, about multi-color (band) FITSes. The packaging of more images to one file is frequently used in space astronomy, where an experiment on a spacecraft records a radiation on many different wavelengths. The color mode is particular case of the gadget. The idea can be also extended for including of correction or calibration images or data.

Grid mode

The grid mode (type 1) simply arrange of pixels without collecting or space separating of pixels. I have no idea about any usefulness of the mode. Also I don't fully understand why noise (dark) level and white (saturated) regions are correctly displayed but the mid-level intensities produces grid structure.

8,16,32,-32 bits per pixel images

The output FITSes can have specified bitpix parameter (see man page). It can be very useful when you wanna save fine precision of intensities. The non-integer values are common product of white balancing when type zero conversion is selected. Also, the problem extensive discussed above is suppressed.

I suppose that the mode 16-bit is perfect for storing of raw data, the mode -32-bit for further processing and modes 8 and 32 are unusable. Images with 8-bit depth will usually white due to overflow of image's values over 255. The 32-bit mode only grows range of integer numbers and practically only occupied twice more disk space without any growing of stored information.

Examples of conversion

Basic run (equivalent commands):

bash$ rawtran IMG_666.CR2 > IMG_666.fits
bash$ rawtran -o IMG_666.fits IMG_666.CR2

The produced image IMG_666.fits contains grayscale image with half image dimensions of the original. Please, respect rule: first options than an image to convert.

Process all images in directory:

bash$ for A in *.CR2; do rawtran ${A} > ${A%CR2}fits; done

Process all images listed in a file l.lst:

bash$ for A in $(cat l.lst); do rawtran ${A} > ${A%CR2}fits; done

The file l.lst is usually created by command: bash$ ls > l.lst

Produce of multi-color image and show its green channel (band) in ds9:

bash$ rawtran -t 2 IMG_666.CR2 > IMG_666.fits
bash$ ds9 IMG_666.fits[GREEN]

Produce user's white-balanced multi-color image:

bash$ rawtran -t 2 -w 2.0,1.0,1.5 IMG_666.CR2 > IMG_666.fits

Separate blue color (band) from an image:

bash$ rawtran -t 3 -c B IMG_666.CR2 > IMG_666.fits

The output file roughly corresponds to a filtered CCD image with blue band.

Notes

Please, read source code of rawtran.c to get more detailed understanding of my ideas. I know that code is wrongly structured, it uses of poor data structures etc. but it isn't important for me. Valgrind shows defect free code.

I'm little bit confused about handling with output file. The default setup writes data on standard output which can be strangle for unexperinced users. The suffix swaping is not too elegant for C coding (shell replaces strings more effectively) and unique output filename like rawtran.png is confusing too.

All developing is proceed on images produced by Canon 30D. Be careful when your are working with another digital camera.

Download of RAWTRAN.
An older post about RAWTRAN.

Mandriva's repository of Munipack

2008-12-08T20:38:00.003+01:00

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.

Hády

2008-11-15T00:02:00.003+01:00

Hády is a lime-pit on Brno's border. The view to the town center show many millions of lights.

(Canon EOS 30D, 10sec, fish-eye)

These lights strongly illuminates the lime-pit itself. The illumination can be nicely observed on the tree.

(Canon EOS 30D, 16 sec, fish-eye)

The Hády transmitter looks likewise a rocket. Inspect the picture for faintest stars. Our naked eyes revealed only stars up to magnitude two.

(Canon EOS 30D, 32 sec, fish-eye)

Thx for nice accompany to Maceška.

Strange ls & fork

2008-07-15T20:48:00.004+02:00

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.

On principal pitfall of a star's magnitude calibration

2008-07-08T22:08:00.003+02:00

A calibration of magnitudes of an instrumental system to a standard system by an aperture photometry method should be revealing of some unexpected behaviour. Very bright stars are calibrated successfully (also the widely-known method of measuring of an extinction – Bouguer line – gives good results), but fainter (and faintest) stars are exhibiting of some horrible scattering, eg. they're not usable for the calibration. I think, it's result of any inaccurate determination of a sky background. Although our methods for the sky determination are more advanced. The inaccuracy comes from an unstable character of the problem of the aperture photometry.

To show, how some tiny inaccuracy in the background determination fluences to a resultant flux, we will suppose that stars are represented by Gaussian profile

G = G0*exp(-r**2).

An integration in polar coordinates (Jacobian!) of the profile gives us a total flux

F = F0*[1 - exp(-r**2)]

The flux F is equivalent to quantity coming from the aperture photometry, eg. the method which we're uses to estimate of the instrumental magnitude. The real situation is different. We need to subtract the background before summing (integration) of the detected signal on our CCD matrix. The model of detected signal may easy described by

I = G0*exp(-r**2) + B

where B is a constant added to every pixel. It's due to an illumination of the chip by a night sky or any another source. To get aperture photometry, we need subtract of B. That means, that we need to estimate of B by a statistical method with some uncertainty b (b << B).

Let's look to details of determination of total flux with a small error of B estimation. We have a function

I = G0*exp(-r**2) + (B + b)

and subtraction of B leads to

I' = G0*exp(-r**2) + b

so the total measurable flux F' (directly measurable by the aperture photometry) will be

F' = F0*[1 - exp(-r**2)] + π*b*r**2.

This is key moment. Our pitfall is presence of a second term. The first term is total flux of the source and its value is finite and physically limited at any radii. Note that choice of the analytic description of the term is not important. We only requires of integrable function, eg. its integral isn't infinite. Integrable functions has also an appropriate physical meaning. The size of second term depends on uncertainty of estimate of B and on its aperture's area. Because first term is limited, there is a radius where second term dominates over first. The radius depends on the inaccuracy of estimation of B and on object's brightness.

The important characteristics of the measured total flux is its instability. An instability in usual sense means strong dependence of results on input parameters. That is our case. Any tiny (small) perturbation of B lead to strong deviation of output from profile. And, what is more worse, any non-zero value of b (eg. all possible measurable cases) has no limit and the results diverge in in any possible cases (limit of F' is the infinity for the b non-zero)! We won't win!

The findings may interpret results of real measurements. Fluxes of bright stars are (in small apertures) not affected by second term. Faint stars may be too faint and the second term may by more important than the first one at small radii.

Theoretical disturbed profiles

To test the hypothesis, I prepared some graphs. The first one shows of the flux F' of an artificial Gaussian profile disturbed by values of background in range -0.1 to 0.1 (±10%). Both axes takes relative units. The graph is a nice demonstration of drastic fluency of any background estimation error on its resultant profile. Two most important characteristics of error of background estimation are:

any non-zero value induce significant change of shape of profile
profile has no limit in infinity

Leo I annotated

Leo I with removed stars

My second graph represents more real situation. There are disturbed fitted profiles of stars on the image of Leo I. The most important change to previous one are:

magnitude scale
the profile is non-Gaussian

Set of disturbed profiles of stars on Leo I

The vertical scale shows differences in magnitudes with respect to first aperture. The profile is modelled by a complex function as composition of wighted sum of Gaussian, Moffat and exponential function (see Stetson (1990)). The reliability of the fit can be demonstrated by another image on which the stars has been removed on base of the profile.

Profile of a bright star #1

Final pair of images shows an application of the disturbed mean profiles for two stars. The bright star has no warped profile. Any uncertainty in the sky estimation is insignificant to the total measurable flux of the star. The star is designed by #1 in the above image. The profile shows systematic differences in small radii. It is perhaps due to saturation of the star (the maximum of peak is greater than photon capacity of our CCD detector).

Profile of a faint star #2

The graph for faint star #2 clearly exhibits the effect of the error in estimation of the sky. The profile can be satisfactory modeled if we subtract 0.05 ADU (b = -0.05) from the sky background (determined by Munipack's). We can see, that the precision of the determination of the sky is really important for relative faint stars with its peak only about six thousands and the sky value about six hundredth (ten percent only!). A last point at radius 28 is affected by a hot pixel. The really interesting effects is the deviation of measured values and the modeled profile. The deviation shows some scattering in order of hundredth of magnitude (which corresponds to the precision given by photon statistics). But more important is relative difference between bright and faint star. We can see that the difference depends on aperture which has been used for estimation of magnitude of stars. That means that any magnitude calibration to standard system will depend on magnitude of the star. That is really poor property of the aperture photometry.

Note, that I selected the stars very carefully, because profiles of faint stars are strongly affected by various kinds of defects.

Another point of view offers photon statistics. The middle bright star on the CCD chip gives typically 10^5 photons, so the statistical uncertainty due to only Poisson noise gives about 0.003 magnitude which is about ten factor better than is usually measured.

The key thing of the post (strong fluency of background on aperture magnitudes) is included in paper of Howell (1989). There is only extension some theoretical ideas and another practical test.

Munipack stable release

2008-06-20T15:07:00.003+02:00

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).

Astronomical image processing guide (How to list of info keywords?)

2008-06-19T22:57:00.002+02:00

A great advantage of the FITS format is support of any arbitrary information included into an image file. A place for the info is reserved in header of the FITS file. Every FITS header must contain a set of records (lines) containing certain mandatory keywords. The set may be followed by records with any other keywords.

The mandatory keywords are: SIMPLE, EXTEND and END. All others are optional. The records of header has the fixed structure:

1-8 - keyword
9 - = equal's sign
10-x - value (various lengths)
x -80 - comment (every text following slash '/')

All records are 80-bytes long and there is no separator between ones. The special keywords COMMENT and HISTORY has no defined a structure and introduce any text string (continuation lines are not allowed). Recent recommendations to contents of the records adds physical units to numerical values as a part of comment. Any set of keywords is not widely used. It means that various utilities may used different keyword for the same entity.

The most common keywords are included in following (artificial) example:

SIMPLE = T / file does conform to FITS standard
BITPIX = 16 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 382 / length of data axis 1
NAXIS2 = 255 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
EXPTIME = 60.000 / [s] Exposure time
DATE-OBS= '2008-06-06T01:02:41.390' / UTC of exposure start
FILTER = 'R ' / filter
OBJECT = 'Star' / Object name
COMMENT This file was written by XXX.
END

We have more ways to handle with FITS header keywords. Practically, we will need to list of all keywords (as a variant of more or less command on unix's shell) or list of value of some specified record. Both situations can be easy coded. We introduce of utility FITSless which will print all keywords (full header) without any switches and a specified value when any keyword will presented, its value will be printed.

The values are usually different kinds (from computer point of view). For example, the observer's name will coded as a string, an exposure time will a real number, the date of start will a specially formatted string. To print the information, we will use only string representation, but in real code it will be better use of appropriate data type. Unfortunately, there is no simple way how to do it in Fortran, C and cFITSIO under recent versions of ones.

program FITSless

implicit none

integer :: status
! status ... FITS status (0=no error)

integer :: j,blocksize

character(len=666) :: name = 'image.fits'
! name .. fill with name of the image to open

character(len=666) :: keyword
! keyword to print the record

character(len=666) :: record
! header's record

character(len=666) :: value, comment
! record's value & comment

integer :: nhead, hpos
! number of records in header and current position

! get first command line parameter
call get_command_argument(1, keyword)

status = 0
call ftopen(25,name,0,blocksize,status)
if( status /= 0 ) stop 'File not found.'

! list specified keyword or full header
if( keyword /= ' ' ) then

write(*,*) 'List of a record specified by your keyword:'
write(*,*) '-------------------------------------------'

call ftgkys(25,keyword,value, comment, status)
! checking status of the operation
if( status == 0 ) then
write(*,*) trim(keyword),' = ',trim(value),' /',trim(comment)
else
write(*,*) 'Keyword "',trim(keyword),'" not found.'
end if

else

write(*,*) 'Full header list:'
write(*,*) '-----------------'

call ftghps(25,nhead,hpos,status)
do j = 1, nhead
call ftgrec(25,j,record,status)
write(*,*) trim(record)
enddo

end if

call ftclos(25,status)

end program FITSless

The code is self-explanatory, I recommend try this following experiments:

try give as parameter an arbitrary text string or upper/lower case keywords
process any printed information by some another text tool (sed, grep,..)
play with listing of a record on given position in the header
modify code to read an input file name by command-line parameters

A ridge of algorithms

2008-06-15T23:45:00.005+02:00

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.

Astronomical image processing guide (How to save of an image to a FITS file?)

2008-06-12T00:09:00.011+02:00

One of most common operation done on FITS files is creation of a new image. The creation process is straightforward. One is required to have an image (result of a mathematical algorithm) with known dimensions and that's all.

The FITS format supports up to seven-dimensional images without any strict limitation of its axis ranges. Practically, we've some limits due to physical properties of present computers. The most important is a size of the output image. The size is determined (approximately) as a product of image dimensions multiplied by number of bytes occupied by one pixel. For two-dimensional image of 100x100 pixels in both axis, represented by real numbers (4-byte, BITPIX=-32), we got size about 40 kilo-bytes. As we know from previous lecture, the images produced by an algorithm are usually saved as real data to preserve its numerical precision.

As example of a test image, I choose Bessel's function of zero kind J₀ which represents light's diffraction on cylindrical aperture. We can observe of square of Bessel's function in an ideal telescope as the image of a star (of course, we use only J₀ for simplicity, a star will looks differently). J₀ is non-standard Fortran function and may be not supported by all compilers (gfortran does it) so one is optional only and you can play with cosine under a strict-standard compiler.

An algorithm to save an image to FITS file is straightforward:

create image as an array
fill the array by an image
initiate a FITS
setup image parameters
save the data

program FITSsave

implicit none

integer :: status, bitpix, naxis, naxes(2)
! status ... FITS status (0=no error)
! naxis .. number of axes in the image (we set =2)
! naxes .. dimensions of the image (2-element array)

real, dimension(:,:), allocatable :: d
! data matrix

character(len=666) :: name = 'image.fits'
! name .. fill with name of the image to create

! aux
real :: x,y,r
integer :: i,j

! set dimensions of the new image
naxis = 2
naxes = (/ 100,100 /)

! set bipix of the image (try: 8,16,32 and -32)
bitpix = -32

! create a data storage (allocate memory) for the image
allocate(d(naxes(1),naxes(2)))

! fill image with values
do i = 1, naxes(1)
do j = 1, naxes(2)

! rectangular coordinates
! the left bottom pixel has 1,1
x = i
y = j

! distance from origin
r = sqrt(x**2 + y**2)

! set value
d(i,j) = cos(r/5.0)
!d(i,j) = besj0(r/5.0)
! uncomment for J0 (Bessel function of zero kind)
! J0 represents diffraction on cylindrical aperture
end do
end do

! save the data
status = 0
call ftinit(26,name,1,status)
call ftphps(26,bitpix,naxis,naxes,status)
call ftp2de(26,1,naxes(1),naxes(1),naxes(2),d,status)
call ftclos(26,status)

! free allocated memory
deallocate(d)

end program FITSsave

The code can be compiled and run by

host$ gfortran -Wall -o FITSsave FITSsave.f90 -L/usr/local/lib -lcfitsio
host$ ./FITSsave

the output file is named as image.fits and can be viewed by any FITS viewer, for example by ds9:

host$ ds9 image.fits

Notes.

Any handle with numerical operations in many computer languages may be little bit confusing. Fortran strictly distinguish between integer and real numbers. The notation 3/4 (both integers) products result 0 (reminder is forget), but 4/3 gives 1. Opposite with this, the notation 3.0/4.0 gives 0.75 (two significant places).

The function ftinit (the initial function for FITS file) can create only a new file. There is no way how to replace any existing file. This is simply a feature of cfitsio, not a bug. It means that you must remove the older file image.fits before run FITSsave again.

Astronomical image processing guide (How to list of values of a FITS image?)

2008-06-02T22:21:00.003+02:00

Every FITS file is representation of an image usually created by an optical device. The image is quantized (sampled) to elementary cells called pixels. An information knows for any pixel are: a pixel coordinate (Cartesian x,y) and its captured optical flux (CCD's flux is a linear function of captured photons).

The pixels which represents an image, are rearranged and a captured flux is digitalised to a matrix. The matrix is saved to a FITS file by a defined algorithm. The pixels coordinates (integers) are arranged in that matrix by the way:

[M,1] [M,2] .. [M,N]
.. ..
[2,1] [2,2] .. [2,N]
[1,1] [1,2] .. [1,N]

The matrix represents an image of width of N pixels and M pixels of height. The origin and orientation is in usual mathematical fashion.

Every pixel is represented by a number. The kind of the number may be an integer and a real (real numbers are with fractional part). Raw images (pure product of a device) are usually represented by integer numbers in interval from 0 to 65535 (2^16) for CCD and from 0 to 4096 (2^12) for a digital camera. A processed images as result of mathematical operations are saved as a real numbers with floating point. (Arithmetical operations may reduce of its precision). The method (complicated on first sight) to store of data reflects many of astronomer's needs and save your disk space. The data representation is coded in parameter BITPIX in the fits header by the way (not all possibilities are included):

BITPIX bytes type range of values
8 1 integer 0 .. 255
16 2 integer 0 .. 65535
32 4 integer 0 .. 4294836225
-32 4 real -1e38 .. 1e38 (7 digits)

An operation on a image included in a FITS file is relative easy. Follow the instruction:

open of FITS
get of its size (width, height)
allocate memory for a matrix
read data
play with data

Fortran offers a very effective way for manipulation with matrixes. For a matrix D, we can select an i,j-element as D(i,j), a i-row D(i,:),i-column D(:,j) or submatrix D(1:10,50:60).

program FITSlist

implicit none

integer :: status, bitpix, naxis, naxes(2)
! status ... FITS status (0=no error)
! naxis .. number of axes in image (we require =2)
! naxes .. dimension of the image (2-element array)

integer :: i,j,blocksize,pcount,gcount,minvalue
logical :: extend, simple,anyf
! required by cFITSIO

real, dimension(:,:), allocatable :: d
! data matrix

character(len=666) :: name = 'image.fits'
! name .. fill with name of the image to open

status = 0
call ftopen(25,name,0,blocksize,status)
call ftghpr(25,2,simple,bitpix,naxis,naxes,pcount,gcount,extend,status)
allocate(d(naxes(1),naxes(2)))
call ftg2de(25,1,minvalue,naxes(1),naxes(1),naxes(2),d,anyf,status)
call ftclos(25,status)

! print value of a random pixel
write(*,*) '# d(1,1)=',d(1,1)

! print last tree values of first row
write(*,*) '# d(1,-10:)=',d(1,size(d,2)-3:)

! print of a submatrix with indexes
do i = 1,10
do j = 50,60
write(*,*) i,j,d(i,j)
end do
end do

end program FITSlist

The output of the code can be saved to a file by sequence of commands:

host$ gfortran -Wall -o FITSlist FITSlist.f90 -L/usr/local/lib -lcfitsio
host$ ./FITSlist > pixels

and easy plotted in a gnuplot with the command:

gnuplot> splot 'pixels'

How aureole shades stars

2008-06-02T01:22:00.004+02:00

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.

Astronomical image processing guide (How to open a FITS image?)

2008-05-26T22:49:00.004+02:00

A structure of a FITS file is a little bit complicated, but not too much. The FITS itself includes a header and a data part. The header of an image consists from meta-information about the image. The most important are the size (width and height) and data representation of the image.

The header is set of 80-byte (character) length records. Every record is represented by text line with structure:
KEYWORD = VALUE
The KEYWORD must be no longer than 8 characters. The '=' must be in 9 column. The width and height of an image is coded by the way:
NAXIS1 = 1628
NAXIS2 = 1236

How to get an image size?

To get this basic information by use of the cfitsio library, we can use of the piece of the code (source code):

! to compile: gfortran -Wall -o FITSsize o.f90 -L/usr/local/lib -lcfitsio

program FITSsize

implicit none

integer :: status, bitpix, naxis, naxes(2)
! status ... FITS status (0=no error)
! naxis .. number of axes in image (we require =2)
! naxes .. dimension of the image (2-element array)

integer :: blocksize,pcount,gcount
logical :: extend, simple
! required by cFITSIO

character(len=666) :: name = 'image.fits'
! name .. fill with name of the image to open
status = 0
call ftopen(25,name,0,blocksize,status)
call ftghpr(25,2,simple,bitpix,naxis,naxes,pcount,gcount,extend,status)
call ftclos(25,status)

if( status == 0 ) then
write(*,*) 'The image ',trim(name),' has the size:',naxes
else
write(*,*) 'The image "',trim(name),'" not found or not accessible.'
end if

end program FITSsize

The code may by compiled by command:

host$ gfortran -Wall -o FITSsize FITSsize.f90 -L/usr/local/lib -lcfitsio

where switch -Wall prints some warnings, -o specify name of the generated binary file (name of the routine), -L points path to cfitsio library (may be omitted, usually any system directory) and -lcfitsio links cFITSIO library (libcfitsio.a).

Type:

host$ ./FITSsize

to run. The utility will try to open file named as 'image.fits' (can be changed in declaration name = 'image.fits'). If this file is accessible it will print the size of the image. If the name can't be open, an error will appeared.

This code demonstrates basic idioms of FITS-specific ones:

its look horribly
there is a lot of declarations which meaning is too hard to remember
the variable status must be set to zero before calling of any of cFITSIO routines
the name of the image to open is a second argument to ftopen
the routine ftghpr reads important parameters (coded by KEYWORDS as above) of the image

Astronomical image processing guide (Intro)

2008-05-21T22:51:00.002+02:00

From time to time, I'm thinking about the most useful way to process of an astronomical image data. An use of wide-known software package utilities like Gaia, ds9, IRAF may be better or worse in comparison of a direct coding of a self-made routine? Both approaches has its own advantages and disadvantages so, I think, there is no an universal way to process its. For example, a lot of work can be done inside IRAF's (http://iraf.noao.edu/) environment, but sometimes may be faster and more suitable of coding of an own utility. Both approaches may be possible useful and important especially for a particular processing. Also, I thinks the develop of any own routine may be much, much better and simpler then use of prepared ones. While there is a lot of documents describing of various software packages, the processing in a computer language is described poorly. That's why I'm starting write this guide.

The basic operation to work with data is data file handling. A FITS format (http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html) is a wide-used format to storing of an astronomical data including both an images and a data tables. A general structure of FITS files may be really very complicated. Fortunately, W. Pence and etc. made the cFITSIO library to provide of a standard way to create, open and modify of any FITS files. The library offers interfaces for C and Fortran languages. There is also a lot of wrappers to others (Perl, Python, C++, ..). I'll use of Fortran (fortran 90/95/2003 dialect) in this guide to create a simple code but the change to C (for example) is straightforward.

A computer library (like cfitsio) is a file with a special structure which includes a set of (useful) functions. The file is usually created by compiling of a computer language (cfitsio is in C) to a machine-specific code.

How to install an environment to open FITS files?

1. Use of your package system and install gfortran (Fortran compiler).
2. Use of your package system and install cfitsio.

ad 1). The gfortran is included in most modern Linuxes. Its is possible to use also Intel's ifort (apparently faster). Solaris offers f90/f95. The GNU g95 provides binaries for other systems (BSD's, Mac OSX, ..).

ad 2) Many modern distributions (Debian, Ubuntu, Fedora..) offers cfitsio as a package. If your doesn't, download directly tarball. Move it to /tmp and execute:
host:/tmp$ tar zxf cfitsio-x.y.z.tar.gz
host:/tmp$ cd cfistio-x.y.z
host:/tmp$ ./configure # check output
host:/tmp$ make # compile
host:/tmp$ su # switch to root account
host:/tmp$ make install # install to /usr/local

To install it in an another place use --prefix parameter for configure (./configure --help). To uninstall it, type (as root) make uninstall. A successful installation is indicated by presence of drvrsmem.h,fitsio.h, fitsio2.h and longnam.h in /usr/local/include and libcfitsio.a in /usr/local/lib.

The Fan on Leo I Revealed

2008-04-10T22:11:00.002+02:00

The unidentified fan on bottom edge of the image of Leo I has really simple explanation! Rays are diffraction patterns of Regulus lying twenty arc minutes bellow Leo I. The connection has been revealed by readers of IAN.cz. Thank you very much! It is a very good example how Internet can help expand of a knowledge. I have no explanation how I had ignored this fact. I inspected the position of Leo I with Xephem and I miss the critical proximity and I had in mind that the Leo I falls to the head of Leo. So don't forget look under legs when you are watching of the sky...

When I play with raw images, I inspect ones by an animation. The animation (warning 36M!) shows "a shut of the fan" near of its end so I gather from the investigation that the light pollution is due of a Earth's source. The animation shows a relative motion of the telescope (corrected by pointing), an airplane, cosmic-ray event and inner lights of our dome.

A last step to full explanation of the secret has been done by exebece. It take note that all stars are fainter at the end of the observation run. The instrumental magnitudes of the star UCAC2 36118678 shows rapid fall of its light fluxes. An explanation of the fainting is direct. The aperture of the telescope, controlled by the siderical motion, has been occult by our dome. A creativity of all possible mistakes by me is unbelievable...;)

The Zodiacal Light

2008-04-06T23:30:00.007+02:00

A mysterious zodiacal light can be sight at the season of the spring equinox. The weather and the sky prepared for us an absolutely excellent spectacle during last weekend and we was able to view the zodiacal light for the first time!

We made three journeys to Rojetin's airport. At first evening, we did sight some lights above west's horizont, but we did understand that we did sight the zodiacal light after that it disappeared. Also, we made some photos but with ISO 600 only so all images are underexposed and noisily. Our second journey was the most successful. Horrible clouds has dissolved and we sight clearly the zodiacal light with help of our fresh experience. Our last journey started really optimistically because the sky has no clouds for whole day. Unfortunately, an atmospheric front moved to west's horizont and it did scatter a light over the zodiacal light. We did not sight anything.

The first image shows the zodiacal light during our second journey. The zodiacal light is a white difuse part of sky below Pleyades (rightly). A head of Taurus is at center of the image, Orion is on the left. Do you know where a white dwarf can be found? The image was acquired at 2008-03-30, 18:05 UT, EOS 30D, f/2.8 fish-eye, ISO 1600, 32 sec and processed by Ufraw+dcraw (histogram equalisation, wavelet denoising) and Gimp (unsharp, resize). The camera configuration and processing is common to all related images (larger).

Next two images recorded a passage of the ISS and Jules Verne spacecrafts during evening of 2008-03-31, 17:39 UT (the same camera configuration). I prepared two versions of the image in a large format (I believe) useful for wallpapers.

I dedicated, inspired by Paulie, the 31's evening to made a sequence of horizont-centered exposures. Unfortunately, clouds has been brighter than the zodiacal light.

Thx to all peoples of my team: Janis, Petoš, Barča, Ushas, Maceška, Jarda, Janapka, Kočka, Fantom, Ondratik and Paulie.

Color transformation

2008-04-04T00:11:00.006+02:00

This record is just for future references.

Some time ago, I got profiles of transmissivity of our new set of photometric UBRVI filters (thx to K.Navrátil). The filters are offered as a part of the official SBIG's accessories. Profiles of trasmissivity of the filter set and Landolt's (Astron. J. 104, 340 (1992)) filter set is displayed on the image:(in PDF). All filter profiles together with various useful files are included in archive newfilters.tar.gz.

A knowledge of the profiles enable us to create a transformation between our and Landolt's filters set. The transformation is constructed only on base of the filter's transmissivity. That means that another one made as a product of a real measurement will perhaps different due to any different spectral sensitivities of others parts of our optical equipment (mainly telescope, detector and atmosphere). We are use the transformation between our set {|u>,|b>,|v>,|r>,|i>} and Landolt's {|U>,|B>,|V>,|R>,|I>} as the matrix equation

|u> = U><U|u> + |B><B|u> + |V> <V|u> + |R><R|u> + |I><I|u>
|b> = U><U|b> + |B><B|b> + |V> <V|b> + |R><R|b> + |I><I|b>
|v> = U><U|v> + |B><B|v> + |V> <V|v> + |R><R|v> + |I><I|v>
|r> = U><U|r> + |B><B|r> + |V> <V|r> + |R><R|r> + |I><I|r>
|i> = U><U|i> + |B><B|i> + |V> <V|i> + |R><R|i> + |I><I|i>

where the matrix elements are defined as area determined by the product of the transmissivity of the filters. For example

<U|u> = ʃ U(λ)u(λ) dλ
<B|u> = ʃ B(λ)u(λ) dλ

...

for all wavelengths λ = 0 to ∞. The results of the integration and solution of the matrix equation are in the table:

0.5051 -0.0131 -0.0008 -0.0001 -0.0000
0.1680 2.5373 0.0233 0.0028 0.0008
-0.0010 0.0587 1.4170 -0.1299 -0.0381
0.0003 -0.0104 -0.0828 0.9252 0.0747
-0.0000 0.0009 0.0073 -0.0460 1.0063

The filter based transformation between our instrumental magnitudes m_i for i = U,B,V,R,I and Landolt's M_i is described by the term

m_u - M_U =
-2.5( log10 <U|u> + log e (<B|u> + <V|u>+<R|u>+<I|u>)/<U|u>)
+ <B|u>/<B|b> (M_B - M_U)
+ <V|u>/<B|b> (M_V - M_U)
+ <R|u>/<B|b> (M_R - M_U)
+ <I|u>/<B|b> (M_I - M_U)
...

(analogically for other filters). The numerical results are:

m_u - m_U = 0.8110 - 0.0260 (m_B - m_U) - 0.0016 (m_V - m_U) - 0.0002 (m_R - m_U)

m_b - m_B = -1.203 + 0.0662 (m_U - m_B) + 0.0092 (m_V - m_B) + 0.0011 (m_R - m_B) + 0.0003 (m_I - m_B)

m_v - m_V = -0.1838 - 0.0007 (m_U - m_V) + 0.0415 (m_B - m_V) - 0.0917 (m_R - m_V) - 0.0269 (m_I - m_V)

m_r - m_R = 0.1338 + 0.0003 (m_U - m_R) -0.0113 (m_B - m_R) - 0.0895 (m_V - m_R) + 0.0807 (m_I - m_R)

m_i - m_I = 0.0870 + 0.0009 (m_B - m_I) + 0.0073 (m_V - m_I) - 0.0457 (m_R - m_I)

Detailed description of the used method and an application to our old
filters can be found in Janis's bachelor work (in Czech).

(The old school typhographics rules! A "modern" graphics technologies doesn't supports a little bit complicated typesetting as (La)TeX did twenty years ago.)

Spectrum from Heavens

2008-03-17T01:20:00.003+01:00

Hrošátka (group of my students) experimented with our new SGS spectrograph on last Thursday. It was of our first real contact with the device so any basic operation was hardly for us (arranging, focusing, pointing, exposing). We acquired a few spectra of some bright objects to test of our equipment. I see, we will need a lot of fine tuning and a lot of experiences in observation and data processing to get a day-to-day usable spectral apparatus. Also, I meet again with CCDops utility. It works nicely under Mac OS X, but it is still hardly to use.

All the spectra has been acquired on evening 2008-03-13 by SGS spectrograph in a low-dispersion configuration and mounted on Celestron 14" with ST-8 XME camera as a detector. All images has been processed by the same way as previous ones. The wavelength calibration is only preliminary.

A first object to acquire was the Moon. It is bright and easy to point. Moreover, the spectrum of the Moon is practically identical to the Sun's spectrum. The resultant spectrum shows a great peak of a continuum radiation modulated by some absorptions lines. The great peak practically visualise the spectral sensitivity of our CCD camera. There are only strong lines due to a non-perfect focusing.

As second object, we acquired Sirius. Sirius is a hot star with spectral classification A0. The spectrum shows practically only strong hydrogen lines of the Balmer's series.

A little bit fainter star was Procyon of a spectral class F5. The hydrogen lines are suppressed and only marginal features are visible. I selected this spectrum as an illustration of an image of a spectrum on the CCD chip.

A high pressure sodium streetlamp has been tried as a possible calibration source. The spectrum is quite different due to a non-thermal mechanism of lighting. Unfortunately, the spectrum is included in all other specters as emission lines. The sky's spectrum is also practically identical. Note, that spectra by a Ch. Buil shows some differences.
Thx to my students Maceška, Kočka and Peťoš for a great help. Especially, Maceška bravery controlled of our notebook when she had a broken leg.

Update: Raw images of spectra are available on Petoš's blog.

Leo I

2008-03-16T12:26:00.003+01:00

One of twelve known companions of our Galaxy (Milky way) is a dwarf galaxy Leo I. The object is projected to a head of Leo constellation with look like a faint star cluster of an approximately dimension of five arcmins and with its total visual magnitude about ten. Leo I is 250 kpc far from us (Milky way has 30-40 kpc in diameter) so its linear dimension is quarter or half of kiloparsec(!). The estimated number of stars (with sun's mass) is 10⁹ (Milky way contains about 10¹¹ of stars). The galaxies like Leo I appertains to a class of dwarf spheroidal galaxies (dSph).

A relative proximity of this kind of galaxies enables us to study of various details not accessible for remote ones. Especially, it is possible to resolve of individual stars and to measure of its magnitudes and spectra. The measurements gives direct values of a dispersion velocity (The dispersion velocity can be determined by estimation of a width of a spectral line raised as a mean of velocity differences of individual stars. The value is greater for faster stars and doesn't depends on a relative velocity of a galaxy's center of gravity.). Velocity measurements are a tool to mapping of the gravitational potential. If any outer fields are negligible, the potential is formed by a distribution of stars. It is worse that the distribution of stars is formed by potential. Fortunately, the simultaneous fitting of both quantities gives right results. But there is problem with observed discrepancy between number of stars (the projected surface luminosity) at a some radius from a core and the dispersion velocity at the same place. That is widely known problem of "dark matter" because the velocity is greater than we are expecting from observations of number of stars with an usual luminosity.

Only for my interest, I made an observation of Leo I on MonteBoo Observatory. A resultant image has been acquired by composition of a series of images at 2008-03-06 between 19:51 and 22:15 UT (totally 5160 sec) by our 0.6m telescope at R band. The Leo I itself is situated to the center of the image as a faint stellar cluster (compare with image of D. Malin on APOD). A graph by a paper Walker et al.(2007) (it contains recent measurements of the dispersion velocities for seven dSphs) is placed to the image. The original graph is scaled to match of the position and the angular scale of Leo I. The solid line fits the measured velocity dispersions in km/s. The horizontal axis represents a distance from its center in parsec (the range is: 0 to 2kpc). The hashed line is a King's model for the luminosity which roughly corresponds to density of stars in the image. For better description, read the original paper. The discrepancy between the luminosity and the velocity is clearly visible. The velocity is a constant at radius where the density of stars is relative low. Note, that potential (velocity) falls rapidly when no matter is presented.

Moreover, the image exhibits a lot of defects over Leo I itself. "Stairs" at edge of the image together with white corners demonstrates a pointing mode of the telescope during a long time series. The effect is intensified by correcting of the image for its median. The median also suppresses a light pollution due to an unidentified near light source. The pollution creates a fan of rays at bottom of image.

Kotvrdovice's airport

2008-03-13T01:07:00.004+01:00

My Sunday's afternoon trip to Moravian Karst finished on Kotvrdovice's airport. The airport is covered by grass plot except a small part of concrete and perhaps it's an airport for sports planes. A horizon is near of ideal but the concrete surface is in proximity of Kotvrdovice (and public lighting) itself. The airport is about two kilometers from Kojál transmiter.

Kotvrdovice's airport facility and runway.

View to Kojál.

Archive of our observations

2008-03-09T23:39:00.004+01:00

Four years ago, I wrote a really simple database engine for our observations. The data are indexed one per day and stored in a database (sqlite, more sophisticated engines need a server) and the served via at the most simple web interface. This philosophy satisfy all our needs so there is no reason for a change.

Now, I'm moving our old software to a new computer so I made a small improvement to database by adding of a new Reference column to front (year) page. It provide a possibility to back-linking of some results to the original data.

The data archive has a link in my links.

Eclipse of the Moon

2008-02-25T00:09:00.004+01:00

Last week has been dominated by eclipse of the Moon. We had a trip for possible locations (with a romantic ruins on the horizont) week ago. Our weather condition was really poor during eclipse time so the phase of totality has been obscured by cloud completely. There are a few pictures and one animation to illustrate the times.

The trip is also documented on pages of Janapka and on Galaxy tea.

A lake under Apollon's temple at winter. Apollon's temple is a part of Lednicko-Valtický areál.

A detail.

A lake below Apollon's temple. Pálava on horizont.

15cm telescope of HaP MK Brno during eclipse. Thx Peťoš.

A link to animation of clouds and halo before eclipse.

First spectra by SGS

2008-02-22T22:59:00.004+01:00

Last year, we purchased the SGS spectrograph. I spend today's afternoon by acquainting myself with the device. First images looks really amazing. All ones has been acquired in my office with a scattered radiation of a fluorescent lamp as a light source with our new ST-8 XME camera as a detector. Compare my findings with its spectrum.

An image of a spectrum of fluorescent lamp in low-resolution mode of SGS. The wavelength interval is about 300 - 900 nm. Ultraviolet is on the left, red is on the right.

An image acquired in high-resolution mode. Wavelengths in interval 490 - 650 nm. The orientation is the same as in previous case. The image covers approximatelly central quarter of the low-resolution spectra (try find of Tb - Eu series between two strong lines).

The image of the same lamp acquired by a digital camera (Canon EOS 30D) and a simple CD spectrograph for comparison. You can simply identify global spectral features. The strong red line corresponds to the strong line on the right on high-res image of spectra. The green line is the strong line on the left of the same image. The lighter horiznotal line has been used for construction of a first graph on image below.

A calibrated graphs of spectra of the images above (click for original size). Top to bottom: spectrum by CD's "grating", low-resolution of SGS, high-resolution of SGS. The graphs exhibits different spectral resolution of all "instruments" (look on series of Tb and Eu at 570-600 nm) and different spectral sensitivity (color graphs, line at 550nm).

Once, the spectra looks really fine, I'v worries about simple use of our equipment. The CCD can be connected to spectrograph only without filter wheel (due to focusing range) but the removing of the wheel is really complicated and delicate operation.

Rojetín - preliminary 21 mag/"

2008-02-14T19:32:00.005+01:00

Today, I processed zenith's images of night sky taken during Saturday's trip to Rojetín. Original RAWs has been converted to FITSes by rawtran.

Dark frames has been processed by mdark utility from Munipack. My fast statistical analysis of a noise of the dark images shows pretty Gaussian histogram with center on level 380 and thickness about 7-8. The noise looks little bit greater then noise of our CCD camera at the same temperature (approx. 0°C). The dark frame reveals a smooth electro-luminescence at a corner probably due to a fast transfer of electrons to an A/D converter.

The converted light images has been corrected by the darks. The application claimed a small modification of rawtran because our camera detects a gravity direction and it automatically rotates images to a portrait orientation and rawtran needs rotate it back (if not, the size of lights and darks are different).

A combination of our Canon 30D camera and our 17mm Canon's fish-eye gives us a scale about 21 pix/°, eg. 2.9' per pixel near center of projection. I determined the value by use of two stars (therefore it is preliminary only!). A precise analysis will need construction of a model of the projection.

All light images has been processed by muniphot by a standard way (determination of a mean background, finding of stars and an aperture photometry). To my surprise, it works without any troubles. The number of found stars for 3-σ is almost 13 000 and for 1-σ over 50 thousands (!). The limiting magnitude of stars (1-σ) has been determined approximately on 10 magnitudes for 30sec in wide-band of sensitivity of our camera. The photometrical calibration (determination of a zero level for instrumental magnitudes by using of known stars) shows a relative great scatter for stars in the interval 2-7 mag. The position on the chip (near center or border) along with position in Milky way doesn't matter. Opposite with this, the color of stars is important and red stars are unusable for it. It may be due to a mist (or another reason).

My determination of sky brightness on place non-confused by Milky way but near of zenith gives value of 21.0 magnitude per square arcsecond with uncertainlity not better than 0.5. So the place satisfy of hard requirements for our observations.

ISS+Atlantis

2008-02-13T16:14:00.005+01:00

Another shot of ISS and Atlantis taken 11. feb. 2008, Canon EOS 30D, 30sec., fish-eye at the observation roof of HaP MK Brno.

Rojetín's night sky

2008-02-12T01:09:00.001+01:00

I found the "airport" month ago. Yesterday, I did a first night's trip to the location. The drive troughout darkness and a relative sparse settled landscape is a amazing adventure. Any ambient scenery is pretty unrecognizable. The darkness on the airport is absolute. Only a few far lights is directly visible. The airport is completly abandoned so I didn't meet any car during my about hour stay on the place.

I had only our Canon 30D and our fish-eye (no a tripoid or no a mount). All images has been taken with a static 30sec exposure and with the camera positioned by anything possible (a hinking map, a car atlas). An objective clone has been 3.2 (full aperture), ISO 1600. An atmospheric condition was relative good with a light mist and a nice crescent moon.

I'm publishing a few preview images. All images are converted from RAW format as a color pictures to better illustrate a light pollution. No corection on dark frame has been done. The place is practically the same as it was at last visit.

A view to noth-east direction as a equivalent to day's view. There are lights from Rojetín and Ždárec. Bright stars are part of Big dippper (center), Ursa Minor (top left) and Leo (right).

A view to south-west direction as a equivalent to day's view. The airport facilty is at right, we can recognize connstelation Orion and Canes Major. Light domes near horizont comes from Březí and Borovník. You can identify an airplane at large resolution picture.

Crescent moon.

Light domes at direction to Brno. A head of Leo on the left, Sirius on the right. The large format of the image reveales Preasepe.

The west's view. Cassiopea on top, Deneb near horizont. M31, Lacerta.

Mars and "the gold gate of ecliptic".

Zenit. A lot of object is vissible. The comet Holmes is near Algol.

A church at Ždárec. One of main light polution sources on north direction.

Expedition Moldavite

2008-02-11T20:38:00.002+01:00

A moldavite (vltavín in Czech by river Vltava) is a stone which has been created during a meteorite impact. Main centers of deposits of moldavites in Bohemia are near České Budějovice (yes, Budweiser's origin) and in Moravia near Třebíč town. I (and a group of geologist) had a visit on Moravian's location on last Saturday. We has found nothing but the trip has been really nice... Stones are like a dark glass and they are usually found on ploughed fields.

Our first locality has been situated near border of Třebíč.

The second locality has been below Sádek castle near of Kojetice village. There is a vineyard around center of the picture.

The third and last stop has been at a small wood near Dolní Lažany willage.

I seeking for a deep darkness...

2008-01-19T19:38:00.000+01:00

I had a trip with aim to seek for an ideal place for our observations. The map of light pollution of Czech Republic is revealing a possible region near Tišnov town. A terrain is hilly around 500m above sea. Majority of roads is poor surfaced and a parking place (or any car's available place) is impossible to be found. Only one acceptable (and near of my ideal) is an "airport" (eg. a wider road) near small village Rojetín. It is probably an emergency or an agro airport without any facility. Rojetín is about 20km (twenty minutes) far from Tišnov. I taken shots of the "runway".

(to north-east)
(to south-west)

Both pictures has been taken at coordinates 49°21'25.638"N, 16°14'46.732"E. In my opinion, the place may satisfy of our requirements for a perfect horizont and ideal light conditions. A night's trip to the airport will be resolving....

Rawtran

2008-01-08T23:50:00.001+01:00

A digital photography is really amazing field of a new technology. I discovered another dimension of one during winter's holiday while I'm play with analyzing of pictures by a standard fotometrical way. I get view to a complicated world of a calibration of that devices. My first touch has been of a most lower level: a conversion of RAW images produced by a digital camera to my favorite FITS format.

A great part of known RAW formats should be recognized and decoded by famous utility dcraw. It satisfy most of my requirements but one creates no FITSes. Dave's recommended way how to transform dcraw's output PGM files to FITS is not ideal. The issue is a netpbm toolkit with a "non-astronomer's" conversion.

My response for the frustration is a small utility Rawran. It wraps of the dcraw, get a PGM data file via a pipe and rearrange the data in fashion:

a four RGGB pixels to intensity as a weighted sum
one to one data pixels
a three separate bands in one file

The utility is not too mature and it can be found in rawtran directory along my other projects.

Some examples of converted images by the first method can be found as FITS files (each about 6M): holmes.fits (zoomed parts of the images has been used in examples above), pleiades.fits, deeep_macocha.fits (a png version of the image has been published some time ago).

New SBIG drivers

2008-01-04T20:41:00.000+01:00

Thanks to J.Soldán, SBIG's new version of camera drivers has been updated month ago. An update of Nightview associated to the new drivers has been smooth. Today's tests of our (faculty's) ST-8 new camera (first light!) discovered a few unimportant bugs in a daemon's start by udev scripts (they would be corrected at now). The daemon (it directly talking to camera via updated drivers) seems to be a bugfix free. The drivers itself looks perfectly. All known bugfixes (a link to libusb and cwf typo in headers) has been corrected. It works on 64-bit systems!

I'd prepared an install_sbig_firmware.sh script to automatically install (fetch it, unpack, copy to appropriate place) of the drivers. To install Nightview on clear computer, download of latest nightview-????-??-??.tar.gz, unpack it, go to libsbig directory (if you can install camera driver) an run the script. Everything is prepared to run successfully a configure. There is a simplefirst-time installation way:

wget ftp://integral.physics.muni.cz/pub/nightview/nightview_2008-01-04.tar.gz
tar zxf nightview_2008-01-04.tar.gz
cd nightview/libsbig
./install_sbig_firmware.sh
cd ..
./configure
make
make install

The presented commands will install all needs. A switch-on of a power button will start firmware loading sequence and the camera daemon. Of course, the installation of drivers will necessary only for first time. The drivers can be smoothly uninstalled by a script uninstall_sbig_firmware.sh

Barnard in time

2007-12-12T22:21:00.002+01:00

All stars are supposed to be static in time. No change, no motion, no emotions. But, it is very surprising that a few stars has an abnormally high proper motion. Hipparcos's measurements has revealed of nine fast stars with proper motion over few arc-seconds per year. The fastest known star is Barnard's star. My students of Astronomical practicum has been observed of the field of Barnard's star for two years. Results are just amazing.

Our determination of the proper motion by precise astrometry of five to ten stars per exposure (total 15 - 20 exposures per observation run) gives values:

R.A.: -0.684 arcsec/year, Decl.: 11.660 arccsec/year.

They has been determined as difference of two robust arithmetical means of the star coordinates at Autumn of years 2006 and 2007. UCAC2 was used as an astrometrical catalogue. The values are in really good agreement with values acquired by Hipparcos: -0.79871, 10.33777. The determination of measure errors gives us uncertainty of order of tenths of arcsec. The differences both techniques are a little bit greater. Perhaps, the discrepancy comes due to apparent non-linear motion of Barnard's star and it is illustrated on Hipparcos pages. The periodic differences shows manifestation of Earth's revolutinons around Sun - parallax.

A better visual demonstration of Barnard's star motion exhibits a four-frame animation of observations acquired at MonteBoo observatory over the last years. A single images which has been arranged to film frames are displayed at header of this post. The linked full frame animation shows change of the position of Barnard's star and (of course) some changes in health of our CCD camera. The first image (2001) presents perfect image while the next images (2006) shows two bad-reductable hot columns. The camera has been aged ten or eleven at time of exposure. The last image taken on HaP MK shows absolutely different field orientation and size. All images has been recomputed with respect to first image by rotation, shift and scaling by bi-cubic interpolation (kombine routine from Munipack).

The side product of our astrometry is determination of the focal length of the 40cm telescope of HaP MK Brno to value: 1.7122 +- 0.0007 m.

An another way to illustrate of the Barnard's motion is composition of all images to single frame. In my opinion, this is the most nicer way to present of a proper motion. The original size version.

Visualisation of found stars

2007-12-09T00:46:00.000+01:00

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

2007-12-07T01:06:00.000+01:00

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!

Cfitsio & fortran wrap

2007-12-01T21:24:00.000+01:00

Some time ago, I reported problem with compilation of Munipack under Mandriva linux distribution. Today's work under Gentoo make my way where the trouble is occuring. Errors like these:

autoflat.f90:(.text+0x8ee): undefined reference to `ftopen_'
autoflat.f90:(.text+0x93f): undefined reference to `ftghpr_'
autoflat.f90:(.text+0x9da): undefined reference to `ftclos_'

says: You have the cfitsio library installed but the functions has not been found. The problem will appear in "modern" distributions without g77 binary (any f77 compiler), while cfitsio configure script is looking for f77 compiler. If the compiler is not found, the configure-machinery drop off support of f77. It is indicated by:

checking for f77... no
checking for xlf... no
checking for cf77... no
checking for gf77... no
checking for g77... no
checking for af77... no
checking for ncf... no
checking for f2c... no
configure: warning: cfitsio: == No acceptable f77 found in $PATH
configure: warning: cfitsio: == Cfitsio will be built without Fortran wrapper support

It can be easy verified by simple runnig of g77 (f77 will be not accessible).

Workaround

This is a bug in cfitsion library so we will wait for correction by authors (it is done now in cfitsio-3.06, but the correction is not included in "modern" distributions). In meantime, the best solution of this is recompilation of the cfitsio with creation of a "g77" compiler wrapper. The wrapper can be created as a shell script:

#!/bin/sh
gfortran $*

or as link

ln -s /usr/bin/gfortran g77

in any appropriate directory (~/bin,/usr/local/bin) and followed by the complete recompilation of the cfitsio library. This new library .a needs be placed to a system-wide linker path (/usr/local/lib).

The nm utility can help with inspection of the cfitsio library. The gfortran is pretty compatible with g77.

An evening

2007-11-10T23:23:00.000+01:00

Some time ago, I spend nice evening on HaP MK. A few shots describes an atmosphere of the times...

Larger photography.

Larger photography.

Larger photography.

Larger photography.

A trip to Macocha

2007-11-04T22:57:00.000+01:00

Macocha is an abyss near Blansko town (approximately 30km far of Brno).. cold evening, .. clear sky .. hight humidity .. Holmes near zenit... Milky way... really nice .. we had concentred to pointed photographing by our fish-eye .. The images covers practicaly full sky sphere. A lot of interesting objects can be identified. For example, Andromeda galaxy (M31), M33, NGC 456, Holmes, California... the large image (1/2 of original) shows optical quality of Canon's fish-eye f15. The picture is perfect at center while small triangles appears at borders. A light polution due to Brno (on south) and Blansko (west-north) is clearly visible...

The Sky (Canon EOS 5D, fish-eye 15mm, 127 sec)

The sky (Canon EOS 5D, fish-eye 15mm, 618 sec)

A large format of deep_macocha , A large format of deeep_macocha.

We still need the correct white balance of our camera....

The romantic time of the evening is illlustrated by images:

Staff at work (Canon EOS 5D, fish-eye 15mm, 30 sec)
Ground view (Canon EOS 5D, fish-eye 15mm, 30 sec)

Large versions: ground and staff.

Thx Mif, codel, RAMka and Kocka.

17P/Holmes on the sky of HaP MK Brno

2007-11-04T22:35:00.000+01:00

I'm introducing images acquired during our historical first star photo party using by a paralactic mount with a siderical driver. There are a few images taken during evenning 2007-10-31/11-01 on a terace of a building of HaP MK Brno. I and codel...

Wide field (Canon EOS 30D, f=18mm, 134 sec)

Detail of comet location (Canon EOS 30D, f=170mm, 244 sec)

Pleiades (Canon EOS 30D, f=400mm, 50 sec)

Orion's nebula (Canon ESO 30D, f=400mm, 30sec)

Don't be confused by background gradient (especially on wide field). It's due to a strong light-pollution by Brno. The observatory is located near center of 400th thousands town. Look also on codel's blog.

Munipack update

2007-11-04T11:10:00.000+01:00

I'd updated Munipack's configure.in to fit a "modern" way to search for fortran's 90 compiler by simply application of AC_PROG_FC macro.

This is a really great step, while last five years the compiler were detected by my own macro (four years ago) or by detecting of various specified compilers (up to today).

By the way, I'm suppose that Munipack compilation will more portable on modern distributions (Ubuntu?).

The macro's change will result in prefer of use of gfortran (not g95, ifc,..) compiler. One is pretty g95-compatible so it has implied changes in munilist's main and it remind me that the main is still non-wraped via C. I started rewrote it. The different compiler to compile can be specified via ./configure FC=ifc.

A problem has been reported under Mandriva Linux 2007.1 distribution. The compilation aborts with:

aflat_bin-autoflat.o: In function `MAIN_':autoflat.f90:(.text+0x8ce): undefined reference to `ftopen_'

(libcfitsio is installed corectly) which means that cfitsio is probally uncorrectly builded. The test with a simple C code is linked correctly, a simple code of fortran reveals the described problem. Specification of -fno-underscoring remove underscoring without expected effect.... (thx to petos).

A ghost (second test post)

2007-11-04T03:42:00.000+01:00

The in-line image of the ghost:

A ghost

2007-11-04T03:40:00.000+01:00

A ghost relevation on our image of the night sky acquired during excelent evening on Thu 1. november.

A ghost image

Test of gnome-blog

2007-11-04T03:05:00.000+01:00

An amazin test of gnome-blog...

First entry...

2007-11-04T02:40:00.000+01:00

Show me!