Page top

Home page

Contents

Index

API (for
programmers)

Page bottom

Next page

What's new in GRIP

Note that the version number of GRIP is the date on which it was released on this site. Eg, 8.1.13 is 2008 January 13th.

• Version 12.1.1
  • This is really GRIP 2. A large amount of refactoring of the code has been done.
  • End users will see little difference except for more consistency between different image depths (8-, 16-, 32- or 64-bits per channel). Nearly all image processing operations can now be performed in any of those types of image. Conversion between image types now retains more of the metadata too.
  • Programmers using my API will find that I have been unable to keep it backwards compatible this time, as I have always done up to now. Having decided that some things would have to change quite drastically I went ahead and changed many things so that such a big upheaval should not happen again. The new API documentation is up to date but I have yet to revise the programming pages towards the end of this web site. To give some pointers as to the nature of the changes:
    • A new package net.grelf.image has been created to contain everything defining images but which is not specific to the GRIP application. This package has no dependencies on net.grelf.astro nor on net.grelf.grip. It does need the more basic net.grelf package but that is all (apart from Java SE standard code). Therefore it can be used in quite different applications if so desired, without a lot of baggage.
    • Classes Im and ImBase have disappeared. Instead the new image package has interface Image with 4 implementations: Image8, Image16, Image32 and Image64. The last of these uses floating point numbers for pixel values, the others use 3 different sizes of integer. (A predecessor of Image32 was called ImageInt and Image64 evolved from a former ImageDouble). Image8 and Image16 use a java.awt.image.BufferedImage internally but it is no longer necessary to refer to that in most cases. Image32 and Image64 use my own image representation and processing these deeper images can in fact be quicker than processing the shallower ones. Some code is common and so there are abstract classes ImageBase and Image8or16Base that avoid repeating such code.
    • Classes ImProcess and Convolutions, which only contained static methods, have also disappeared. Those methods which took a BufferedImage as a parameter have become instance methods in the implementations of Image. Those methods which took an ImFrame as a parameter have become instance methods of ImFrame. (I had been wanting to do that for years; for one thing it makes unit testing easier.)
    • The package net.grelf.grip still contains Accumulator32 and Accumulator64 classes which are subclasses of the corresponding Image implementations. These accumulators only contain the GRIP-specific methods, mainly for combining images (especially for stacking astrophotos but I know that some programmers have other interesting uses for the warping methods).
    • The code for the dialogues in GRIP that show preview images has been considerably simplified by the new image structure, particularly because the interface ImPreviewActor no longer has to distinguish between BufferedImages and Accumulators.
    • Methods throughout which had been marked as deprecated for a while have now been removed.
    • There are some cases where a new class in net.grelf.image (eg, HistogramAll, ByteMask) forms a superclass for a more specialised version in net.grelf.grip (Histogram, BlobMask). HistogramAll deals with whole images but subclass Histogram is able to form histograms of arbitrary shapes. The general image operations of erosion and dilation have been moved to the image class ByteMask but GRIP's BlobMask deals with segmented objects (regions of interest) within images.
• Version 11.11.21
  • The Batch/Astro menu has a new option "Accumulate star trails". The trouble with combining a sequence of N images of trails is that each star moves while the background stays fixed. If there is any brightness at all in the background sky, it will be added up N times but the star trail sections only appear once in each position. The stars therefore become very faint compared to the sky. So this new option finds the stars in each image and amplifies their pixels by the factor N before adding into the accumulator, while leaving the sky alone.
  • The semi-interactive comet processing on the Batch/Astro menu now reports at the end the number of skipped frames, those frames in which the stationary object could not be detected. If you close a main frame without clicking on a detected blob it will be skipped.
  • The option to neutralise the background in 32- or 64-bit images has been improved so that it works in the majority of cases. (When it does not work the failure is obvious: sorry, but try something else. The difficulty is in calculating histograms and finding accurate modal values of such deep images.)
  • For programmers: some significant refactoring has been done so that Accumulator is a sub-interface of Image. There are 2 implementations of each of those: AccumulatorInt and AccumulatorDouble, ImageInt and ImageDouble (all still in package net.grelf.grip). Most of the code has gone into the Image implementations. The Accumulators only contain code relevant to accumulating (does that sound logical?). This is a step towards making an image package that is not dependent on GRIP-specific features such as ImFrame and ImPane. A few methods have been marked as deprecated in favour of renamed ones, such as Im.hasAccumulator() becoming Im.hasImage().
  • The documentation of the menus in GRIP is now getting out of date again. It will be revised as soon as possible.
• Version 11.10.4
  • The batch menu was far too long so it has been folded into several sub-menus.
  • The Batch/Astro menu has a new option "Measure a star (select on first image)". It first asks for confirmation that another option "Warp onto common basis" has already been used so that the images to be measured are all aligned. It then segments stars in the first image of the sequence and asks you to select a star by clicking on or near it. It then measures the integrated brightness of the star as accurately as possible (using the photometric circles as in the Blob Menu). It repeats the measurement on the same star in the rest of the images and saves the results as a CSV (comma-separated value) file for loading into a spreadsheet.
    It is hoped to extend this new option to measure simultaneously all stars in each image, or perhaps the brightest n (where n is determined by the user).
  • Bug fix: histograms of 32-bit or 64-bit images were sometimes failing with an array index out of bounds due to rounding errors. This has been prevented.
  • Bug fix: resaving an image in FITS format which had been opened from FITS always caused a duplicate main header to be written, which was not in accordance with the FITS standard. This has been prevented.
  • Numerous small improvements, such as showing image number in the image caption while processing a sequence of comet images.
• 2011 July 15 - Not a new version of the code but a correction to the help file, pages.zip. The images for the page "Introduction to GRIP" were not included in the zip file. That has now been corrected. Many thanks to Roy for pointing the error out.
  The help files are just a subset of the pages on this site, to enable them to be seen when off-line.
• Version 11.6.1
  • GRIP now loads FITS files entirely by its own code. There is no longer a need to put any fits.jar file on the classpath. This is not merely to avoid using third party packages but to avoid having to copy the image from one data structure to another after loading into memory. This not only gains speed but also makes it more likely that there will be enough memory to load an image.
  • New options on the geometry menu enable lens distortions to be calibrated and corrected automatically, using a "warping grid". A reference image is required, comprising a square array of dots photographed through the same optical arrangement (lens and focal distance) as that which is to be corrected. The dots may be small squares or circles but they must all be of the same colour and intensity on a uniform background. The easiest method is to print an array of black dots on white paper. GRIP even provides a suitable image: from the initial file menu select "New test grid of squares". Ensure that the image size is such that none of the black squares touches the edge. Save the image as a TIFF file so it can be printed accurately (by any other convenient software). Photograph the printed array through the lens you wish to correct, again ensuring that none of the dots touches the edge of the photograph. Then use the option on GRIP's geometry menu, "Make warping grid". That measures the centres of the dots, works out their average spacing and orientation, and for each dot calculates where it should lie on a perfectly regular grid having the same spacing and orientation and such that the dot nearest the centre of the image will not move. Finally you will be prompted to save the measurements in a file with the extension .warp. This is in fact a comma-separated value (CSV) text file so you can look at it with any text editor or spreadsheet. Each row in the file contains the x and y coordinates of the centre of each measured dot followed by the x and y of its corrected position. So the .warp file is the warping grid that can be applied to any subsequent image photographed through the same lens. The option "Use warping grid" on the geometry menu does the job. It will ask you to select the .warp file so GRIP can load the grid measurements. It then calculates a set of polynomials that will warp the image (like a rubber sheet) to correct the distortion. Accurate interpolation is done between pixels to get a smooth result. (The warping is the same method that is used when combining multiple exposures in astrophotography but there GRIP is matching star patterns between frames.)
    NB: There is a limit to the amount of distortion that GRIP can accurately correct. If you find the result is not accurate enough then first use inverse gnomonic projection (which depends on the focal length of the lens), followed by the warping grid as described here. Note that the projection may produce elongated black areas at the edges of the image. That is not a problem because the process creating the warping grid ignores elongated objects.
  • A new option on the batch menu enables a warping grid to be applied to a set of files automatically.
  • A new option on the levels menu enables a warping grid to be created in a more manual way by first thresholding a reference image, then detecting blobs, then creating and saving the grid. Most users will find it easier to use the more automated option on the geometry menu.
  • For Java programmers: the change in loading FITS files means that most of the constructors of classes implementing Accumulator have become redundant and have been removed. All the work involving different types of data arrays is now done by FITS.load () directly from the input data stream instead of from intermediate arrays.
• Version 11.5.22
  • Tidied some flaws in the new 64-bits-per-channel processing: 64-bit FITS files can now be saved and read correctly; curves no longer overflow (to black) at the maximum value.
  • The levels menu was getting too big so a sub-menu now covers the various possibilities for changing the bit depth of an image.
• Version 11.5.17
  • All image processing operations can now be applied to images held as 64 bits (double precision floating point) per channel.
  • The curves dialogue has two new buttons for saving and loading curves as disc files. The files are simple text files with the name extension .curve. This enables the same curve to be applied to several images.
  • Inevitably there were some problems with the major upgrade in the previous version. These have been tidied up. The worst one I have found was that Gaussian blurring on the convolutions menu produced a black result on 32-bit images - now fixed.
  • Documentation of the menus has not kept up with recent changes but that will be attended to soon.
• Version 11.5.8 - Major enhancement
  • * All image processing operations can now be applied to images held as 32 bits per channel.
  • * Images held as 32 bits per channel can now be saved as 32-bit (integer) FITS files and loaded back from there.
  • Change 1 above means that the batch processes for combining (stacking) images now end with the accumulator on display, ready for any of the numerous menu options to be applied to it. It is no longer immediately put through a curves dialogue to convert it to a 16 bits per channel image for further processing.
  • Change 2 above means that the .accum file format that only GRIP can read is now redundant. It has been retained because I have a large number of astrophotos in that format that I may wish to reload. From now on the accumulator can be saved at any time as a FITS file (32-bit integer channels) and reloaded from there. This also means the full 32-bits-per-channel data may be transferred to other applications for further processing. FITS is the standard image format for astronomy (link to further details and formal specification).
  • A diagram showing how the various image file formats can be used with GRIP can now be found here.
  • FITS files holding 32- or 64-bit floating point values can also be loaded but they do immediately present a curves dialogue, complete with histogram, for scaling into 32-bit integers per channel.
  • The "Show image information" option on the image menu now uses a scrollable text area so that (a) all the keyword metadata from a FITS file can be shown and (b) the text can be selected and copied to the system clipboard.
  • For Java progranmmers: class AccumulatorInt has expanded enormously to parallel all the operations on BufferedImages in ImProcess. There have been consequential small changes in many classes but backward compatibility has been maintained except in a very small number of cases.
    AccumulatorDouble has also been greatly improved, with the aim of similarly expanding that soon. Special care has been taken to ensure that the data arrays are as small as possible, so that as many of these deep images can be held simultaneously in memory as possible.
    Metadata for FITS files is better handled and no longer shown to the user as the files load. Saving, in the FITS class, is written from scratch rather than using the nom.tam.fits library because that copies data arrays unnecessarily.
• Version 11.4.8
  • In the image summary dialogue at the end of pass 1 of the batch astro process, rejecting an image from further processing causes the graph of drive errors to be repainted with the rejected image(s) shown in grey.
  • At the end of pass 2 of the batch astro process there is now a message box confirming how many images were processed to make the final result.
• Version 11.4.5
  • The drive errors dialogue that appears during the batch astro process has been extended so that (a) it shows several other measurements made on each image and (b) the user has a check box on each row of the table so that certain images can be rejected on the basis of those measurements, so those images are not processed in pass 2. The measurements include the number of stars detected and the average circularity of detected objects (ratio of radii calculated from measured area and perimeter, which should be 1 for a perfectly circular object). Circularity is likely to differ from 1 if the star tracking is inaccurate during the exposure. The number of stars detected may be reduced if the image is blurred.
  • A bug in the way the interiors of detected objects were scanned has been present in GRIP from the beginning but has now been definitely fixed. This has made possible the proper measurement of circularity as described in the previous item. For this reason the option on the levels menu for showing the most uncircular detected objects is now also more effective.
  • For Java programmers: note that the class DriveErrors has been renamed ImageSummaryDialogue because of the expansion of the dialogue's role. Also class ImageOffset has become ImageSummary.
• Version 11.3.30
  • The dialogue for reading a 32-bits-per-channel accumulator out into a displayable 16-bits-per-channel image through a look-up curve has been considerably improved. This dialogue appears either at the end of the batch astro-process, when many images have been combined into an accumulator or when opening an image from a saved accumulator file (.accum). The improvements include the following.
    
    • The histogram is displayed in the same window as the interactive curve and the preview image, so it is no longer necessary to drag the curves dialogue in order to see the histogram.
    • The histogram is now truly of the accumulator rather than the scaled image, as can be seen by its axis labelling.
    • A new button in the dialogue enables the background to be neutralised. This is intended for the typical astrophoto situation where light pollution gives rise to a histogram containing 3 background peaks of which the red peak is typically further to the right (brighter). Neutralising the background is done by linearly stretching 2 channels (if it is a 3-channel image) to make all the modes coincident. Importantly this is done in the accumulator, before the look-up curve is applied. The accumulator is therefore modified by this step and the step cannot be repeated (except by reloading the .accum file). This change is really useful for astrophotography in which faint details just above the background are to be brought out by the look-up curve. That can now be done much more effectively and an interesting example can be seen here.
    • A new option on the drop-down list of preset curves is "Linear from mode". This makes the look-up curve zero until the mode for channel 0 (red in an RGB image) and then rise linearly to the maximum brightness. This is most useful after the background has been neutralised as above. It is of course more accurate than trying to position the start of the rise by eye to match the modal position in the histogram.
  • The above background neutralisation has required a small change in the way statistics are calculated for histograms so that a saturated maximum brightness level is not counted as a modal value. Modal values displayed always ignore zero and maxmimum brightness. Other statistics, such as min, max and mean do not ignore those extremes.
  • Awkwardness in the way new points are inserted in the curves dialogue has been corrected.
  • The way stars are drawn in GRIP-generated star charts has been improved.
  • Although GRIP does not attempt to recognise exposure times etc in the metadata of FITS files, as it does when loading other image formats, (because there does not appear to be much standardisation - true?) it does now display in a scrollable window all of the metadata found in such a file.
• Version 11.2.18
  • The order of events has changed slightly at the end of the batch process for combining into 1 image:
    1. Optionally save the accumulator in a .accum file.
    2. The accumulator is scaled linearly into a 16-bits-per-channel image which is displayed.
    3. Optionally save the 16-bit image in a .tif file.
    4. A histogram of the accumulator is displayed, along with the curves dialogue for reading the accumulator out in a different way from linearly, if required.
    Previously it was necessary to reload the accumulator from file if a different curve was required.
  • The file naming from the batch process for combining into 1 image has changed, to indicate which of the 3 radio buttons was selected for the processing:
    • image1-imageN_warp.accum or .tif
    • image1-imageN_shav.accum or .tif
    • image1-imageN_shbr.accum or .tif
    This makes it easy to see afterwards which method was used.
  • The "Combine" menu of the image table window has a new option: "Build 1 RGB image". It is enabled when 3 single-channel (monochrome) images have been selected. The motivation for adding this came from the next new item.
  • GRIP can now read images from FITS files, provided you obtain the file fits.jar from http://heasarc.gsfc.nasa.gov/docs/heasarc/fits/java/v1.0/v1.05.0/ and put it on the classpath (ie, in the same directory as GRIP.jar) and modify file run.bat to mention it in the list of .jar files. Then if, when opening an image, the file extension is .fits (in any case combination) the file is assumed to comply with the FITS standard.
    FITS images can hold data in several different primitive array data types. Depending on the size of each datum, GRIP will behave in one of two ways when opening such a file:
    • If the data type is small enough (ie, integers with at most 16 bits per channel) a Java BufferedImage is created and immediately displayed in its own window, just like any other image in GRIP.
    • Otherwise an accumulator is created, similar to that used in the batch process for combining images except that it will either contain 32-bit integers or 64-bit floating-point values (Java type double). So the user will then be presented with a histogram of the accumulator and a curves dialogue for scaling the data into a 16-bits-per-channel image.
    GRIP can load FITS images having either 2 or 3 axes, the former representing monochrome images and the latter being treated as RGB (though that may mean false colour interpretation of the original data). The FITS standard does not specify which of the 3 axes is the channel (band) index for 3-axis images, so GRIP makes the assumption that the shortest axis is the channel (band) axis and can deal with that being any one of the 3.
    NB: This FITS capability must be regarded as "beta" at present. It has been verified on a range of samples but FITS allows many possibilities. Also note that no attempt is made yet to interpret metadata such as exposure settings or date and time.
  • For Java programmers: the FITS capability has meant that Accumulator has become an interface. It has 2 implementations so far: AccumulatorInt and AccumulatorDouble. The latter has required another new class: RangeDouble.
• Version 11.1.1
  • For users working with RAW images: a cloned RAW image now offers relevant options on the Levels menu. GRIP does work with the latest version of jrawio (version 1.6.1) - if you download the binary .gz file and extract the .zip, put it on the classpath and add -Dit.tidalwave.imageio.raw.defaultSource=rawImage to the start command in run.bat, which should then look like this:

    set classpath=GRIP.jar;jai_imageio.jar;clibwrapper_jiio.jar;it.tidalwave.imageio.raw-1.6.1.jar
    start java -Xms768m -Xmx1024m -Dit.tidalwave.imageio.raw.defaultSource=rawImage net.grelf.grip.GRIP

    or in 64-bit systems like this:

    set classpath=GRIP.jar;jai_imageio.jar;clibwrapper_jiio.jar;it.tidalwave.imageio.raw-1.6.1.jar
    start java -Xms2000m -Xmx2000m -XX:+UseSerialGC -Dit.tidalwave.imageio.raw.defaultSource=rawImage net.grelf.grip.GRIP

  • For programmers: two significant new classes in net.grelf - MeasuredValue and Angle. In net.grelf.astro several classes have been modified to use Angle.
• Version 10.10.22
  • A new option on the Batch menu, "Astro combine for comets" provides a semi-interactive method for combining multiple exposures in which there is a slowly moving object (eg, a comet or minor planet) which it is required to keep fixed, letting the stars trail past it. As each image is opened GRIP attempts to segment stars and pauses to allow you to click on the object that is to be kept fixed. As a caption says, closing the image window then proceeds to do the same on the next image until all have been processed. The images are shifted into registration according to the differences between the indicated object positions and accumulated to make the final image. Here is a result created by this process.
    NB: That assumes that the comet nucleus (or whatever the object) is sharp enough to be detected as a star. If that is not the case the method can still be used, with a little more work. On each paused image type Ctrl-H (the short-cut keys for the "Hover and magnify" option on the measurement menu). That makes it possible to click anywhere on the image, not just on detected star-like objects. Zoom in a few times to make the pointing as accurate as possible in this case. Otherwise the process is the same as before.
  • I have only just discovered that there may be difficulties in running GRIP in 64-bit systems. Particularly in batch processes it may fail with "Out of memory" errors. This is misleading - there is not really a shortage of memory. The fix is to include -XX:+UseSerialGC in the file run.bat, as described on my trouble-shooting page.
  • For programmers: in creating the new batch process for comets I found and fixed significant bugs in the two Accumulator.add methods that involve translating the image. Those methods were really not working at all.
• Version 10.8.28
  • New blob measurement option on the levels menu, for use after segmenting stars: plot log brightness against B - G colour index.
  • Bug fixed in star chart loading in which epochs were not recognised if they began with a letter (B or J). This was causing it to be impossible to click and see data on a reloaded star chart that had been saved by a recent version of GRIP.
  • For programmers: bug fixed in multiplying complex numbers, in the new Complex class. The unit testing for this class has been improved.
• Version 10.8.23
  • A much better method of detecting stars in images has been included (programmers: see new class net.grelf.grip.StarSegmenter). It works even if there is significant background variation, so there is no longer a need to do background correction first. It even works for stars embedded in (or in front of) nebulae. It is controlled by 2 parameters but tests on a variety of images (my own and some from other people) has shown that values of 38 and 16 always work. In case it should prove necessary to vary the parameters they have been included in the configuration file (grip.properties) and are therefore adjustable through the Config menu of GRIP. To make that work you will need to delete the file grip.properties if it already exists from a previous version of GRIP, and then re-run GRIP.
  • The levels menu has been changed to use the new star segmenter. The old option "Auto-threshold (stars)" has been replaced by "Auto-segment (stars)". Unlike the old option this does not require you then to "Detect blobs" as a separate step. It goes on and does that automatically so you end up with an interactive image - as the mouse hovers over it, the nearest star to the cursor is highlighted and some measurements are shown.
  • The batch astro-processes also use the new method of star segmentation, so they work on a wider range of images than before (eg, those containing much nebulosity or background variation that could not be corrected).
  • The "Blob/star measurements" option on the levels menu now enables you to see a graph of "Colours". This plots red excess (R - G channel brightness) against blue excess (B - G channel brightness) - both values normalised by dividing by the total brightness of the blob/star. This is useful for looking at star populations in clusters and an example can be seen here.
  • Some awkwardnesses in the way the application was zipped for download have been corrected.
  • For Java programmers: new class net.grelf.Complex covers mathematics with complex numbers (not actually used in GRIP but in some applets I am developing for the BAA Computing Section web site).
  • For Java programmers: to improve my unit testing, some classes have been changed to implement interfaces. In such cases class X has been renamed X_ and it implements interface X. (Note on programming style: I don't like the way many people use XImpl as the name of an implementation because it implies that there cannot be other implementations of the interface. On the other hand IX for the name of the interface, which some people write, is not good because the fact is that the type name that really matters is X. So I am using X_ to denote a kind of default implementation of X. I am sure many will disagree with this policy.)
    I have also split some classes X into class XBase and class X extends XBase, as a step towards making my packages more independent of each other. This should not require any changes to code using X.
• Version 10.5.7
  • The star chart dialogue (New star chart on the file menu of GRIP) now gets the coordinates of an object and the data for the star chart directly from the public Simbad database (at the Centre de Données Stellaires in Strasbourg) without requiring AstroGrid to be installed or running. A live internet connection is needed of course.
    NB: During testing I have found (and reported to CDS) that the positions of stars with identifiers containing the word "Melotte" are not very accurate and sometimes result in stars being duplicated in the chart.
  • For programmers: some refactoring has been done to move several general-purpose classes to the higher level package net.grelf. This enables them to be reused more easily without being dependent on any classes in net.grelf.astro or net.grelf.grip. Only one method signature has had to be changed: Util.saveJTableAsCSV ().
• Version 10.4.5
  • The speed of combining a large sets of images has been improved significantly. I was finding with my 23 Mpixel images that the warping step slowed by a factor of 3 after the 9th image. There is now no slow-down.
  • For programmers: the access to logging has changed so that classes that log anything no longer necessarily require the GRIP class for compiling or running.
• NB AstroGrid has recently been updated. The JAR file is now called acr-interface-1.3.2.jar (previously acr-interface-1.2.2.jar). The good news is that GRIP does not need recompiling to work with the new version. So if you are using AstroGrid services from GRIP simply replace that JAR file and edit GRIP's run.bat file for the one-character change.
• Version 10.2.12
  • On the main GRIP file menu, saved HTML pages of reference stars from AAVSO can now be loaded as star charts and then saved as .chart files in GRIP's (XML) format.
  • On the batch menu a new option enables .chart files to be merged. So by using this and the previous item, AAVSO reference stars can be incorporated very easily into charts drawn from Hipparcos and Tycho data (either from local files or via AstroGrid). Note that if a magnitude for a given band has already been found when another chart refers to the same star, the magnitude is not changed by the second occurence. Therefore the reference chart must come first in the list to be merged.
  • Unfortunately the improvements to the handling of Dec values in 10.2.7 caused problems in reloading saved .chart and .blobs files. That has been corrected. Any files saved with previous versions will now load.
  • Programmers should note the new class net.grelf.grip.Maths which correctly calculates statistics of a list of angles even when they spread across the jump between 360 and 0 degrees. If you search on the internet for averaging angles you will find methods that are definitely wrong (they may work for special sets of values but not generally). I needed these statistics for calculating the centre and size of any merged star charts.

  The reason I am doing so much with charts is that I plan to be able to map photos onto charts automatically. Then measuring positions and magnitudes will be really easy.

• Version 10.2.7

  Numerous small improvements arising from testing, of which the following are the most significant.

  • Measuring small angular separations on photos is now more accurate.
  • Display of position values (RA and Dec) no longer repeats the whole number part of the seconds as the fractional part (internally the values were correct)!
  • On the star chart dialogue the fields for entering declination values had a possibility of ambiguity when the degree value was zero. This is now correctly handled: if you put -0 as the degree field it will be realised that the minute and seconds fields should be interpreted as negative, regardless of whether you also put minus signs in those fields. Declination values returned from the Sesame service are displayed such that any minus sign goes in the degrees field, even if that is zero, and it will be interpreted correctly when going on to create a chart. Programmers will find that the documentation of class net.grelf.astro.Dec has changed in the light of this.
  • I think the problem is finally solved in which star charts could not be created if the AstroGrid JAR files were not present.
• Version 10.1.20
  • Metadata written into the image resulting from combining a sequence of images now has the correct month!
  • The XML saved from the magnitude graph is now well-formed (one element was not paired correctly).
  • Star charts saved as XML now include the chart caption as a <Chart> element and the caption is editable from the image menu. Also reloading star charts is more tolerant of different formats for RA and Dec values.
• Version 10.1.16
  • The magnitude graph has a new button, to save the results as XML. The XML is designed to be easy to incorporate into a larger XML file covering a large number of such observations, perhaps of several different stars and using different charts and equipment (all identifiable in the XML).
  • The batch menu has been rearranged, putting the astro-process near the top. At the same time that option has been renamed more explicitly as "Astro combine into 1 image". Also there is no longer a choice between camera or telescope versions of the option (which were only to help the user to decide which options to tick in the dialogue that appears before processing). It will be a while before these pages are all revised, so wherever we refer to the "batch astro-process" it means this option, for combining a set of images into 1. Some tool-tip text has been added to the menu to explain.
  • A new option on the batch menu is "Astro warp onto common basis". This is quite similar to the old astro-process except that the images are not combined. Instead each is separately distorted and re-saved with _warp in the file name. The distortion (done in the same way as in the older process) ensures that the centre of each blob (star) is at the same (x, y) position in every image. This prepares for analysing star variability in a sequence of images over potentially long time spans.
  • Another new option on the batch menu is "Accumulate images into 1". This does the same processing as the old "Average images", using the 32-bits-per-channel accumulator. The difference comes at the end. Averaging simply divides all levels by the number of images and writes back into a normal (8- or 16-bit) image. The new option instead presents a curves dialogue and histogram of the accumulator so that maximum contrast can be obtained in the result when it is written back into a normal image.
  • The dialogue displayed at the start of the batch astro processing has been considerably improved, with some new adjustable parameters.
  • It has been made harder to accidentally close an image window while processing is continuing, which could cause worrying error messages.
• Version 10.1.13
  • Magnitude estimation does now use multiple wavebands (eg, Johnson U, B, V, R, I) if they are available in the reference star data. A new dialogue makes it possible to say which waveband should be used for each channel of an image (either monochrome or RGB). The default assignment for monochrome images is to use V band and for RGB to use RVB respectively (and V for the overall brightness measurement). The resulting graph indicates in a key which bands were in fact used for each of the reference stars. All reference stars should of course use the same bands - there is no reason why they should not but the graph legend confirms it.
  • Confidence intervals are now shown in the magnitude estimation graph, using the calculation scheme decribed here. Experiments on my own images show that the errors in the brightness measurements are smaller than in the supposedly known magnitudes of the reference stars. Hipparcos and Tycho data do include standard error estimates which reinforce this conclusion. So perhaps the graph was the right way round earlier - magnitude as the y-axis and log brightness as x. I am not proposing to change it again for my own purposes.
  • A smaller font is used for the reference stars on the magnitude estimation graph and the annotated star chart, to reduce confusion where text overlaps. The graph now uses a key listing reference stars to further reduce the clutter.
  • The magnitude estimation graph now also shows the name of the image that was measured and the start and end of the total exposure sequence used to create the image (both as date/time strings and as Julian dates).
  • The combined image created by the batch astro-process now contains metadata including camera settings and the overall start and end times of the exposure sequence. This is all stored as a semicolon-separated sequence in the ImageDescription tag of a TIFF structure. It is therefore visible in other applications such as PhotoShop. GRIP can decode the sequence again to make use of each item, eg to show times as Julian dates in the magnitude estimation graph.
  • If a star chart is opened from a disc file and it contains stars having user-entered ids (<OtherId> elements) those stars are assumed to be in use as reference stars for magnitude estimation and are highlighted in small red squares on the display. This is to make it much easier to go through a reference sequence and identify the same stars on images being measured. It is possible to edit <OtherId> elements into the XML .chart file with a text editor and this may be the quickest way to set known stars as references, from their other (eg, Tycho) ids.
  • The chart annotation done when estimating magnitudes is now more flexible: the list of open images is searched for any chart that contains the reference stars and that chart is copied and annotated.
  • Magnitudes in band I are loaded from the Hipparcos data file, hip_main.dat. I is not available in the corresponding Tycho file, tyc-main.dat. Magnitudes in bands V and B were already loaded from both files.
  • Image information (on the image menu) now also shows the time of taking the photo as a Julian date, to the nearest second. To support that a new field in the configuration menu is for setting your local time zone offset, though the system should set that automatically when the configuration file (grip.properties) is first created.
  • A handy new Julian date conversion dialogue is also available from the configuration menu.
  • If an image which has associated blob/star data is cropped (via the geometry menu) then the blob data are modified so they remain valid for the cropped image.
  • Fixed some small problems: Tycho ids were not appearing in star charts generated from local data files, XML .chart files were sometimes not well-formed for multi-band magnitude elements.
• Version 10.1.1
  • The blobs menu now enables each blob to measured accurately by using a disc completely surrounding the blob and subtracting the mean background level measured in a ring outside that. Full statistics of the background measurement are saved in the XML .blobs file to enable further analysis to be done if required. Magnitude estimation uses the more accurate brightness measurements and, as expected, straight line fits of log (brightness) against magnitude are much better. The estimation has been done for a photo I took of Nova Aquilae 2009 and full details of the method are being added to that page.
  • If blobs were identified as stars by pasting star data from a GRIP-generated star chart then an annotated copy of the chart image is also produced when magnitudes are estimated. This shows which stars were used for making the least-squares fit graph.
  • Magnitude estimation using star charts to assign star data to detected blobs in an image now works if the image is monochrome. Previously it only worked for RGB images.
  • The axes of the magnitude estimation graph have been swapped, to make clear that magnitudes are assumed to be known accurately whereas brightnesses measured from the photo are subject to error. It is intended to add error bars to the graph soon.
  • Stars in GRIP may now have multiple magnitudes, in different wavelength bands. Multiple magnitudes are now extracted from VO tables returned by AstroGrid cone search services. Alternatively the Hipparcos and Tycho data files provide both B and V magnitudes for GRIP to load from a local disc. Magnitudes other than V are not yet used in the magnitude estimation graphs but that will come soon.
  • The star chart generation dialogue now allows two possible cone search services to be used through AstroGrid: Tycho-2 and USNO-B. However in my experience so far the USNO service is unreliable. That is a shame because it can return much fainter stars for plotting in the charts.
  • The interactive star charts can now be saved as XML files (extension .chart) and reopened. When reopened they still have the full interactivity.
  • The magnitude estimation graph and the drive error analysis graph can now be saved as images (I suggest .png for smallest files).
  • New option on the measurement menu: Star spectrum. This works in steps, so you can stop after any step. It assumes you can crop the image (in step 1) to include just a star trail and corresponding spectrum. It then rotates the cropped image automatically so the spectrum is horizontal, with the star trail vertically on the left. It corrects the spectrum for wobble in the star trail then averages vertically and displays a profile from the centre of the star right along the spectrum. It is intended to develop this further.
  • GRIP's command line now recognises file paths as parameters. If the file names end in .accum, .blobs or .chart (GRIP's own file formats - the latter two XML) or the usual image file extensions then the files will be opened automatically when GRIP runs.
  • For programmers: the BlobMeas class has changed considerably to allow for the more accurate brightness measurements and background ring statistics. Consequently the XML .blobs files have also changed, though it is still possible to reload earlier ones.
• Version 9.12.14
  • New option on the measurement menu: "Calibrate from known stars". Having identified some detected blobs as stars, from a GRIP-generated star chart, simply selecting this option automatically calculates the average scale and orientation of the photo.
  • There is a new option on the measurement menu: "Blobs/stars separation data". It is only enabled if blobs have been detected in the image (from the levels menu) or reloaded from a .blobs file. It enables clicking on or near 2 blobs at a time (like measuring a straight line but the points snap to the nearest blob). The distance and slope of the line in the image are then shown. If both blobs have been identified as stars, to the extent that equatorial coordinates (RA and Dec) are known, then the position angle (PA, anticlockwise from north) and the celestial angular separation of the 2 stars is also reported. This works on the interactive star charts too - you can measure the PA and angular separation of any 2 stars. When measuring two stars identified in a photo (rather than a star chart) there is an option to overlay a meridian on the image, to show its orientation.
  • The profile drawn by measuring a straight line or a curve is now in a horizontally scrollable pane.
  • Data displays from the measurement menu have a new button, "Copy data", which copies all of the data which is listed as text to the system clipboard for other applications to paste. The data are in a crude form of HTML, as recognised by Java graphical components to control layout.
  • The naming of options on the measurement menu has been revised so that it can be seen which kind of display will result from a measurement - histogram, profile or plain text data.
  • Saving an image, which may change its name, now automatically refreshes the image table.
• Version 9.12.8

  • GRIP can now obtain data for star charts through AstroGrid. So far 2 services are used, both from the Star Chart dialogue, which now looks like this:

    

    The new field and button at the top enable you to enter the name of an object and call the Sesame service to get its coordinates, which are then automatically entered into the RA and Dec fields. For this to work you must first have AstroGrid's Virtual Observatory (VO) Desktop running. You can download that and install it by following very simple instructions on the AstroGrid site.

    Also you need to copy VODesktop's 3 jar files (the RMI versions of acr-interface-1.2.2.jar, rmi-lite-1.0.jar and commons-logging-1.0.3.jar) into a /lib directory under the directory from which GRIP is running. You can check that by examining GRIP's run.bat file. GRIP will not fail if it does not find these files but you will get a message box if you try to access the AstroGrid services.

    Sesame is a very useful service and it seems very flexible in the names it can interpret. Letter case does not matter. Constellation abbreviations and the first 3 letters to spell Greek letters are fine. NGC, M, etc, and popular names of nebulae all seem to work. In the example dialogue I have used HR Del, as I have a page on this site about it.

    The second service used, if you have the VO Desktop running, is to get the star data for the chart. At the moment that uses the Tycho-2 database of 2.5 million brightest stars. GRIP can also decode the response from the US Naval Observatory B database (even more stars) but I am not yet making that available, because of some issues mentioned below.

    If VO Desktop is not running or it fails to get the data for some reason, GRIP tries to get the data from local files holding Hipparcos and Tycho data, as before.

    There are some issues with using AstroGrid which I am attempting to clarify with them before going further. The main one is that if you set a field width greater than about 1 degree there seems to be a restriction on the amount of data coming back. The data are truncated and so cannot be marshalled across the RMI interface. Worse than that, AstroGrid does not give a message that GRIP can intercept in such cases so it just seems to fail without explanation. GRIP does not crash however - just try again or do something different.

    For Java programmers trying to use AstroGrid's API: it only took me a few days to get this far. I may be able to help if you email me.

  • This version can no longer open .blobs files saved by version 9.12.2, only the XML format saved by 9.12.3 onwards.
• Version 9.12.3
  • The format of the .blobs files introduced in version 9.12.2 has been changed to XML. This has several advantages, not least that it is human-readable as text. The file size is only about 50% greater than before. This version of GRIP is able to read either the previous format or the new XML format but will only save in the new format. Later versions will probably not be able to read the previous format, so if you were quick to use yesterday's new feature, convert your .blobs files now by opening and re-saving.
• Version 9.12.2
  • A major new feature has been added to enable blobs detected in an image to be identified as stars and have all known star data attached to them. Create a star chart for approximately the same region as the photograph. Clicking on a star in the chart displays its catalogue data (from Hipparcos and Tycho) and now also makes the star object available for use elsewhere. To associate the star with a blob do the following. On the levels menu of the photograph, threshold (either automatically or manually) to get the stars in green, then detect blobs. Then hovering over the photograph you can click near any star to see it highly magnified in a new small window. That window has a blob menu from which a new option now enables you to paste the star data. From then on that blob includes the star details in its data. You can go on to identify several stars in this way and then do magnitude estimation on others. It is hoped to extend this to make useful bulk star measurements on the photographic image, eg for monitoring all variable stars in the frame at once. Having taken one photo of a region it will be possible to automatically identify the same stars in subsequent photos (that is what GRIP does now when aligning multiple images) - watch this space!
    One thing I have done so far is to repeat the estimation of HR Del's magnitude (discussed here) by associating my photographed stars with Hipparcos and Tycho stars from a GRIP star chart:
    
    
    I hope you can see the potential of that!
  • Having spent time identifying blobs as stars in an image you would not want to lose the results. So another major new facility, accessible from both the levels menu and the blob menu, is for saving all blob data and any associated star data, in a file with extension .blobs. The saved data include the path to the image file. So for reopening the blob data and the associated image there is a new option on the main file menu of GRIP: "Open blob data & image". NB: If you subsequently want to move the image to a different directory or disc you would need to reopen the blob data and image and then resave them in the new location.
  • If you attempt to crop an image for which there are data for detected blobs, a confirmation dialogue appears to warn you before proceeding.
  • For programmers: the above has involved making several classes serialisable, particularly in the package net.grelf.astro. A .blobs file simply contains a serialisation of class BlobMeasList.
  • The option to average vertically has been removed from the levels menu.
• Version 9.11.25
  • New option on the astro-process dialogue: neutralise background.
  • The option "Auto-balance (equate modes)" on the levels menu has been renamed "Neutralise background". It still does equalise modes (assumed to relate to the sky background) but it now does it by scaling channels to match the minimum modal value rather shifting up to match the maximum. This new method ensures that bright objects do not change colour while the background becomes on average a neutral grey.
  • The histogram window displayed to assist converting the accumulator to a 16-bit image is now automatically closed when the curves dialogue is closed.
  • At the end of the batch astro-process a new window pops up headed "Drive error analysis". It contains both a table and a graph of how the photographed image has moved with time.
• Version 9.11.18
  • The problems with the curves to convert from 32-bit accumulator to normal 16-bit image have been corrected. So both at the end of the astro-process and when reloading a .accum (GRIP-format) file, the user is once again presented with the curves dialogue, now working correctly.
  • A new feature is designed to help with that contrast-enhancing curves display for converting the 32-bit accumulator: a new window pops up automatically, containing a multi-channel histogram of the accumulator across the brightness level range that the accumulator currently contains.

  The use of both of the above features is described here.

  I see that Tidal Wave are once again working on jrawio and making good progress. Their latest JAR file (v1.6) does work with GRIP. It only has to be on the classpath declared in GRIP's run.bat file, if you wish to download and try it. Unfortunately they have not yet got the colours right for Canon EOS 5D MkII, but apart from that my latest raw images do load. jrawio is the only third-party software that GRIP uses. It is a set of JAI imageio plug-ins, so no recompilation of GRIP is required.

• Version 9.11.14
  • Star charts are now automatically calibrated as they are created, so that subsequent measurements of distance are in degrees (if the fieldwidth is at least 4 degrees) or minutes of arc (otherwise).
  • If an accumulator is loaded from file (having been saved from a batch astro process) the image is now automatically scaled linearly into 16 bits per channel and displayed. Previously a curves dialogue was offered but there are a number of problems with doing that on 32 bits per channel (as the accumulator has) so it needs further work before it is reinstated.
  • All configuration properties which are paths to files now automatically get "Browse" buttons in the configuration dialogue.
  • Corrected a minor error in which Ctrl+F5 was shown as the short-cut for 2 options in the image table editing menu.
• Version 9.11.8
  • Further small improvements to star charts:
    • Conventional names (eg, Peg 44 eta) are now shown for stars brighter than magnitude 4. (A little XSLT converted the XML described here to a properties file which is now included in the file GRIP.jar. The Hipparcos ids are used as keys for more common names.)
    • Showing Hipparcos variable stars by red boxes on the chart can now be switched off if required.
    • The epoch is shown in the caption bar of the chart. Precession calculation has been improved.
    • The chart image has 8 bits per channel instead of 16, to remove the irritation of converting if it is required to save the chart image in JPEG format.
    • A cross may optionally be drawn at the centre of the chart.
    • The erroneous Hipparcos data for a number of stars with RA and Dec of 0 are ignored if the chart covers the point (0, 0). The log will show any stars removed from the chart for this reason.
  • New operations on the convolutions menu: Gaussian blurring and unsharp mask. The latter is useful for enhancing detail in nebula photos.
• Version 9.10.29
  • The star chart has been improved in several ways:
    • A local stereographic projection is used for the plot (ie, a tangent plane to the celestial sphere at the centre of the plot). This means that any area can now be plotted, even around the poles, and the scale is the same both horizontally and vertically.
    • Stars indicated as variable in the Hipparcos data are marked with a small red square outline in the plot. (I plan to go on to include more variability information from another catalogue linked to the Tycho data.)
    • The epoch field is now used. RA and Dec at a given epoch for the centre of the plot will be converted to epoch 1991.25 for loading the Hipparcos and Tycho data, to find which stars fit in the plot.
    • Clicking near a star that has both Hipparcos and Tycho identifiers will show both.
    • The default chart size is now 800 x 800 so that it displays initially at 100% scale on most screens.
    • The dialogue now enables the user to change the chart size.
• Version 9.10.22
  • A major new option on GRIP's main file menu creates photo-realistic star charts from Hipparcos and Tycho data. This is aimed towards making more useable finder charts for variable star work. Further details.
  • The options on GRIP's main file menu have been rearranged in descending order of their most likely use, departing slightly from normal conventions.
  • At the end of the astro process the resulting image was shown in the image table as having 8 bits per channel when in reality it has 16 bits per channel. This has been corrected by refreshing the table.
  • Any exceptions occurring when an image is saved are now not only recorded in the log files but also shown to the user in a message dialogue that has to be acknowledged. A common irritating case is when trying to save a 16-bit-per-channel image as JPEG. The message ensures the user notices and can try again after using the levels menu to convert the image to 8 bits per channel.
  • For Java programmers: new package net.grelf.astro contains many new classes to do with star charts, such as RA, Dec, SkyPoint, Star and StarChart.
• Version 9.10.14
  • When a star image has been thresholded and then blobs have been detected (see the levels menu), clicking on or near a detected blob opens a magnified view of that blob in a new window. GRIP has had that facility for a long time. What is new is that the small window thus opened has an extra menu, the blob menu. This menu is geared towards estimating unknown star magnitudes (particularly of variable stars) from known reference stars in the same image (ie, the image in which blobs were detected). There is a new page about how to estimate star magnitudes.
  • I can confirm that the memory leak in the astro-process option of the batch menu was indeed fixed in version 9.10.2. I have processed many sets of 64 or more images without running out of memory and therefore having to restart GRIP.
  • For Java programmers: new classes RA and Dec are aimed towards loading reference star data from internet resources in a version of GRIP yet to be released (soon, I hope).
• Version 9.10.2
  • There is a new feature after blob detection on the levels menu, whereby the measured centre, detected outline and its enclosed area and brightness are shown. By putting the brightnesses into a spreadsheet along with known star magnitudes it would be possible to estimate unknown magnitudes of other objects, such as variable stars. It is intended to develop this further.
  • Brightnesses are now always measured as the square root of the sum of the squares of each of the levels in the different channels (eg, red, green, blue) of the image. This produces a better black line on 1-dimensional profiles, more suitable for spectrum analysis (which is also planned for further development).
  • One dimensional profiles now have their horizontal axes annotated in the currently calibrated units for the sampled image (in pixels if it is uncalibrated).
  • The table of images has a new option on the editing menu, for swapping the order of any 2 selected images. This enables any asymmetrical operation on the combination menu (eg, subtraction or division by a flat field) to be applied the other way round.
  • A few things have been tidied on the final image resulting from the batch astro-process, so that it can be reloaded from file after automatic saving.
  • If you select to show detected blobs on every image in pass 1 of the astro-process and you fail to close those windows, the process itself closes them at the start of pass 2.
  • There was a memory leak in the astro process so that if you tried to process a large set of images after having done another large set, the system could run out of memory. This is believed to have been fixed but only after running a lot of time-consuming examples will this be certain. If in doubt, close GRIP and start it again before processing a second large set of images (more than 30, say).
  • There are often warnings in pass 2 of the astro process about converging lists of matches. The cause is still being investigated but no harm seems to occur.
  • The help files have been simplified, for a much smaller download. Previously the whole site was zipped for the help but that was becoming too big. The XSLT that generates the pages has been modified very slightly so it generates two sets of files: (1) for the whole site, which I upload, (2) the help pages and their images only, zipped for you to download. It means that some links in the help pages now go on-line but all of the explanation of menus can be kept with the application by following the instructions for directory layout on the download page.
• Version 9.9.1
  • The astro-process dialogue has a major new facility: radio buttons to specify the image superimposition method to be used.
    1. Warp - GRIP was designed on the premise that simply shifting images to superimpose them would not be good enough because camera and telescope optics always distort images to some extent. If objects have moved from one frame to the next they will not be distorted in exactly the same way. So recognising objects by their mutual patterns and then warping to superimpose them for noise reduction was GRIP's original method of working. This is still the method unless you deliberately select one of the following.
    2. Shift by average - it has become apparent that there are not always enough stars in a telescopic field for the warping algorithm, which really needs at least 9 objects that are matchable throughout the sequence of images. So this simpler method is offered. It finds the average offsets of all objects from one image to another and simply shifts (ie, translates) an image by that average offset for superimposing it on the accumulating image.
    3. Shift by brightest only - in some images (eg, photos of planets) there is really only one large bright object. For this case, GRIP now also offers the simplest possibility: measure the offset of only the brightest object in every image and stack the images using only those shifts.
  • The astro-process dialogue has been enhanced further to include a Help button, giving direct help about this dialogue.
  • The astro-process dialogue now also has a button for viewing the dark image (if any) to verify that a suitable image has been specified.
  • In working with large single objects it became obvious that blob detection was not working properly. It was fine for small objects like stars but not for larger objects such as images of Jupiter. In fact, anyone trying to use GRIP for measuring automatically thresholded objects in general must have realised it just did not work. Blob detection has therefore been reworked so that it is now fully robust.
  • Using test images containing several objects of equal brightness it was realised that only one such object would be kept for measurement. It would be very unlikely for star images to encounter this problem but more generally it would be wrong. This has also been corrected.
    For programmers: the problem is that java.util.TreeSet will not store multiple objects with the same value of whichever field is used for the comparator for sorting, even though other fields may be different and the objects really are distinct. For this reason, all method parameters of type java.util.TreeSet<BlobMeas> have been changed to a new type BlobMeasList which extends java.util.LinkedList. New objects are inserted into the list in sorted order to avoid having a separate sorting step later; this is more efficient with a LinkedList than with an ArrayList. Similarly, all occurences of java.util.TreeSet<Connection> have been changed to use new class ConnectionList. So the API is not backwards compatible, you will need to refactor as just described.
• Version 9.8.23
  • A new option in the batch astro-processing enables the whole process to run automatically and save the results without any intervention. If this option is selected there is no chance to examine GRIP's matching of objects between images, before pass 2 starts, and you are not asked for confirmation of saving the results. If you are confident that the processing will proceed OK (which I am usually) there is then no need to keep an eye on the lengthy processing.
• Version 9.8.17
  • All of the complicated menus now have an additional option at the end for "Help about this menu", to open the relevant help page directly in the default browser.
  • Bug fixed in which the table of opened images could not be displayed if an image had previously failed to open correctly.
  • Bug fixed in setting the (de-)convolution kernel manually or automatically. It is now possible correctly to sample the image to obtain the kernel, either by positioning a square of given half-width or by pointing to a star and detecting its profile automatically. This is particularly useful for deconvolution because the image of a star should be a point but atmospheric and mechanical effects combine to spread it out to the shape actually captured in the image. Deconvolution attempts to restore that shape to a point, for everything in the image.
• Version 9.7.26
  • Convolutions menu has new non-linear filter operations: nearest extreme and rank. Nearest extreme sets every pixel in the image to whichever is nearest in brightness in the user-selected neighbourhood: the minimum or the maximum. The rank filter replaces each pixel by its order in the neighbourhood, scaled so that the highest possible rank will be the maximum level in the image. Both of these filters treat each colour component independently. They are both useful for enhancing detail, particularly in astronomical photos.
  • The window containing the list of currently opened images is now always created when GRIP starts, rather than having to open it manually from GRIP's file menu. It is from this list that images can be combined in various ways; users may not have realised that if they had not opened the list window. Consequently there is no longer a menu option for closing the image list window. Note that the list window can always be found on the screen by first finding the GRIP window (type Ctrl+G) and then choosing File/List on that window's menu.
  • 2 new options on the Combine menu of the image list window: add/multiply images in proportion (eg, 1/4 of first image to 3/4 of second), with a slider to see the effect as the proportion is varied. These are useful for combining the results of image enhancement with their original images.
• Version 9.7.6
  • In gnomonic projection (and its inverse), the lower limit of lens focal length has been changed from 10mm to 5mm, for experimenting on flattening images taken with fish-eye lenses. I have a 15mm fish-eye lens which, on my full-frame Canon EOS 5D MkII gives a 180 degree view along the diagonals of the frame. That produces more barrel-distortion than Photoshop (CS4) can correct, using either the lens distortion filter or the (de-)spherizing filter. But in GRIP, using the inverse gnomonic projection on the Geometry menu and setting 8mm as the lens focal length, I found I could flatten the image. 8mm makes sense because that would be the focal length for the other type of fish-eye lens, that creates a circular view inside the 36x24mm detector frame. GRIP creates a very large resulting image because, unlike Photoshop, it does not crop the results of its filters but makes room to see everything. A consequence was that in 2 Gbytes of RAM I ran out of memory when I tried to save the image on disc, unless I first scaled it down or cropped it. But overall, the process does work - I can use GRIP to flatten images taken with my fish-eye lens. That can be genuinely useful for architectural images where I want to get the maximum possible width of field. Here is a flavour of what can be done:
    Before:
    After:
• Version 9.5.4
  • Major bug fixed in the batch astro process: star detection was not happening if background correction or gnomonic projection were selected.
  • If the batch astro process does not manage to match stars across the images then you now have the option to display a drawing that shows what was detected in each processed image.
  • When performing the batch operation of averaging images, if the first image loaded is raw the user is asked whether to average the images as uninterpreted raw. Previously each was interpreted and then added into the accumulator for averaging.
  • New option on the batch menu: Interpret raw & save as TIFF.
• Version 8.6.28
  • There are two new options on the measurement menu: 2D profile and 3D histogram. The first takes the profile of the whole image and plots it as 3 isometric views, one for each colour channel - you will first need to crop the image to a small enough rectangle (it is intended to make this easier in a later version, selecting a rectangle with the mouse). The second option takes the histogram of the whole image and plots it as 3 graphs - a draughtsman's projection (3rd angle?) of the RGB cube, with frequency plotted on a colour scale that is shown.
  • A new option on the image table/combine menu creates red/green stereo images from a pair of selected images. The selected images must be of the same size and type (number of channels and bits per channel). The resulting image has a monochrome version of the first image in its red channel, a monochrome version of the second image in its green channel and zero in its blue channel. Viewing it through red/green spectacles creates the stereo effect if the original images were of the same scene but the camera moved a few inches horizontally between exposures. It was possible to do this previously in GRIP through a multi-step process but this new option makes it very quick and easy. Cardboard spectacles with a red filter for one eye and a green one for the other are available for a few pence if you search on-line.
  • Options on the levels menu now either work correctly for a monochrome image or display a message saying that the particular operation is not possible on a monochrome image.
  • A small enhancement to Exif.java makes the loading of JPEG images more robust. Some applications seem to save such files with incorrect metadata structures. GRIP now ignores such inconsistencies rather than failing to open the image.
• Version 8.6.11
  • Measurements, including histograms, now work for monochrome images as well as for RGB ones.
  • The curves dialogue now works for monochrome images too.
  • The dialogue for starting the astro process (from the batch menu) has been improved in layout and useability.
  • If the astro process settings require temporary images to be created between passes, a check on available disc space is now done (thanks to new features in Java 6) and a prompt gives time for releasing space if necessary.
• Version 8.2.7
  • The two astro-process options on the batch menu now start with a dialogue for setting various aspects of the process. The dialogue is simply initialised slightly differently for the two options. It is now possible to use any combination of dark and flat fields, histogram background correction and gnomonic projection during the process.
  • The detection of defective pixels and their use in correcting RAW images has been improved. More description is available here.
  • The downloads page now makes available the updated JAR file for GRIP by itself, for those who have already downloaded the full application before. This means a much smaller download for updates (260 kb instead of 1.6 Mb). A diagram is also provided now, to show the required directory structure for running GRIP.
• Version 8.1.21
  • The telescope version of the astro-process on the batch menu now makes use of a flat field image if one is available.
  • The operation of dividing by a flat field image is also available on the image table menu (in the window listing all open images). This enables the action of a flat field image on a single image to be studied, to verify that the flat field image is suitable and that GRIP applies it correctly. (One simple check of GRIP is to clone an image and divide it by the clone, which should produce a completely uniform result.) For more information about the meaning and purpose of a flat field image, see here.
  • The source code for the BatchProcessor class is now available in the downloadable source code, so you can verify its behaviour. Please contact me (graham dot relf at fsmail dot net) if you spot an error or if you can see useful additions I could make.
• Version 8.1.20
  • The astro-process on the batch menu has been improved and split into two options, one for images taken through a camera lens and one for images taken through a telescope without a camera lens. The difference is explained here. Expect further enhancements, to make use of flat field images in telescopic work.
• Version 8.1.13
  • The size (width and height in pixels) of the cells for correcting background levels is now a configurable property. Previously the width and height were always set by dividing the width and height of the image by 16. The cells were not necessarily square, which they are now. The reason for making this configuarable is that very bright objects in a cell can distort the background if the cell size is too small. Likewise large specks of dust on the camera detector causing dark areas can distort the background level. In such cases choose a larger cell size.
  • A bug has been fixed in which cropping a set of images by a batch process failed because the list of files was lost.
• Version 7.11.25
  • The end of the batch astro-process has been improved:
    • The images are now warped onto the middle one in the sequence rather than the first, to give a more symmetrical pattern of overlaps.
    • At the end of pass 2, instead of rather clumsily asking for a list of match trail numbers, the user is invited to draw rectangles intersecting those trails which are to be deleted. Then closing the frame displaying the match diagram causes the process to continue to pass 3.
    • At the end of pass 3 a curves dialogue is displayed so that the read-out from the 32-bits-per-channel image accumulator back into a normal image can be transformed through a look-up curve. This is to enable contrast to be increased and fainter features to be enhanced. Typically a low-value gamma curve would be suitable here. For programmers this means that ImCurveDialogue can now generally transform from either a java.awt.image.BufferedImage or an Accumulator into a BufferedImage.
    • There is no longer a white frame drawn around each image before warping. This is because it could adversely affect the calculation of dynamic range for scaling the accumulated result. Unfortunately the lack of white frames does make it harder to tell where the edge of all the image overlaps falls in the result. Does anyone have a better idea?
  • A new option appears on the levels menu for a RAW image, to automatically detect defective pixels and save a list of them as a CSV file. This option is intended to work on dark-frame images, ie, those captured with the camera lens cap on. NB: THIS OPTION IS STILL EXPERIMENTAL - IT MAY ONLY WORK FOR A CERTAIN RANGE OF EXPOSURE TIMES.
  • A new option on the configuration menu enables a list of defective pixel positions to be loaded from a CSV file. If such a list exists in the configuration, interpreting a RAW image (an option on the levels menu) now takes them into account. This is done by first replacing each of them by the average of its 4 nearest neighbours of the same colour. Bayer interpolation takes place after that step.
  • A less serious (alright, fancy graphics) option has been added to the image menu, to generate a Mandelbrot curve and allow the user to zoom into it repeatedly. For programmers this is in class ImGraphic. It is intended in a future version to add a pseudocolour capability for monochrome images which will make these images even prettier. Meanwhile try splitting channels (levels menu), changing them independently, and recombining (image table menu).
  • A minor bug has been fixed in which nothing happened if no file extension was given for the file name when saving an image in a file. If GRIP did not know what type of image to save it ignored the request but gave no warning that nothing had been saved.
  • A very minor bug has been fixed in which the zoom factor was reported wrongly in the caption of an image frame after saving the image in a file.
  • New class BatchProcessor has been split off from BatchMenu.
  • General refactoring has been done, mainly to simplify menu classes and to make the actions for nearly all menu options available as callable methods in the API.
• Version 7.8.8
  • Two new options (which I needed for a particular photographic project) have been added to the batch menu: Square (multiply by self), for enhancing contrast, and Saturate.
  • Similarly, two new operations are available for making your own multi-step batch process: Square and Saturate.
  • A small bug has been fixed in the dialogue for making your own batch process: a NullPointerException is no longer thrown if the button for adding a step is pressed but then the selection is cancelled.
  • A more serious bug has been fixed in which rectangles drawn for cropping or measuring had to start at top left and be dragged out rightwards and downwards. Not everyone wants to do it that way, so now alternative approaches also work.
  • The calculation of scale and position for newly opened images has been improved so that it looks neater and there is less likely to be an immediate need to zoom or reposition the images.
  • Reading metadata from files has been improved so there is now more likelihood of extracting camera details to include in measurements (eg, if you want to plot a graph against time).
• Version 7.7.4
  • Corrected a very minor problem in which the right- and bottom-most pixels of any image were displayed as black.
  • Added option to the file menu of the image window, for putting a border around the image in any colour. That increases the size of the image by the width of the border on all sides.
• Version 7.5.16
  • GRIP now attempts to read EXIF (ie, camera manufacturer's) metadata from images if the JAI plug-in does not manage to read any when opening an image. This seems to work for JPEG files direct from a camera but may not work for JPEG files which have been saved by an image processing application. Such applications should resave metadata in a non-EXIF format but they do not all agree.
  • Combining images via the image table menu now changes the caption and the history list of the image which contains the result, to make it easier to see which one it is.
• Version 7.5.13
  • The option for opening an image from the main menu has been improved so that several images may be selected at once and opened.
  • A new option on the image levels menu, Average vertically, is for use before measuring profiles along straight lines. This is particularly for spectroscopy. A page about this is planned.
  • A minor bug has been corrected: when opting to rotate or scale an image and then cancelling the dialogue which asks for the angle or factor, the operation is cancelled without throwing an exception.
  • For programmers, new class Timer provides a simple way of logging how long any process takes to run.
• Version 7.4.19
  • The astro process has been improved. After pass 2 it is possible to remove objects from the matching interactively to improve the result. The default value for the number of brightest stars to consider has been increased in the configuration menu from 16 to 24, which seems to spread control points across typical star images better.
• Version 7.4.10
  • A new option on the Measurement menu makes it possible to copy calibration between images, which is appropriate only if the objects being measured were at the same distance from the camera for both images and the same focal length was used.
  • More operations have been made available in the dialogue for making your own batch process.
• Version 7.4.3
  • In certain circumstances it was not possible to save an image in JPEG or TIFF formats. This has been fixed.
• Version 7.3.31
  • A new option on the geometry menu enables an image to be translated by any amount in x and y. Translating by a pixel or two and then subtracting the original image is a way of detecting edges in the direction of the offset. It is then possible to make line drawings from photos by going on to threshold the edge image, then zeroing the image itself (eg, by using the curves option in the levels menu), drawing the overlay into the image, converting to monochrome, inverting and auto-stretching the result. An example of this has been added to the documentation for the geometry menu.
  • The curves dialogue available from the levels menu of each image now has a drop-down for setting some standard curve shapes, including gamma correction curves for user-supplied values of gamma. The V-shaped curve can be used to change subtracted images into absolute-subtracted images (differences all converted to absolute values so the background level can be 0 instead of half-way up the range).
  • Thresholding, also available from the levels menu, now has 3 separate sliders for red, green and blue channels. Thresholding can now be applied in either of two ways: AND-ing the tests on each channel (every channel must be at or above the threshold level) or OR-ing them (any channel may be at or above threshold).
  • Colour balance adjustment is a new option on the levels menu. Each channel can be increased or decreased by a user-selected percentage. Beware when increasing a channel if it already goes up to the maximum level - you will get flattened highlights in that channel.
  • Viewing the kernel on the convolutions menu as an image now provides a menu in the frame, so the kernel image may be manipulated or saved as an image file. Any processing done in this view window will not affect the current kernel however.
  • There was a bug in cloning from the image menu because the file path from which the image had been loaded was not copied to the new frame. Using the reload option on the image menu of the cloned frame would not work. This has been fixed.
  • The batch menu has a new option "Make your own process" but it is not yet complete.
• Version 7.3.25
  • The operations on the convolutions menu have been tested more thoroughly and improved. In particular, deconvolution is now known to work. Try enhancing your blurred photos!
  • The convolutions menu is now explained in these pages.
  • A new option on the geometry menu enables the unused margin of a RAW image to be cropped off. To support this the configuration dialogue has new rows for you to enter the margin values for your particular camera. The margin values may be in your camera's user guide or you can work them out by loading a RAW image and a JPEG image and comparing their sizes from the information option on the image menu.