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
