Tags:
create new tag
view all tags

Coronal Loop Deployment

Science Testing Document

Input

  • The algorithm takes as its input a 2-D FITS image file, for example AIA, TRACE or EIT. Image data in all 5 standard FITS datatypes (byte, short, long, float and double) are accepted and images may be any size (subject to memory restrictions). The input FITS file remains unmodified by the algorithm during processing.

    An example of a Coronal Loop FITS input file is shown here: 1t051998.fits

Compilation and Execution:

A makefile (Makefile) is provided in the installation package to simplify building of the algorithm. Running 'make' creates an executable called LoopRecog (and a shared library called libLoopRec.so for IDL support). Please refer to the README file in the package for details of how to install the software.

  • commandline execution: %
    LoopRecog <input filename> <sigma> <min no. of contour points> <output filename>
    , e.g. LoopRecog 1t051998.fits 1.0 20 output.fits

  • input filename is the name of the input FITS file to be processed. The full pathname is required if the file isn't in the same directory as the algorithm executable.

  • sigma is a positive value (float) which controls the Gaussian smoothing filter, part of the image processing. Typically a value of 1.0 will yield reasonable results although different images may require different settings. In general, the lower the value of sigma, the greater the level of detail detected in the image, although too low a value can lead to excessive "clutter" in the output image, and too high a value may lead to loss of detail.

    A minimum value of sigma=0.6 is imposed by the algorithm. There is currently no maximum limit.

  • min no. of contour points is a positive value (integer) which defines the minimum size (in terms of points or pixels) of coronal loops or contours displayed in the output image. Such a limit filters out some of the "clutter", i.e. small loop fragments that may be detected with low sigma settings.

    A minimum value of 20 is recommended for this parameter although presently there are no min/max limits imposed by the algorithm.

  • output filename is the name of the output FITS file containing the loops that have been identified.The full pathname is required if the file isn't in the same directory as the algorithm executable.

Expected Output

  • The algorithm produces a FITS file containing the original image with detected coronal loops overlayed, and an Ascii table extension containing the footpoints of each of the displayed contours (in x-y pixel coordinates). Chain codes for each loop are recorded to aid compatibility with the Heliophysics Knowledgebase, and input parameters entered by the user are also captured. The output file is written to the target directory and filename specified by the user.
A typical Coronal Loop FITS output file is shown here: 1t051998.fits.tmp

Current level of completion

  • The algorithm has been tested on EIT and modified TRACE 2-D FITS images (containing byte and short datatypes) of various sizes. The current CVS version of the algorithm has been sent to Stanford/Lockheed for review and testing in the SDO algorithm "pipeline".

  • The algorithm is one of 5 loop recognition codes tested and compared by Dr Markus Aschwanden earlier in 2007, the results of which are published in his paper 'Comparison of five numerical codes for automated tracing of coronal loops', submitted to Solar Physics.

Future work:

  • Future work on the algorithm will concentrate on:

  1. Correlation with the NLFFF output from the Magnetic Extrapolation algorithm.
  2. Improving loop linkage to deal with loops that cross or fade and reappear.

Science Test Cases

See CoronalLoopDeploymentResults

For all test case input files, download: http://msslxx.mssl.ucl.ac.uk:8080/eSDO/CoronalLoops_1.0_testdata.tar

CoronalLoopDeploymentResults

Case 1: TRACE image: 1t199805.fits

Description

This "classic" Soho TRACE image has become a benchmark for investigators currently working on the Coronal Loop Recognition problem. The sheer number of well defined but densely-packed loops provides a good test for any algorithm. This image was originally by Lee and Gary in their Oriented Connectivity Method (OCM), a pioneering work in Coronal Loop Recognition.

Input

Test image: CoronalLoops/test/1t051998.fits (see Test Case download file)
sigma: 1.0
minimum number of points per contour: 20

The minimum number of points is set to 20 pixels to reduce the amount of "moss" (Markus Aschwanden's description) - short bright pixel segments that are clearly not part of a larger loop structure.

Output

Expected:

A "successful" result is one in which most of the prominent observed loops are detected over their full length by the algorithm. Where loops of similar intensity are closely banded, giving the impression of a single thick loop several pixels wide, an single loop of average intensity should be traced.

Actual:

The algorithm recognises most of the prominent loops at the centre of the image but fails to trace them in their entirety as they fade in intensity towards the edges of the image.

Case 2: TRACE image: tri20000912.1100_48.fits

Description

This close-up TRACE image of the Sun's photosphere shows many bundles of loops that cross and fade quickly, rather than the long well-defined individual loops of Case 1. This represents a much more difficult challenge for the algorithm.

Input

Test image: CoronalLoops/test/tri20000912.1100_48.fits (see Test Case download file)
sigma: 1.0
minimum number of points per contour: 20

The minimum number of points is set to 20 pixels to reduce the amount of "moss".

Expected Output

Expected:

As Case1.

Actual:

The algorithm partially traces the brightest loops top centre of the image and manages to identify their footpoints, but struggles with loops that cross and fails completely to extract the giant lower-intensity loops in the image.

Case 3: TRACE image: tri20031104.2200_65.fits

Description

This close-up TRACE image of the Sun's photosphere shows crossing coronal loops of a similar size and intensity. The image also contains a large amount of background noise, presenting an extra challenge for the algorithm.

Input

Test image: CoronalLoops/test/tri20031104.2200_65.fits (see Test Case download file)
sigma: 1.0
minimum number of points per contour: 20

The minimum number of points is set to 20 pixels to reduce the amount of "moss".

Expected Output

As Case1.

Actual:

The algorithm partially identifies most of the prominent loops in the image, but fails to deal with crossing loops. The graininess of the image produces numerous false-positives.

Case 4: SOHO-EIT image: efz20020109.130016

Description

This full-disk EIT image features coronal loops that are less well-defined and of lower contrast than their TRACE counterparts, making recognition more difficult . The image also has a grid-like pattern superimposed upon it, providing a good test of how well the algorithm deals with "noise".

Input

Test image: CoronalLoops/test/efz20020109.130016 (see Test Case download file)
sigma: 1.0
minimum number of points per contour: 20

The minimum number of points is set to 20 pixels to reduce the amount of "moss".

Expected Output

As Case1.

Actual:

The algorithm struggles to find even the most prominent loops in the image, and the many false positives show that the algorithm is confused by the presence of the grid-like lines.

Case 5: SOHO-EIT image: efz20020116.105610

Description

Another full-disk EIT image with coronal loops that are better defined than in the Case 4 image. Again there are grid-like lines superimposed upon it, which may hinder the algorithms ability to extract purely coronal loop lines.

Input

Test image: CoronalLoops/test/efz20020116.105610 (see Test Case download file)
sigma: 1.0
minimum number of points per contour: 20

Expected Output

As Case1.

Actual:

As in Case 4, the algorithm struggles to extract the even the most prominent loops in the image, and is clearly confused by the the grid-like lines within the image.

Unit Testing

  • gcc compilation: A makefile (Makefile.test) is provided in the installation package to allow a unit test executable called LoopRecogTests to be built. When executed a series of internal checks are run and the results printed on the standard output.

  • commandline execution: %
    LoopRecogTests

Classes with unit tests:

  • alloc.c ................ (3 tests)
  • convol.c ............. (20 tests)
  • correct.c ............ (1 test)
  • error.c ............... (1 test)
  • lines.c ................ (4 tests)
  • link.c .................. (7 tests)
  • loop_recog.c ...... (1 test)
  • normal.c ............. (5 tests)
  • position.c ............ (2 tests)
  • thresh.c .............. (1 test)
  • width.c ................ (4 tests)

Running the algorithm from AstroGrid

AstroGrid workflow instructions:

  1. Open AstroGrid workbench and click "Task Launcher"
  2. Tasks: find application, specify variables and file as input, specify files as output, launch
  3. Task Launcher search: coronal loop or "Coronal Loop Recognition"

Running the algorithm from IDL

The algorithm may be run from within IDL using the IDL wrapper LoopRecog.pro provided in the installation package. The input parameters are the same as for the commandline version. For example:

  • idl> .run LoopRecog.pro
  • idl> LOOP_RECOG_WRAP, 'lt051998.fits', 1.0, 20, 'out.fits'

Please note: The libLoopRec.so shared library is required by the IDL wrapper.

NOTE: All .fits files have been moved from the attachments table to http://msslxx.mssl.ucl.ac.uk:8080/eSDO/algorithms/CoronalLoops/CoronalLoops.html.

-- MikeSmith - 17 Sep 2007

Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | More topic actions
Topic revision: r21 - 2008-01-15 - MikeSmith
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback