What's new in GRIP
(To see what GRIP is about, first see Introduction to GRIP.)
Note that the version number of GRIP is the date on which it was released on this site. Eg, 12.2.29 is 2012 February 29th.
-
Version 18.3.3
- LRGB images. This will be of interest to astrophotographers using filters in front of monochrome cameras. There is a new option on the levels menu which is enabled when the image is monochrome: "Convert to RGB". All 3 channels of the resulting image will be identical to the original monochrome image. The purpose of this is to prepare a luminosity (L) image to be combined easily with an RGB image by using the Add proportion option on the combine menu. (Previously the workaround was to open the L image 3 times and combine all 3 copies to RGB.)
-
Version 18.1.24
- A new button on the profile display dialogue enables the x-axis of the graph to be stretched by an integer factor. This was requested by someone wanting to extract subtle detail from small planetary images.
-
Version 17.6.20
- New variable in the main file, GRIP.java, enables me to make different versions to include or exclude experimental code.
-
Version 16.10.8
- Split stars (on the segmentation menu) did not display its result correctly. This has been fixed.
- For programmers: there has been considerable refactoring of the batch processor to improve its structure, particularly making methods smaller. New enum BatchAction replaces the way in which actions were previously named by strings.
-
Version 16.1.29
- There is a new option in stacking comet images, to save each shifted image in a new file. This makes it possible subsequently to process the shifted images again, perhaps to do median processing which might remove star trails to leave only the comet.
- A small bug fix: a recent internal change to improve the accuracy of image rotation by multiples of 90 degrees* resulted in the rotated images not being displayed correctly if they had more than 16 bits per channel. The rotated image was correct, as could be proved by processing it further, but the display was wrong (for programmers: the range of values was not set in the resulting image).
* The change simplified the rotation in such cases by moving whole pixels rather than by using the general rotation algorithm involving trigonometry and pixel interpolation. - At the end of comet stacking the combined image could not be saved automatically because an impossible file path was constructed. This has been fixed. The fix includes checking whether the user ended the result path with a separator character (forward or backward slash depending on O/S) and adding one if necessary.
- Oops! Recent zip files for downloading have not contained the .bat files for running the program. This is now fixed (2015 Nov 20). Thanks to Mike in Michigan for pointing this out to me.
-
Version 15.11.17
-
Meteor detector. A new option on the Batch/Astro menu is "Find meteors". This scans a set of images looking for linear features brighter than the background. Whenever one is found a magnified view of it is shown in a pop-up window. The window is labelled with the image file name and the pixel location of the feature within the image. The scanning does not pause, so at the end there could be a series of windows open for review. Also at the end a further window contains a comma-separated tabulation of the results, including some measurements made on each detected feature.
This new facility has been tested on a few of my own Perseid images and works well. However it does need testing on more images. There are some adjustable parameters that may need tuning for different types of exposures. - For programmers: the methods in class net.grelf.grip.StarSegmenter have had their parameter lists changed slightly to make it optional whether erosion and dilation is done after segmentation.
-
Meteor detector. A new option on the Batch/Astro menu is "Find meteors". This scans a set of images looking for linear features brighter than the background. Whenever one is found a magnified view of it is shown in a pop-up window. The window is labelled with the image file name and the pixel location of the feature within the image. The scanning does not pause, so at the end there could be a series of windows open for review. Also at the end a further window contains a comma-separated tabulation of the results, including some measurements made on each detected feature.
-
Version 15.11.07
- The change in the batch astro dialogue to make simple and advanced versions caused a problem. In the advanced version, if many files have been selected the dialogue goes off the bottom of the screen and cannot be used. This has been fixed.
-
Version 15.10.30
- Selectable target directory for stacking. The batch astro dialogue has a new input field for changing the directory (folder) in which the resulting stacked image should be saved. Any temporary files will also be put there during the process. This overcomes a problem reported by some users if the drive (or more likely memory card) containing the images to be stacked has little or no spare capacity, because previously the result and temporary files went in the same directory as the source files.
- The batch astro dialogue has been simplified. Many of the options available are rarely needed in practice and so they have been set only to appear if the new "Advanced" button is clicked.
- Fixed bug in which the result was not displayed correctly after the manual alignment process introduced in the previous version, if the images being matched had 32 or 64 bits per channel.
-
Version 15.6.23
-
Accurate manual superimposition of images. There is a new process for manually aligning an image to another one. The alignment is not done simply by shifting, scaling and rotating. Like the batch/astro/combine process in GRIP this new process does a rubber-sheet style warping of the second image to match the first. It uses 9 control point pairs between the images. The novel aspect of this new facility is that magnified (100%) views of 9 regions of each image are displayed simultaneously so that the control points can be adjusted alongside each other, by mouse clicks and dragging, to single pixel accuracy.
First open and select the two images in the image table. The required menu option is then enabled: Combine/Adjust control points and warp. A more detailed explanation is displayed in a separate window at the start of the process. - For programmers: new package net.grelf.malign contains the classes providing this new manual alignment facility.
-
Accurate manual superimposition of images. There is a new process for manually aligning an image to another one. The alignment is not done simply by shifting, scaling and rotating. Like the batch/astro/combine process in GRIP this new process does a rubber-sheet style warping of the second image to match the first. It uses 9 control point pairs between the images. The novel aspect of this new facility is that magnified (100%) views of 9 regions of each image are displayed simultaneously so that the control points can be adjusted alongside each other, by mouse clicks and dragging, to single pixel accuracy.
-
Version 15.6.10
- More measurements are displayed for each blob when clicked upon after segmentation.
- A new pair of histograms is available from the segmentation menu after segmenting. These show width / height ratios and circularities. Circularity is defined as radius derived from perimeter divided by radius derived from area (by simple geometry).
- A new option in the image table's "Combine" menu is for pairs of images. "Keep pixels which differ from 2nd image" first asks for an integer threshold value. It then processes the first image and zeroes all pixels which have the same value (within plus or minus the threshold range) in all channels in the second image. This can sometimes enable objects to be separated from an unchanging background even when that background is complicated.
- A major bug has been fixed in the thresholding option on the segmentation menu. The range sliders for this operation cannot have been working for many past versions but no-one has reported it.
- For programmers:
- HistogramBlobs has become an abstract class with 2 concrete extensions: HistogramBlobArea (formerly HistogramBlobs) and HistogramBlobShape (a new class).
- Image interface has new method: saturate (amount). It is implemented for all images in the abstract superclass ImageBase.
- Image interface also has new method keepOnlyDifferingPixels (), implemented in each Imagexx class. A method of the same name also appears in the ImFrame class. These are supported by new methods called pixelsDiffer () in the class ImageBase.
- Version 15.4.14
-
Version 15.1.17
- There is a small change in the batch processor for the option "Astro warp/shift onto common basis", where images are aligned as if going to stack but saved individually in new files as warped/shifted images. Previously the saved files would have been in TIFF format unless the input images had 8 bits per channel in which case JPEG would have been used. Now the logic determining the extension is that TIFF will always be used unless the input images are deeper than 16 bits per channel (unlikely), in which case FITS is the format.
-
Version 14.10.18
- The menu bar on each image now has a menu headed "Segmentation". This was previously a sub-menu of the levels menu but that was getting too many options. There is no change to the functionality but short-cut (Alt) keys have been reassigned among the options.
Segmentation is the process of detecting pixels of interest within an image, such as stars. Each connected group of such pixels is termed a "blob" in this software. - The slide show (on the batch menu) can now be driven by a script containing a list of image file names or paths, one per line. The script may also contain lines beginning with upper case keywords:
PATH filePath // sets a prefix which will be applied to all subsequent file names
OPEN filePath // opens a normal GRIP window containing the image from the file
PAUSE // causes the slide show to start in paused mode: user steps through.
RESUME // resumes automatic stepping.
In the OPEN case the slide show pauses until the window is closed again. This enables functionality in GRIP to be demonstrated during a slide show. (There may be issues with keyboard focus - still working on that.) - Keys active during the slide show now include PgDn/PgUp to move forwards/backwards (alternatives for the arrow keys) and Esc to end the show (rather than "any other key" as previously). Esc also asks for confirmation.
- The slide show can now display any images that GRIP can open, including FITS files deeper than 16 bits per channel.
- If any image cannot be loaded the slide show will continue with the next step, rather than dropping out (in programming terms, any exception is caught within the loop).
- The menu bar on each image now has a menu headed "Experiment". Here we group several options that were previously scattered across other menus, where new ideas are being tried out. End users can ignore this menu.
- Interpolation between pixels where required (eg, when rotating an image) has been made slightly more efficient. A small consequence for programmers is that the method
net.grelf.Interpolator.getPixel() is no longer static: an Interpolator must be constructed before looping through an image. This enables a zero pixel having the same number of channels as the image to be constructed just once rather than every time it is needed.
- The menu bar on each image now has a menu headed "Segmentation". This was previously a sub-menu of the levels menu but that was getting too many options. There is no change to the functionality but short-cut (Alt) keys have been reassigned among the options.
-
Version 14.9.22
- The last change (14.9.19) was not complete: the option "Batch/Astro/Astro warp/shift onto common basis" could not save the warped images if the extension of the source files was .fit. It also did not work for source files ending with .fts (allowed since version 13.12.4) but no-one had noticed and reported that.
-
Version 14.9.19
- A very minor change, to allow FITS files to be loaded if they have the extension .fit - previously it had to be either .fits or .fts but now all 3 are possible.
Thanks to Glenn in Australia for pointing out that Maxim DL saves FITS files with the extension .fit so this change avoids him having to rename them.
- A very minor change, to allow FITS files to be loaded if they have the extension .fit - previously it had to be either .fits or .fts but now all 3 are possible.
-
Version 13.12.30
- A simpler, faster and yet more effective algorithm is now used for stacking star trail images. (For programmers: this is in class net.grelf.sequence.Maximiser.)
- A keyboard short-cut, Ctrl-E, is now provided for the auto-segmentation of stars, on the levels menu, because this is frequently useful.
- On clicking on a segmented star, the blob dialogue opens to show a magnified view of the star. This dialogue has been considerably improved. Operations that were options on the blobs menu have become buttons in the dialogue, for ease of use. It is intended that the blobs menu will be phased out before long. The following are among the improvements in this area.
- It is no longer necessary to remember to give a detected star an identifier before it can be measured (photometry or astrometry). Instead a prompt appears.
- It is no longer the case that all detected stars which have identifiers but no magnitude (photometry) or position (astrometry) will be measured when the relevant button is pressed. Just the currently selected star will be measured against the known reference stars.
- Measured positions (RA and Dec) are now displayed with error limits.
-
Version 13.12.16
- Two major new features are available from the batch/astro menu:
- "Animate at 100% scale" helps when looking for faint comets or asteroids. By running through a sequence of aligned images you may be able to see the object moving against the stars. Before starting this option you need either to have used the option "Astro warp/shift onto common basis", so you have a set of image files that have already been aligned, or to have warp/shifted to make one combined image and also to have saved a CSV file with the drive error data. An unaligned set of images can use the CSV file to do the aligning while loading for animation.
The animation is at 100% scale so you start by seeing only the top left portion of each image. During the animation the following keys are recognised.
- Arrow keys move the display to adjacent portions of the image sequence.
- The space bar pauses and resumes the animation.
- S saves the currently viewed image portion as a sequence of JPEG files in the directory from which the images were loaded. You may then use some other application to make a video.
- "Create median pixels image" makes a new image in which each pixel value is the median of the values of that pixel throughout the image sequence. This can be better than averaging for reducing noise. It is also useful for non-astronomical photos: if you have taken a number of shots (with camera fixed) of a scene with objects moving about (people, for example), the medianising will remove those objects.
This process does require an aligned set of images, either from a fixed camera or by using one of the other options on the batch menu first.
This option can process more images than will fit into memory at once. However, if the full images will not fit they will be processed in multiple passes by dividing the images up into horizontal slices. It is all done automatically and the log (console) display shows how it is progressing. It can be a very lengthy process, depending on the amount of memory in your machine.
- "Animate at 100% scale" helps when looking for faint comets or asteroids. By running through a sequence of aligned images you may be able to see the object moving against the stars. Before starting this option you need either to have used the option "Astro warp/shift onto common basis", so you have a set of image files that have already been aligned, or to have warp/shifted to make one combined image and also to have saved a CSV file with the drive error data. An unaligned set of images can use the CSV file to do the aligning while loading for animation.
- A bug in the geometry option "Fit images in m x n" has been fixed.
- For programmers:
- net.grelf.Maths has new methods for finding the median value of an int or double array. For now it simply sorts the array and retrieves the median entry but it is intended to substitute a more efficient algorithm. It is not time-critical as far as the above medianising operation is concerned, where the bulk of the time is taken up by loading images from disc.
- New package net.grelf.sequence contains Animator and Medianiser to provide the new features described above. These classes may also be run as stand-alone applications. All the user interaction is built in.
- The new package also contains Reformatter (formerly net.grelf.grip.BatchReformatter) and SlideShow (moved from net.grelf.grip).
- Two major new features are available from the batch/astro menu:
-
Version 13.12.4
- FITS files having the extension .fts are now recognised as well as those having names ending with .fits.
- In the batch process for stacking comet images an error message occurred after stacking if some images were skipped by the user. This prevented the data file listing offsets from being created. This bug is now fixed.
- A more major bug has been fixed in the batch astro process for warping/shifting images to a common basis and resaving them. The unmodified images were being saved instead of the modified ones! Many thanks to Leif in Sweden for pointing this out so I could fix it.
-
Version 13.4.26
- A new button has been added to each frame in the batch astro-process for comets (/asteroids): Point manually. This is for cases where the object of interest is too faint or diffuse for the automatic star segmenter to detect it. The user can instead point to the object directly with the mouse. It is possible to zoom in for accurate pointing. This was used successfully for a stack of 61 images of 273P/Pons-Gambart and the result is shown here.
- An experimental option has been added to the dialogue for starting the batch astro-process for comets. This converts each frame to intensity/colour before using the intensity part for segmentation. This may sometimes help to automate difficult cases of the kind described in the item above.
-
Version 13.2.3
- Bug in batch averaging fixed.
- Bug in recombining channels (causing a flickering loop) fixed.
- New option on the main GRIP file menu makes a gradient strip image to help with monitor bightness and contrast adjustment.
-
Version 13.1.22
- GRIP now requires JRE (Java Run-time Environment) version 7. Download it from www.java.com and follow the simple installation instructions there. It is quick and easy to do.
- The curves dialogue (Ctrl-M) now works correctly with monochrome images, not just RGB.
- Fourier Transforms. I had always assumed that these would be too slow to be of use in GRIP. Then a few months ago I tried coding an in-place Cooley-Tukey FFT (butterfly) algorithm. I found that a 2048 x 2048 3-channel (RGB) image was tranformed in less than 3 seconds on my laptop (an Acer 4830T using Intel Core i5), even without trying to use parallel threads. That involves over 12,000 1-dimensional transforms. So I was amazed, and realised that it could be used to speed up many useful things, such as wide-radius Gaussian blurring (for background correction and for unsharp masking) and deconvolution. I have now implemented those. They automatically convert the image to 64 bits per channel (floating point). The convolution menu has the forward FFT which produces two images: the real part and the imaginary part (identified as such in their metadata). The image table menu has the inverse FFT, when a real and imaginary part have been selected. The image table menu also has new options for displaying the complex image logarithmically, so the detail in the frequency domain is visible. Related to this, a new option on the geometry menu swaps the 4 quadrants of an image (if you know about Fourier transforms that should make sense).
- FFT requires the image width and height to be powers of 2. So the geometry menu has 2 new options: Crop to nearest powers of 2 and Expand to nearest powers of 2. The latter simply puts a black border (level 0 in all channels) around the image.
- Sometimes you don't want to crop or expand the image, so (de-)convolutions give the user the option of either using the new fast methods or the old simple methods. The new methods do require much more memory, for the complex 64-bit images.
- Another consequence of all this is that images can end up quite correctly having negative values for pixels. So histogram, profiling and tone-curve algorithms have had to be rewritten. Hence the lengthy retesting process which delayed release of this new version.
- The labelling of histogram axes has been improved, allowing for the wider range of possible values.
- A minor but persistent niggle has been improved: Java's file browsing dialogue (JFileChooser) does not give programmatic access to the text input field for the file name, to immediately change file extensions according to the user's choice of filter from the drop-down list. However, GRIP does now apply an appropriate extension after selection, so it is no longer necessary to remember to type the extension.
- A small change in the levels menu allows direct conversion from any bit depth (8, 16, 32 or 64) to any other, without having to go one step at a time.
- 32-bit images can now be saved in TIFF format. BUT this is the 32-bit floating point format as used by Photoshop and so is only for conveying images to that application. It has very limited use because it really only has a resolution of 23 bits per channel (after allowing for exponents and signs). GRIP cannot reopen such files (there seems to be no point).
- The batch processor is now able to accept input files deeper than 16 bits per channel for all operations. This enables combining several stacked results. If the batch processor has to save temporary files between passes they are now saved in FITS format (allowing any bit depth) rather than TIFF. (For programmers: this has involved changes in methods of the Accumulator and Warp classes to accept any object that implements Image rather than merely Image8or16).
- There was a bug in the batch processor when simply averaging a number of images. The result could sometimes be totally black. This has been fixed.
- A minor error in the saving of FITS files has been corrected. The problem was that calculation of the number of padding bytes at the very end of the data could have been wrong in some circumstances, so that very strict FITS readers would then refuse to read the files.
- A problem has been fixed in which applying a look-up curve to images containing a very large range of levels would run out of memory.
- The size labelling of the interactive rectangle for cropping was sometimes off by a few pixels due to the scaling down for display. This has been fixed.
- For programmers: the FFT has introduced a new interface ComplexImage and implementation ComplexImage64 in package net.grelf.image. This interface and class provide the FFT, inverse FFT and related methods.
- For programmers of astronomical applications: new class net.grelf.astro.Topocentre provides capabilities for converting from geocentric to topocentric coordinates. Some UK locations are predefined as constants in the class.
-
Version 12.6.24
- 32 bit RGB or monochrome images may now be saved as TIFF files that Photoshop can open.
NB:(1) Be aware that Photoshop's interpretation of 32-bit is floating point, which means there are only 23 bits for the mantissas. If you have stacked more than 128 images in GRIP you will therefore lose some information by doing this. FITS is still still the preferred format because GRIP saves the full 32-bit integer data in that format.
(2) I have not been able to persuade Photoshop (I have CS4) to recognise the ICC profiles that I have included in the files, using the ICC private TIFF tag standard. I think Adobe must be relying on non-TIFF-standard metadata (eg, XMP) in their files for recognising profiles. I have included some XMP but that has not worked so far. The images are OK in Photoshop as long as you bear in mind the 23-bit limitation. You will get a dialogue in Photoshop about assigning a profile. Simply accept the most linear option. - Signal to noise ratios (in the detected star/blob frames) are now measured more accurately using the photometric guard regions.
- There was an unfortunate bug in batch/average images, which resulted in non-16-bit images becoming black. This has been fixed. Image accumulation was not affected by the bug, so that provided a work-around.
- 32 bit RGB or monochrome images may now be saved as TIFF files that Photoshop can open.
-
Version 12.5.25
- Split Intensity is now available for all image depths. This is where an RGB image is split into two, one containing the intensity information and the other containing the colour, so they can be worked on separately and then recombined via the image table menu. Otherwise colour tends to become desaturated during image processing.
- Combining comet/asteroid images (to keep the objects fixed while stars trail past) has been improved in several ways. The comet image frame now has a panel with explicit buttons for processing or skipping each frame, or for cancelling the whole process. The process also now launches from the usual astro process dialogue so that dark and flat frames (etc) can be applied to each frame automatically during the process.
- Brightness scaling has been added to the levels menu. This is mainly aimed at HDR (High Dynamic Range) applications using 32-bits-per-channel accumulator images, so that an accumulated set of short exposures can be shifted up in brightness to be added to another accumulated set of longer exposures. (Eg, for photos of the Orion Nebula, M42, where longer exposures burn out the trapezium area, so it is necessary to add in a set of shorter exposures.)
- The pixel replication factor is now shown in the caption bar of magnified frames, to aid interpretation of measurements.
- The magnified display of detected blobs/stars now indicates automatically if the object has saturated in all channels. This is done both by superimposing green dots on saturated pixels in the magnified image and also in words in the control panel to the right of the image.
- Measurement display windows (1D profile, histogram) can now also be closed by the normal close button in the top right corner of the frame. (Fixing a minor irritation.)
- More grid lines are now drawn in the background of 1D profile graphs, to make it easier to make estimated readings.
- In the 1D profile graphs for RGB images the green profile is now plotted last, so it is on top of black, red and blue.
- Image display in pseudocolour has been reinstated, in the Image menu. This only affects the display, not the image, and it can be switched off again. Pseudocolour can be useful for bringing out detail in regions of small contrast, particularly when looking for faint objects (comets, nebulae). It is now also possible to apply the pseudocolour table permanently to the image itself, via the Levels menu, if so desired (we have no immediate application for this, but someone may have).
- The configuration menu now includes some equipment details for inclusion in image metadata. It is intended to do more work in this area.
-
Version 12.4.3
- New batch process: magnify. This replicates pixels, unlike scale which interpolates them. I needed this for a presentation, to make camera pixels visible in a movie showing how a star image is affected by atmospheric turbulence.
- New blob measurement graph: radius v integrated brightness
- New segmentation submenu of levels menu, to make the main levels menu shorter.
- New levels option: draw regions. Can be used for making a mask image.
- New levels option: draw overlay into new image (which may then be saved as a mask).
- Measurement menu: Draw overlay into image now creates a new image instead of replacing the original one.
- Draw overlay into new image (levels or measurement menus) now asks whether the new image should be monochrome.
- A FITS image (usually 32 bits per channel) is now saved automatically at the end of the batch comet process and also at the end of batch (non-astro) accumulate and star trail processes. Previously the user had to remember to do it before any further processing.
- Setting a crop rectangle: the text showing the size while dragging now takes the display scale into account.
- For programmers: new class BatchMetadata collects metadata during batch processes for use in the result image and in ImageSummaryDialogue.
- The batch comet processor now adds metadata to the result image.
- New buttons in the blob frame (magnified display when clicked on a detected blob/star): Profile in x, Profile in y and Close window.The profiles are along the horizontal and vertical centre lines drawn automatically over the magnified object.
- For programmers: there was possible confusion among add (Image, x, y) methods of implementations of Image. The methods have been renamed addProportion() and addTranslated().
- Fixed bug in batch aligning to common basis, which was causing null pointer exceptions in pass 2.
- A dummy Undo (Ctrl-Z) option has been added to the Image menu to explain why there is no Undo, for those who don't read manuals.
- Gaussian blur (on the convolutions menu) now runs to the edges of the image, making it more suitable for subtraction from the original (like an unsharp mask). For mathematicians: this simply assumes that the edge values extend outwards as far as required, rather than assuming a periodic image.
-
Version 12.3.16
- There is a new option on the Levels menu: Equalise histogram. Although this is too extreme as part of the processing to make a final image it is quite useful for showing quickly whether there are any faint objects present, just above background.
- Some general improvements have been made to the batch processing. In particular, if one image should fail it should no longer prevent the remainder of the set from being processed.
-
Version 12.2.29
- An important bug has been fixed, that was making star charts useless. The bug had been in the last few versions. The problem was caused by the Epoch field in the dialogue for creating a star chart. There was no indication of what to enter in the field or how it would be interpreted - Julian Day or a year? Unfortunately the validation of the field only allowed years (eg, 2012.0) but the result was interpreted by the code as a JD. So 2012.0 was treated as 2012 days after 0JD - thousands of years BC! Proper motion is significant over thousands of years so the charts were completely wrong. How did I fail to pick this up in testing? Because I stupidly used a star cluster (the Pleiades) for my test chart. It looked right but of course that is because the proper motions of stars in a cluster are all similar. Doh! Anyway it is correct in this new version. The Epoch field starts with 2012.0 in it, as an example of what is expected.
- Metadata fields for the FITS format can now be edited by the user - with care!
- In certain circumstances the image translation operation was producing a completely black image. This has been fixed. Amazingly that is all I have found wrong due to my major refactoring for the previous version.
- For programmers: there are some useful new methods in Angle and its subclasses, allowing more flexible input of values in single text fields. See Angle.parseAngle(), RA.parseRA() and Dec.parseDec(). In due course dialogues in GRIP will be improved to make use of these. Users will then be able to enter angle values in any reasonable format without fussy tabbing between sub-fields.
-
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.
- 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.
-
Version 11.2.18
- The order of events has changed slightly at the end of the batch process for combining into 1 image:
- Optionally save the accumulator in a .accum file.
- The accumulator is scaled linearly into a 16-bits-per-channel image which is displayed.
- Optionally save the 16-bit image in a .tif file.
- 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.
- 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
- 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.
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.
- The order of events has changed slightly at the end of the batch process for combining into 1 image:
-
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
or in 64-bit systems like this:
start java -Xms768m -Xmx1024m -Dit.tidalwave.imageio.raw.defaultSource=rawImage net.grelf.grip.GRIPset 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.
- 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:
-
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.
- 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.
-
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 ().
- 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.
-
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.
- 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!
-
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.
- Further small improvements to star charts:
-
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.
- The star chart has been improved in several ways:
-
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.
- 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.
- 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.
- 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.
- The astro-process dialogue has a major new facility: radio buttons to specify the image superimposition method to be used.
-
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:
- 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:
-
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.
- The end of the batch astro-process has been improved:
-
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.