Fifth Solar Image Processing Workshop

http://sipworkv.sipwork.org/

This series of workshops brings together members of the solar physics and image processing communities to present and discuss advances in solar image processing techniques. The design and implementation of existing algorithms as reliable and robust tools are discussed, as well as automated techniques for processing very large amounts of data.

The fifth Solar Image Processing Workshop will concentrate on the role played by solar image processing as we enter the petabyte era of solar physics. For example, the Solar Dynamics Observatory vastly increases the amount of data we have about our Sun, and solar image processing is taking a central role in reducing SDO and other data into useful information about the underlying physics. We are pleased to confirm at this time two invited speakers – Piet Martens (Harvard-Smithsonian), discussing the SDO Science Center and the image processing techniques being used there, and Michaele Piana (University of Genoa), discussing inverse problems in relation to image processing.

The structure of the workshop is as follows. The morning is given over to talks presentations, with all breaks also being poster sessions. Participants are expected to attend all talks and poster sessions. In the afternoons, the conference splits into splinter sessions, where the following subject areas are covered. We solicit contributions in these areas.

(1) Solar Eruptive Events

This session examines solar eruptive events of all types such as flares and coronal mass ejections, including:

• detectable precursors
• automated tracking of events via image processing algorithms
• physics of eruptive events
• energy and mass storage in the corona
• flow into the extended solar atmosphere
• prediction of eruption

(2) Solar Disk Features

This session deals with all types of features and events on the solar disk and how they may be tracked in time, space and wavelength.

Topics of particular interest are:

• prediction of the emergence of active regions
• automated tracking of features in time, space and wavelength during their passage across the disc.
• cataloging of features and the comparison of feature catalogs
• detection of changes to solar features with time as precursors to shorter time-scale behavior such as flares and prominence eruptions.
• physics of sunspots, coronal holes, filaments/prominences and other solar features

(3) Reconstruction of the 3-D solar atmosphere

This session deals with the reconstruction of the true structure of the solar atmosphere from multiple viewpoints, wavelengths and times.

Topics of particular interest are:

• reconstruction of the three-dimensional dynamics of coronal mass ejections as a function of time
• propagation of 3-dimensional structures in the extended solar atmosphere
• three-dimensional structure of coronal magnetic fields
• changes in three-dimensional structure in time as a precursor to subsequent events

(4) Differential emission measure, solar activity and irradiance reconstruction

This session deals with the differential emission measure (DEM) of various solar features; how solar activity changes the DEM, and the reconstruction of the solar irradiance spectrum from the spatial features we see on the Sun. Topics of particular interest are:

• DEM reconstruction methods
• using DEM to recover the physics of solar features
• connecting DEM to the observed spatial and temporal behavior of solar features
• reconstruction of the irradiance spectrum.

VERY limited funding is available for students who wish to attend the conference. Please contact the Chair of the Science Organizing Committee (Jack.Ireland@nasa.gov) stating

• name
• institution
• proposed contribution (title + abstract + presentation type – talk or poster)

Students will be selected for funding on a first come, first served basis and on the suitability of their work with respect to the stated areas of interest of the workshop.

Registration is now open at

http://www.sipwork.org/sipworkV/registration/

We have negotiated a special rate at the conference hotel; for CHF230/night ($200, EUR165, GBP136) we provide accommodation, breakfast, lunch, dinner and coffee/tea for the duration of the meeting. The meeting location is in a village in the Swiss Alps, so alternative accommodation is sparse. Participants are strongly encouraged to register at the conference hotel to take advantage of this rate.

If you have any further questions please do not hesitate to contact the SOC and LOC chairs at the email addresses below.

See you in Switzerland in September!

LOC Chair: Andre Csillaghy, University of Applied Sciences Northwestern Switzerland (andre.csillaghy@fhnw.ch)

SOC Chair: Jack Ireland, ADNET Systems Inc./NASA GSFC (Jack.Ireland@nasa.gov)

CONTENTS

1. INTRODUCTION

1.1 Creating an IDL object

1. INTRODUCTION

IDL objects were first introduced in version 5.0. The concept of object
oriented programming (OOP) is not new. It is the basis of many modern
languages such as C++ and Java. The idea behind OOP is that operations and data
go hand in hand. Why? Because if you are handed a piece of data without any way
of operating on it, then it would not be very useful to you. Furthermore, even if you
were given software to operate on the data, the data may still not be
useful without a set of rules to describe how the software interacts with it.

Consequently, the main thrust of OOP techniques is to keep operations and data
married together so that they understand each other. This concept is called
encapsulation. A valid question to ask is: what is wrong with
non-OOP programming techniques in which procedures (or functions) are written to
operate on data? For example, one can develop a reader to read a file, a plotter
to plot it, and a writer to save it, as in the following pseudocode:

IDL> read,file,data
IDL> plot,data
IDL> write,file,data

The short answer is that there is nothing wrong with
using non-OOP techniques. The long answer is that,
as data sets become complicated and operations more complex, simple
procedures are no longer simple. Procedures often become a series of
steps that are called repeatedly or they require enhancements to support
different datasets, which were not originally considered.
In the OOP world, these procedures are called methods.
These methods operate on data in exactly the same way as regular
non-OOP procedures but they are special in that they function
differently depending on the data in question. This concept is called
polymorphism and will be described in more detail in
section 2.3

The purpose of this tutorial is not to make the case for using OOP
techniques in IDL, but to illustrate situations in which such techniques are
more advantageous than non-OOP techniques. We start with demonstrating how
to create a very basic IDL data object, followed by how to interact and
manipulate it, and finally how to apply it to a real world example of reading
and displaying a FITS image. Although not a strong pre-requisite, we assume
that the reader is familiar with the use of IDL pointers and structures.

1.1 Creating an IDL object

An IDL object is simply a container in memory space. This container holds:

• data
• descriptions of the data
• procedures for operating on the data

The descriptions are called properties, and the procedures are
called methods. The interesting twist is that
both properties and methods can change as the data changes.

The first step in creating an object is deciding a name.
The name is important because it should signify something about the
the data. For example, if we are developing software to
sell different types of cars, such as Fords, Toyotas, and Hondas, then
the logical object name is probably car. This
generic name is
referred to as the object class. There is nothing special
or magic about the name, although it should be unique.
However, the name does become important later when we develop
different objects.

Since we are keeping things simple – and are already thinking in terms
of data – we name our object class data.
We define this class in a file named
data__define.pro that contains the following code:

function data::init

 return,1

end

pro data__define

 void={data,ptr:ptr_new()}
 return 

end

So, what does the above all mean. Let’s take it in steps:

1. CLASS filename: naming the file
   data__define.pro is an IDL convention
   for writing a class definition file. The class name has to be part
   of the file name, followed by double underscore and the word
   define.
   If we were defining a car class, then the car class definition file
   would be named car__define.pro.
2. INIT method: the first line in the file defines a method to initialize
   the object. It is mandatory for all definition files.
   The naming convention for this (and all methods) is class name, followed
   by double colon and the method name (::init).
   In this example, the init method doesn’t do very much. We will modify it
   later to actually do something useful. For now, it simply returns
   unity, which signifies that the object is successfully created.
3. CLASS definition: the second line defines an IDL structure in
   which the data will be
   contained. An IDL structure is a variable that can hold different data types such
   as strings, floats, integers, and even other structures. In this example, it
   contains a pointer field (called ptr) that we create with the
   command:
   ptr_new(). The latter function creates an address in memory where
   future data will reside. The advantage of using a pointer is that we can
   dynamically insert data even though we don’t know its size ahead of time.
   In general, the class definition file is where the attributes
   of the object are defined as structure tags.
   These attributes are called properties.
   In our data object example, we have a single property namely
   ptr.

Having written and saved the above file into the current IDL
working directory, we create a data object as follows:

IDL> a=obj_new('data')
IDL> help,a
A               OBJREF    = ObjHeapVar37(DATA)

Creating the data object is called instantiation.
The IDL function call to obj_new(‘data’) looks for the
file data__define.pro, compiles it, and executes the
init and structure definition code that creates the data object.
Calling help on the output variable a shows
that it is an object of class type data.
In the language of OOP, the variable a is an
instance of the data class.
Currently, this object doesn’t
do very much other than waiting around for some data to
come along and some operations to perform on the data.

1.2 Putting data into an object

As currently defined, we cannot interact with the data object because
we have not defined any methods to communicate with it.
The next step is to write a method that allows us to insert data into
the object. We re-edit the file data__define.pro as follows:

function data::init

;-- allocate memory to pointer when initializing object

 self.ptr=ptr_new(/allocate)
 return,1

end

;----------------------------------------------------------------

pro data::set,value

;-- if data value exists, then insert into pointer location

 if n_elements(value) ne 0 then *(self.ptr)=value
 return 

end

;------------------------------------------------------------------

pro data__define

 void={data,ptr:ptr_new()}
 return 

end

Several things are going on that require explanation:

1. SELF variable:
   we have added the following line to data::init,

   self.ptr=ptr_new(/allocate)

   What is self? When we are working inside an object, we reference the object using the variable name self.
   The above line says:

   “Take the structure field named ptr,
   which we have defined to be a pointer, and allocate new memory to it using
   the IDL pointer function ptr_new(/allocate).”
   

   We only need to do
   this once when the data object is first created.

2. SET method: we name the method for inserting data
   set. Any name will do, but following IDL convention
   we precede it with the class name data::. This method
   is a procedure that takes the variable data as a
   command line argument. As is always good practice, we check that
   the variable value exists before proceeding
   by calling n_elements(value). If the latter returns a
   non-zero value, then we insert the value into the pointer value
   ptr.
3. Inserting data:
   if you are confused by the syntax
   *(self.ptr)=value, don’t worry. Here is the simple breakdown.
   Recall that self is an internal reference to the
   data object, which
   is defined to be a structure with a tag (or field) named ptr.
   We reference this pointer as self.ptr. The latter is not
   an actual data value but an address to where data is located (or stored).
   The asterisk symbol references the value of the data stored at the
   pointer location. When the data object is first initialized, there is
   no data at this location. The IDL statement
   *(self.ptr)=value says:

   “Take my input data value and
   insert (or copy) it to this pointer location.”
   

   In the language of OOP, this action is called
   setting the object property.

1.3 Getting data out of an object

In addition to inserting data, we need a method for extracting data
from the object. We shall call this method data::get,
and include it in the file data__define.pro as follows:

function data::init

;-- allocate memory to pointer when initializing object

 self.ptr=ptr_new(/allocate)
 return,1

end

;----------------------------------------------------------------

pro data::set,value

;-- if data value exists, then insert into pointer location

 if n_elements(value) ne 0 then *(self.ptr)=value
 return 

end

;----------------------------------------------------------------

function data::get,value

;-- if data value is stored in object pointer, then copy it out

 if n_elements(*(self.ptr)) ne 0 then value=*(self.ptr)

 return,value

end

;------------------------------------------------------------------

pro data__define

 void={data,ptr:ptr_new()}
 return 

end

The get method differs from
set in that we have defined it to be a function.
The choice of function versus procedure is more of a matter
of convenience than convention.
The function first checks
for the existence of a data value at the pointer location
self.ptr. If data is present, then the value
*(self.ptr)
is copied to the output variable value.
If there is no data value, then an undefined value is returned.

1.4 Destroying an object

When finished with using an object, it is recommended that the
memory allocated to the object be released. All objects should therefore
have a method that will take care of cleaning up after themselves.
The IDL naming convention for this method is ::cleanup. In the case
of the data object, this cleanup method would involve freeing the pointer
property of any allocated data. To implement a cleanup method, we include
the following lines in the file data__define.pro:

function data::cleanup

;-- free memory allocated to pointer when destroying object

 ptr_free,self.ptr
 return

end

The IDL procedure ptr_free flushes the pointer
variable self.ptr of any saved data and re-initializes it.
This method is not called directly. Instead it is called automatically
when the object is destroyed using the IDL obj_destroy procedure
as follows:

IDL> obj_destroy,a                             ;-- destroy object
IDL> help,a
A               OBJREF    = ObjHeapVar4        ;-- object is now null

2. WORKING WITH OBJECTS

Having defined a data class, we next demonstrate how it can be
used in common applications, and how it can be extended to
perform different functions.

2.1 Modifying object properties

Because we have used a pointer as its property,
the data object can accomodate any data type.
For example, let’s create a 2-dimensional float array
and insert it and extract it as follows:

IDL> image=findgen(512,512)
IDL> a=obj_new('data')        ;-- create object variable a
IDL> a->set,image             ;-- insert image
IDL> image2=a->get()          ;-- extract image
IDL> help,image2
IMAGE2            FLOAT     = Array[512, 512]

This example introduces the arrow syntax for calling methods.
The statement a->set,image says:

“Call the method named
set on the object variable named a, and pass
the argument variable named image.”

We apply the same syntax when calling the get method
except that we invoke it as a function and return the value into the
output variable image2.

Next, let’s try inserting and extracting a data structure such as the
system variable !d:

IDL> a->set,!d
IDL> var=a->get()
IDL> help,var,/st
** Structure !DEVICE, 17 tags, length=88:
   NAME            STRING    'X'
   X_SIZE          LONG               640
   Y_SIZE          LONG               512
   X_VSIZE         LONG               640
   Y_VSIZE         LONG               512
   X_CH_SIZE       LONG                 6
   Y_CH_SIZE       LONG                12
   X_PX_CM         FLOAT           40.0000
   Y_PX_CM         FLOAT           40.0000
   N_COLORS        LONG          16777216
   TABLE_SIZE      LONG               256
   FILL_DIST       LONG                 1
   WINDOW          LONG                 0
   UNIT            LONG                 0
   FLAGS           LONG            328124
   ORIGIN          LONG      Array[2]
   ZOOM            LONG      Array[2]

In this example, we insert the variable !d into the
object and then retrieve it into the variable var.
Note that we only create the object variable once, and recycle it as
necessary. We can of course create as many data objects as we like
and store different data types accordingly. Just remember to give them
different variable names.

2.2 Adding object methods

As we have already seen, we can add new methods to an object by
editing its class definition file. We can make the data object
more useful by giving it the ability to read data
from a file and plot the data. In the following example, we open the file
data__define.pro and add two methods
that we conveniently call data::read and
data::plot:

pro data::read,file

 if n_elements(file) ne 1 then return ;-- at least one file name entered
 check=findfile(file,count=count)     ;-- check if file exists
 if count ne 1 then return            ;-- bail if not there
 image=fltarr(512,512)                ;-- assume a 512x512 image file
 openr,lun,file,/get_lun              ;-- open file
 readf,lun,image                      ;-- read image
 free_lun,lun                         ;-- close file
 self->set,image                      ;-- insert image into object
 return

end

;---------------------------------------------------------------------

pro data::plot

 value=self->get()                                    ;-- extract data value from object
 dsize=size(value)                                    ;-- determine data dimensions
 if dsize[0] eq 2 then tvscl,congrid(value,512,512)   ;-- if 2-dimensional, CONGRID and TVSCL it
 return

end

The read method accepts a file name as its argument. As is good
practice, we check if the filename argument is entered and
use IDL’s findfile to test if the file actually
exists. We subsequently open the file, read the data,
and insert into the object using the
set method call: self->set,value. Note that because we are
referencing the object itself, we use the self variable
name for the object.

The plot method extracts the data value from
itself via the get method call: self->get().
It checks that the data is a 2-dimensional image using the
IDL size function, and
plots it with a call to IDL’s tvscl command
and congrid, which expands the image to a 512×512 array size.
To demonstrate this sequence of steps,
let’s create an image file image.dat in the current directory and
deploy the data object as follows:

IDL> image=findgen(512,512)        ;-- create 512x512 image array
IDL> file='image.dat'
IDL> openw,lun,file,/get_lun       ;-- write image to file
IDL> printf,lun,image
IDL> free_lun,lun

IDL> .run data__define             ;-- recompile class definition file
IDL> a->read,file                  ;-- read image and display it
IDL> a->plot

The call to the plot method produces the following simple image:

Sample data plot

Note that it is not necessary to reinitialize the data object since
we are using the same object variable to store the image data.
However, it is necessary to recompile the class definition file
since we have added new methods to it.

2.3. How does inheritance work?

Looking at the last two lines in the previous example, it doesn’t appear from
our data object example that we have advanced very far using OOP techniques.
In particular, compared to the opening example of reading and plotting
data using non-OOP procedures, it seems that a lot of effort was invested in
writing object methods that essentially reproduce the same functionality as
conventional procedure calls.

The real power of OOP techniques comes not in what we have just
done, but in what we are about to do. The data object that we have created
is a building block that can be used to develop objects that
perform more complicated functions. Consider the following problem:

“I have an image in a FITS file that I would like to read and display. I would
also like to remember the name of the FITS file so that I can track
it.”

The data object that we have created provides a convenient storage facility
for FITS image data, but it lacks the required FITS file reader
and it doesn’t have a way of remembering the file name. We could
of course re-edit the data class definition file to add this functionality,
but that would involve much more work.
The OOP solution to the problem is to define a new class that somehow
inherits the functionality of the data class. The following is how to do it.

We define a new class called fits by creating
a file named fits__define.pro, which contains the
lines:

pro fits::read,file

 if n_elements(file) ne 1 then return   ;-- at least one file name entered
 check=findfile(file,count=count)       ;-- check that file exists
 if count eq 0 then return
 image=mrdfits(file)                    ;-- call Astronomy library FITS reader
 self->set,image                        ;-- insert image data into property
 self.filename=file                     ;-- save filename in property
 return

end

;-------------------------------------------------------------------------

pro fits__define

 void={fits,filename:'', inherits data} ;-- inherit from data class
 return 

end

Several new concepts are happening here. Let’s start
from the bottom up.

1. FITS__DEFINE: the procedure that defines our fits data
   structure looks very different from the original data structure in
   data__define.pro. It appears to be missing
   the data pointer property. Actually, the latter is
   is not missing. In OOP language, it is inherited from the
   data class via the statement inherits data.
   In addition
   to inheriting data’s property, the fits class inherits all of its
   methods: init, cleanup, set, get, read, and plot.
   Hence, inheritance has saved us from writing a lot of extra code.
   Note that the fits data structure contains a new property called
   filename, which is a string data type. This
   property will be used to store the FITS file name.
2. FITS::READ: object inheritance
   imports data’s simple read method
   data::read, which clearly will not work on a FITS file.
   To overcome this problem, we write a new method that uses the
   Astronomy library routine
   
   mrdfits.pro
   to read
   the FITS file and insert the resulting image data into the object pointer
   by using the inherited set method.
   The fits read method thus overrides data’s
   read method.
   This new method also saves the FITS filename as a property of the
   fits object once the data is saved.

In OOP language, the fits class is
a derived class of data,
and a fits object is referred to as child of
the parent data object.
The following example demonstrates how to use the fits class to create
an object to read a Big Bear H-alpha image
contained in the file
bbso_halph_fl_20040310_173531.fts:

IDL> file='bbso_halph_fl_20040310_173531.fts'
IDL> f=obj_new('fits')                 ;-- create object
IDL> help,f
F             OBJREF    = ObjHeapVar37(FITS)

IDL> f->read,file                      ;-- read file
IDL> f->plot                           ;-- plot data
IDL> image=f->get()                    ;-- extract image
IDL> help,image
IMAGE            INT       = Array[512, 512]

BBSO H-alpha

We create a fits object using
the obj_new function, and feed it the FITS file name.
After
reading, we plot the image, and
extract the image data using the get method.
As defined, the get method inherited from the data class
only allows us to extract the data value from the property pointer. However,
we would also like to extract the filename that is associated with the
data, which is also a property. To include this functionality, we
override the get method in data__define.pro
with a new get method in fits__define.pro as follows:

function fits::get,filename

 filename=self.filename             ;-- copy filename in variable
 image=self->data::get()            ;-- call DATA's GET method to return data
 return,image 

end

The above lines illustrate the simplicity and elegance of inheritance.
We have added a new output argument filename in which we
return the string value of the filename, which is saved in
the property self.filename. Since we also wish to
return the data value, we include a call to the get method that we have
already defined for the data class. There is no need to rewrite the latter.
Hence, in the last example, we can execute the following:

IDL> data=f->get(filename)
IDL> help,data,filename
DATA            INT       = Array[512, 512]
FILENAME        STRING    = 'bbso_halph_fl_20040310_173531.fts'

Note also that the fits object methods (read and
get)
retain the same names as their parent data method names. The difference
is in their behaviors, which depends upon which data type is being operated
on. This ability to behave differently depending upon class (or data type) is called
polymorphism.

3. APPLYING OBJECTS TO SOLAR IMAGES

The example classes in this tutorial demonstrate how
objects can be
designed, created, and used.
If interested in experimenting with these
classes, you can download complete definition files via the following links:

data__define.pro

and

fits__define.pro.

Although useful for illustrative purposes,
these classes are too simplistic for
handling more complicated solar datasets.
For example, not all solar datasets conform
to the FITS format standard. Variations
in the use of header keyword names and values
often require the use of special readers.
Moreover, different datasets usually
require the application of instrument-specific processing algorithms
inorder to be useful.
This dependence of operations upon the properties of the dataset
naturally lends itself to the use of objects as a tool for analyzing
solar data.

3.1 Using MAP objects

IDL maps are described in
maps.html.
An IDL map is a structure data type that
stores data and associated identifying information. A map
structure is not a true object since it does not contain methods.
Nevertheless, it is useful
for displaying and, in particular, overlaying solar images from
different instruments.
The following example illustrates how to
to read, process, and display the quicklook
SOHO/EIT file

efr20040309.072550
using a map and procedures available in the IDL

SolarSoft library:

IDL> files='efr20040309.072550'
IDL> read_eit,files,index,data                   ;-- read EIT QL file
IDL> eit_prep,index,data=data,outindex,outdata   ;-- prep data
IDL> index2map,outindex,outdata,emap             ;-- create map
IDL> eit_colors,195                              ;-- load 195 color table
IDL> plot_map,emap,/log,grid=20,/limb            ;-- plot map

SOHO/EIT 195 A

This example highlights several points. Even though we
are primarily interested in
reading and plotting an EIT image, we have to
know and perform several steps:

1. read the EIT FITS file using the special reader
   read_eit.
2. process the EIT image
   using the procedure eit_prep, which performs dark current
   subtraction and flatfielding.
3. convert the processed image to a map structure
   emap via the procedure
   index2map.
4. plot the map structure emap
   using the procedure plot_map, which is
   called with the keywords /limb, /log, and grid=20
   inorder to display a log-scaled image with a heliographic grid and limb.

In addition, we have to remember to pass the variables: index, data
as arguments to these procedures, and know that our EIT dataset is
a 195 A image that has a custom color table (which we load with the procedure
eit_colors). That’s a lot to remember each time. It would be nice
if we could somehow encapsulate the above procedures and data into an
object and only have to remember as little as necessary to get the job done.

What we need is a map class that will allow us to define
map objects to store data such as EIT images and
provide methods to manipulate them. Such a class already exists. It is defined
in the file
map__define.pro. The map class is analogous to
our example data class except that it uses a map
structure to store data and its corresponding properties (such as pointing).

Now consider the following OOP approach to the same example:

IDL> file='efr20040309.072550'
IDL> eobj=obj_new('eit')                         ;-- create an EIT object
IDL> eobj->read,file                             ;-- read EIT file
IDL> eobj->plot                                  ;-- plot EIT image

The above example produces exactly the same plot output as the conventional
example, but what is different? Let’s take it in steps:

• We have created an object variable eobj by
  calling the object creation function obj_new(‘eit’)
  with the class name eit. But where did this class
  come from? The answer is that we have already created a class
  definition file
  
  eit__define.pro in which we have
  incorporated the EIT data as a property.
  The eit class definition file is slightly more complicated
  than the fits and data classes defined earlier.
  The eit class inherits from a slightly more complicated
  fits class that is defined in
  
  fits__define.pro,
  which in turn inherits from the map class.
  The map class
  works as a storage device in much the same way as the simple
  data class that we defined
  in our earlier example.
  This inheritance relationship is illustrated in the diagram below.
  

  MAP->FITS->EIT Class Inheritance

• After creating the eit object, we read the
  EIT file using the read method. This method
  is nothing other than the read_eit procedure, which we have incorporated
  into eit__define.pro. This is polymorphism
  at work. Because our object is aware that it belongs to the
  eit class, its read method correctly calls the corresponding
  eit reader, followed by eit_prep to process the image.
  Hence, the EIT image is automatically
  read, processed, and saved into the eit object.
• With the EIT image in memory, we display it
  using the plot method. This method is the
  plot_map procedure that we have already incorporated into
  map__define.pro and, hence, is inherited
  by the eit object. We have also modified the plot method
  slightly to include a call to eit_colors in order
  to load the corresponding image color table.

In summary, the object variable eobj object is a map object
since the eit class is derived from a map class.
The details of the relationship between
eit and map classes are not overly important
to the average user who is interested in performing basic data analysis.
The main point is that, by using an eit map object,
the overhead of remembering
several instrument-specific procedure names is significantly reduced.

3.2 Image analysis with objects

The eit class has a get method that
provides access to the EIT image data and map structure as
follows:

IDL> edata=eobj->get(/data)
IDL> help,edata
EDATA           INT       = Array[1024, 1024]

IDL> emap=eobj->get(/map)
IDL> help,/st,emap
** Structure <40e0fb08>, 13 tags, length=2097256, refs=2:
   DATA            INT       Array[1024, 1024]
   XC              FLOAT          -8.15294
   YC              FLOAT           21.0663
   DX              FLOAT           2.63500
   DY              FLOAT           2.63500
   TIME            STRING    ' 9-Mar-2004 07:24:58.402'
   ID              STRING    ' Rocket Science EIT 195'
   ROLL_ANGLE      FLOAT           0.00000
   ROLL_CENTER     FLOAT     Array[2]
   DUR             FLOAT           12.5970
   XUNITS          STRING    'arcsecs'
   YUNITS          STRING    'arcsecs'
   SOHO            BYTE         1

The pointing information contained within a map structure allows us to
analyze different images regardless of the image source. By making a
map structure a property of a map object, we
simplify the steps involved in performing typical image processing operations.
We will conclude this tutorial by demonstrating three such operations:
rotating an image; correcting for differential solar rotation; and overlaying
images.

• Rotation: to rotate (or roll) an image clockwise about its center,
  we pass the angle of rotation as an argument to the method rotate.

  IDL> robj=eobj->rotate(45) IDL> robj->plot

  In this example, we rotate the EIT image contained in
  the eit map object eobj by 45 degrees to create
  a new map object robj which produces the image:
  

  Rolled EIT 195 A

• Solar differential rotation: to differentially rotate an image we pass the
  time interval over which to rotate
  as an argument to the method drotate.

  IDL> dobj=eobj->drotate(5,/days) IDL> dobj->plot

  In this example, we solar rotate the EIT image
  forward in time by 5 days to produce
  the image:
  

  Differentially rotated EIT 195 A

• Overlaying images: to overlay two images, we first plot a base image
  using the plot method and overplot a second image
  as a contour using plot
  with the keyword /over.
  We demonstrate this operation by overlaying
  a SOHO/MDI image on an EIT
  image. But
  first we need to create an mdi map object.
  We have already defined an mdi class by writing a
  definition file
  
  mdi__define.pro.
  As with the eit class, the mdi class inherits
  from a fits class (which inherits from a map class).
  Because of this common inheritance, an mdi object has the same
  plot method as an eit object.
  This class allows us to create
  an mdi object to read and display a high-resolution MDI image
  in the file
  
  mdi_maglc_re_20040310_2102.fts:

  IDL> file='mdi_maglc_re_20040310_2102.fts' IDL> mobj=obj_new('mdi') ;-- create an MDI object IDL> mobj->read,file ;-- read MDI file IDL> mobj->plot ;-- plot MDI image

  

  SOHO/MDI
  Note how the steps for reading and plotting the MDI
  image are identical to those for EIT. The internal details of
  how these steps are performed are handled by the
  corresponding methods. Having created eit and mdi
  objects, the final step of overlaying their corresponding images
  is reduced to the following single line:

  IDL> eobj->plot,/over,/drotate ;-- overlay EIT image on previous MDI image ; (correcting for solar differential rotation)

  

  EIT/MDI overlay
  In this example, we used the /drotate keyword to differentially
  rotate the EIT image contours to the same time as the
  base MDI image.

• Extracting a sub-field: the
  extract method extracts a sub-field graphically
  or via keywords.

  IDL> mobj=obj_new('mdi') IDL> mobj->read,'mdi_maglc_fd_20040522_0005.fts.gz' IDL> cobj=mobj->extract() IDL> cobj=mobj->extract(xrange=[-500,500],yrange=[-500,500])

  In this example, we read an MDI full-disk image in the file
  
  mdi_maglc_fd_20040522_0005.fts.gz, and call extract
  without any keywords. A box-cursor is used to select a sub-field.
  Alternatively, the keywords: xrange and yrange
  can be used to specify the sub-field.

  MDI Full Disk

  MDI Partial Disk

Two significant developments arose from this meeting. Firstly, the meeting was organized around a new website http://www.sipwork.org, set up not only to handle the organizational aspects of SIPWork IV, but also to act as a central meeting place where the discussion of image processing, computer vision and its application to solar physics can be discussed. At time of writing, the website is undergoing a major revision in order to make it simpler to manage and more directly accessible from social media feeds such as Facebook and Twitter. Secondly, the participants spontaneously agreed to hold an extra splinter session during the meeting, on image/data browsing tools and the availability and accessibility of images and data, with special emphasis on the data volume challenges of SDO. The flexibility of the workshop format we designed can accommodate such spontaneous requests from this solar image processing community. That this request occurred clearly shows that the participants are eager to discuss the data volume challenge of SDO.

TRACE/EIT 19.5 nm Image Alignment using Cross-Correlation

(Peter T. Gallagher, L-3 Com Analytics Corp., NASA/GSFC)

This page describes a simple method to correct the pointing information in TRACE
19.5 nm images by cross-correlating them with EIT 19.5 nm images using IDL
SSW. The data were taken during an X-class flare which occurred on 21-Apr-2002, more details on which can be found here.

An alternative method for correctng TRACE pointing (using MDI continuum images) is described at Tom Metcalf’s page.

Step 1: Read, calibrate and convert data to maps

It is best to select images which have been taken as
close in time as possible. In this example the images are separated by
11 seconds.

IDL> eit_prep, 'efr20020421.011334', eit_index, eit_data
IDL> index2map, eit_index, eit_data, eit_map
IDL> eit_map = map2earth( eit_map ) ; SOHO @ L1 -> Earth

IDL> mreadfits, 'trf20020421_011323_a2.fits', index, data
IDL> trace_prep, index, data, trace_index, trace_data, /wave2point
IDL> index2map, trace_index, trace_data, trace_map

Further information on mapping software can be found at Dominic
Zarro’s
pages.

Figure 1: TRACE and EIT 19.5 nm images with the same
field-of-view.

Step 2: Extract regions with distinct features and plot

We extract a region where there is a bright loop visible:
800″ < Solar_X < 1000″ and -350″ < Solar_Y < -150″. This
is plotted
in Figure 1 above.




IDL> xrange = [ 800, 1000 ]
IDL> yrange = [ -350, -150 ]
IDL> sub_map, eit_map, sub_eit, xrange = xrange, yrange = yrange
IDL> sub_map, trace_map, sub_trace, xrange = xrange, yrange = yrange

IDL> eit_colors, 195
IDL> !p.multi = [ 0, 2, 1 ]
IDL> plot_map, sub_eit, /log
IDL> plot_map, sub_trace, /log

Step 3: Extract TRACE and EIT images and convert to same size

In order to compute the cross-correlation between two images the
image with the lesser number of pixels (EIT) is rebinned
to the size of the larger (TRACE).




IDL> trace_image = sub_trace.data
IDL> sz = size( trace_image, /dim )
IDL> cube = fltarr( sz( 0 ), sz( 1 ), 2 )
IDL> rsub_eit = coreg_map( sub_eit, sub_trace )
IDL> cube( *, *, 0 ) = rsub_eit.data
IDL> cube( *, *, 1 ) = sub_trace.data

Step 4: Compute offsets between TRACE and EIT and update TRACE map.

Use cross-correlation to find the pixel offsets between TRACE and EIT
and create a new TRACE map with corrected pointing.




IDL> offsets = get_correl_offsets( cube )
IDL> print, offsets
      0.00000      0.00000
      5.19975      8.60905
IDL> correct_trace_map = shift_map( trace_map, offsets( 0, 1 ) * trace_map.dx, $
IDL>                                           offsets( 1, 1 ) * trace_map.dy )

Figure 2: Left: TRACE with EIT contours before pointing
correction. Right: The corresponding data after TRACE pointing correction.

Step 5: Plot the uncorrected and corrected TRACE data with EIT contour
overlay

The corrected and uncorrected TRACE 19.5 images together with EIT contour
overlays are given in Figure 2 above.




IDL> plot_map, trace_map, xrange = xrange, yrange = yrange, /log
IDL> plot_map, eit_map, /over
IDL> plot_map, correct_trace_map, xrange = xrange, yrange = yrange, /log
IDL> plot_map, eit_map, /over

Figure 3: Movie which blinks between the coaligned TRACE and EIT images (Hit reload/refresh to run).

CONTENTS

1. INTRODUCTION

1.1 Creating a Map

1.2 Plotting a Map

1.3 Plotting Maps on Different Color Scales

2. OPERATIONS WITH MAPS

2.1 Rotating a Map

2.2 Stretching and Resizing a Map

2.3 Extracting a Sub-region From a Map

2.4 Differencing Maps

3. APPLYING MAPS TO SOLAR IMAGES

3.1 Creating a SOHO/EIT Map

3.2 Creating a SOHO/CDS Map

3.3 Creating a Yohkoh/SXT Map

3.4 Converting a TRACE File to a Map

3.5 Converting a FITS File to a Map

3.5.1 Converting a HESSI FITS File to a Map
3.6 Correcting for Solar Differential Rotation

4. OVERLAYING MAPS

An IDL map is a structure that contains two-dimensional (2-d) image data with accompanying pixel coordinate and spatial scale information. The latter parameters are defined as properties of the map and are unique for each image source. Defined in this manner, an arbitrary image can be manipulated or transformed in a manner that is independent of the image source.

This software note describes how to create and use maps for processing solar images. We will use sample images obtained from instruments onboard SOHO and Yohkoh missions. Typical processing tasks include: roll-correction, stretching, translation, solar rotation-compensation, and image coalignment. Although we discuss solar examples, the techniques described below are applicable to any two-dimensional dataset. IDL mapping software is incorporated into the SolarSoft system – a set of integrated software libraries, databases, and system utilities which provide a “common” programming and data analysis environment for Solar Physics.

The low-level function for creating a map is make_map. In this example, a 256×256 array is created with findgen and converted to a map variable:

IDL> image=findgen(256,256)
IDL> map=make_map(image)
IDL> help,/st,map

** Structure <4031f908>, 8 tags, length=40056, refs=1:
   DATA            FLOAT     Array[256,256]
   XC              FLOAT           0.00000
   YC              FLOAT           0.00000
   DX              FLOAT           1.00000
   DY              FLOAT           1.00000
   TIME            STRING    '11-Mar-1998 11:40:44.000'

The resulting map is an anonymous structure with the following tag definitions:

• DATA: the 2-d data values.
• XC, YC: the cartesian coordinates of center of the image. Since coordinate information was not specified, the origin is used as the default value.
• DX, DY: the spacing between between pixels in the cartesian X and Y directions, respectively. Since spatial scale was not specified, the spacings default to unity.
• TIME: a reference time for the image. It could be the start or mean time of the image. The default time is the current Universal Time (UT) when the map is created.

The above tag definitions are defined also as keywords in make_map. For example, a map with a pixel spacing of 2 units in the x-direction and 3 units in the y-direction is created by:

IDL> image=findgen(256,256)
IDL> map=make_map(image,dx=2,dy=3)
IDL> help,/st,map
** Structure <403cd0e8>, 9 tags, length=40072, refs=1:
   DATA            FLOAT     Array[100, 100]
   XC              FLOAT           0.00000
   YC              FLOAT           0.00000
   DX              FLOAT           2.00000
   DY              FLOAT           3.00000
   TIME            STRING    '18-Mar-1998 15:23:16.000'

Note that the basic map structure definition is kept intentionally simple, with data and coordinate parameters being the main defining properties. The units of the coordinate system are also arbitrary. Additional properties are added two ways:

1. At the definition stage. For example, to include a property UNITS that specifies coordinate units:

   
   IDL> nmap=make_map(map,units='arcsecs')
   IDL> help,nmap,/st
   ** Structure <403cd0e8>, 9 tags, length=40072, refs=1:
      DATA            FLOAT     Array[100, 100]
      XC              FLOAT           0.00000
      YC              FLOAT           0.00000
      DX              FLOAT           2.00000
      DY              FLOAT           3.00000
      TIME            STRING    '18-Mar-1998 15:23:16.000'
      UNITS           STRING    'arcsecs'
   

2. After the definition stage. Following the same example, but using the function add_prop :

   
   
   IDL> add_prop,map,units='arcsecs'
   
   

   produces the same result. Multiple properties are added as multiple keywords, with the restriction that each property name is unique.

Maps are plotted using the procedure plot_map . Thus, using the 2-d image created earlier,

IDL> plot_map,map

Fig. 1 – Image Map

The procedure plot_map inherits all the major IDL plot keywords such as xstyle, ystyle, font, charsize, charthick, etc. It supports the following additional keywords:

• drange: 2-element vector of data min and max to display
• xrange: 2-element vector of xmin and xmax to display
• yrange: 2-element vector of ymin and ymax to display
• /log: display using log10 scaling
• xsize, ysize: device pixel size for the plot window [def=512x512]
• /noaxes: inhibit plotting axes
• /nolabels: inhibit printing axis labels
• /notitle: inhibit printing title
• /cont: plot image as a contour
• levels: an array of contour levels

The use of more advanced keywords will be demonstrated later in this tutorial.

The following steps demonstrate how to simultaneously plot maps using different color tables.

IDL> image=findgen(256,256)
IDL> map=make_map(image)                ;-- make a simple map
IDL> nc=100                             ;-- # of colors per image
IDL> loadct,3,ncolors=nc                ;-- load red table from  0:nc-1
IDL> plot_map,map,ncolors=nc            ;-- plot map using red table
IDL> loadct,1,bottom=nc,ncolors=nc      ;-- load blue table from nc:2*nc-1
IDL> plot_map,map,bottom=nc,ncolors=nc  ;-- plot using blue table

The key to plotting with separate color tables is to divide evenly the total number of available device colors. The latter is given by the system variable !d.table_size. In the above example, the total available colors is 200. Hence, the color table is split into two equal halves of nc=100 colors each. The routine loadct loads a red color table (#3) into the first 0 to nc-1 color range, and blue color table (#1) into the second nc to 2*nc-1 range. The resulting plots appear as:

Fig. 2a – Red Table	Fig. 2b – Blue Table

The following examples demonstrate various image processing that can be applied to maps.

Maps are rotated using the function rot_map . An interesting example is provided by rotating (i.e, rolling) a SOHO EIT full Sun image. The routines for creating an EIT map will be described in section 3.1 . For now, assume a 512×512 EIT map, eit_map with the following properties:

   DATA            INT       Array[512, 512]
   XC              FLOAT           14.2450
   YC              FLOAT          -13.0278
   DX              FLOAT           5.18000
   DY              FLOAT           5.18000
   TIME            STRING    '15-Mar-1998 00:00:49.985'
   DUR             FLOAT           12.1000
   ID              STRING    'EIT: 304'
   SOHO            INT              1
   UNITS           STRING    'arcsecs' 

This map contains an EIT 304 Angstrom image that has been double-binned from it’s original 1024×1024 size. Note the additional properties ID specifying the image wavelength, DUR specifying the image duration, and SOHO specifying image source. To rotate this map through, say, 60 degrees clockwise about its center, and display the results:

IDL> rmap=rot_map(eit_map,60.)
IDL> plot_map,eit_map,/log
IDL> plot_map,rmap,/log,/new

IDL> help,/st,rmap

   DATA            INT       Array[512, 512]
   XC              FLOAT           14.2450
   YC              FLOAT          -13.0278
   DX              FLOAT           5.18000
   DY              FLOAT           5.18000
   TIME            STRING    '15-Mar-1998 00:00:49.985'
   DUR             FLOAT           12.1000
   ROLL            FLOAT           60.0000
   ROLL_CENTER     FLOAT     Array[2]
   ID              STRING    'EIT: 304'
   SOHO            INT              1
   UNITS           STRING    'arcsecs' 

Fig. 3a – Before roll	Fig. 3b – After roll

The keyword /new forces the creation of a new plot window in which to plot the rotated image. The rotation is performed by rotating the coordinates of each image pixel, computing a new grid of rotated coordinates, and interpolating the new grid back to the original image. Generally, the dimensions of the rotated grid will be larger than the original image. By default, rot_map will preserve the original image dimensions by clipping image pixels that fall outside the original dimensions. The keyword /full_size inhibits clipping.

The roll angle and roll center are added as property fields name ROLL and ROLL_CENTER to the rotated map. The roll angle in units of degrees measured clockwise from North and the roll center coordinates are in data units (i.e., arcsecs). Note that if the input map is already rolled, then the new roll angle will be added to the existing roll value. By default, the map is rotated about it’s center. The keyword center can be used to rotate about an arbitrary center, e.g., center=[20,30] .

The keyword roll has the same functionality and can be used to roll a map to any given roll angle, regardless of it’s current roll angle. For example, to rotate a map to a 100 degree roll:

IDL> rmap=rot_map(eit_map,roll=100.)

The function grid_map changes the dimensions and pixel spacing of a map. For example, the following command will rebin the 512×512 EIT map displayed in figure 3a, to a 128×128 size map:

IDL> gmap=grid_map(map,128,128)

The (x,y) pixel spacings of the output map are computed automatically. To change the spacing between pixels, use the keywords dx, dy . For example, to rebin to a pixel spacing of 2 units in x- and 5 in y-directions:

IDL> gmap=grid_map(map,dx=2,dy=5)

The (x,y) dimensions of the output map are computed automatically. Spacing and output dimension parameters can be combined to produce different stretching and resizing effects. For large images, regridding can be a slow process since each pixel has to be interpolated onto a new spatial scale.

The procedure sub_map extracts a sub-region from a map. It can be used in two ways, graphically or manually.

IDL> sub_map,map,smap,/plot,[xrange=xrange,yrange=yrange,ref_map=ref_map]

A sub-region of map is selected graphically by using the keyword /plot, in which case plot_map is called and a “rubber-band” cursor is used to select a sub-region. The sub-region map is returned in smap. The data coordinate limits of the sub-region are returned as two-element vectors in the keywords xrange and yrange. Alternatively, the data coordinate limits can be input via the keywords xrange=[xmin,xmax], yrange=[ymin,ymax], or via the keyword ref_map. In the latter case, the extracted sub-region will be extracted according to the xrange/yrange values of ref_map.

The procedure diff_map subtracts two maps to produce a difference map.

IDL> dmap=diff_map(map1,map2,[/rotate])

The output map dmap contains a difference image of the two images contained in the map1 and map2 input maps — the second image is subtracted from the first. The optional keyword /rotate solar rotates the second image to the time of the first image prior to subtraction. Solar rotation is described in section 3.6 .

This section describes the steps involved in creating maps for various solar datasets. The routine index2map is a generally useful program for creating maps from any dataset that is in a Yohkoh index/data format.

The following lines read and process EIT images into maps:

IDL> files=eit_files('19-mar-98','20-mar-98',wave=304,/full)
IDL> read_eit,files,index,data,[outsize=outsize]
IDL> eit_prep,index,data=data,outindex,outdata
IDL> index2map,outindex,outdata,emap

Each step is summarized as follows:

1. eit_files returns EIT filenames for a range of times/dates and wavelength filter. This example returns filenames (string array) for 304 Angstom full-disk images.
2. read_eit reads the filenames array and returns an index structure representation of the FITS file header and a 2-d data array of image values. The latter is a 3-d array when more than one image is read. The optional keyword outsize specifies the dimensions of the output image. For example, setting outsize=512 produces a 512×512 image.
3. eit_prep applies degridding, dark current, and flatfield corrections to the image data.
4. index2map converts the corrected outindex and outdata variables into a map. The latter is an array when multiple images are copied.

In the case of full-disk images, the 1024×1024 array size can lead to IDL out-of-memory problems on some systems. To avoid this problem, there is an optional outsize keyword to rebin images to a smaller dimension (with accompanying loss of spatial resolution). The following example creates a 512×512 map.

IDL>index2map,outindex,outdata,emap,outsize=512

The outsize keyword can also be used when reading the image with read_eit. More detailed documentation on manipulating EIT data is located in the EIT Users Guide .

The function mk_cds_map creates CDS maps. The CDS instrument produces images by rastering in pre-determined spectral lines. Images can be derived by using the peak count rate intensity of these lines, or by integrating the count rates over the observed spectral wavelength band. The following steps illustrate reading and processing CDS images into maps:

IDL> files=cds_files('19-mar-98','20-mar-98',study=study,info=info)
IDL> read_cds,files,ql
IDL> cds_map=mk_cds_map(ql,window,/calib,/clean)

Each step is summarized as follows:

1. cds_files returns CDS filenames for a range of times/dates. This procedure requires that the environment variable CDS_FITS_DATA point to the directory containing the CDS FITS files. An optional input keyword study can be used to search for specific files. This keyword is an acronym for the CDS study, e.g. study=’SYNOP’ . An optional output keyword info returns a string array of observation start times and study names for the files. Currently, the mapping software requires that only maps with similar dimensions can be combined. Since CDS studies can have arbitrary raster sizes, one must be careful not to mix different studies into an array of maps.
2. read_cds reads each file name and returns an array of “quicklook” data structures QL. Each QL structure contains a single raster experiment in several simultaneous wavelengths.
3. mk_cds_map creates maps for selected selected spectral windows. The window argument is a scalar or vector of window numbers. Each window corresponds to a particular wavelength range. If this argument is not included, then the function will prompt for window numbers. The following keywords are also supported:
   • /calib: applies instrumental corrections for background, flatfield, and spectral tilt.
   • /clean: removes data pixels corrupted by cosmic ray hits.
   • /peak: produces an image based on the peak intensity within the window spectral band — default behavior is to sum over wavelength.

The following example, reads and creates an SXT map from an SXT full-frame data file:

IDL> rd_xda,'sfr970407.1229',-1,index,data
IDL> sxt_prep,index,data,outindex,outdata,/register,/norm,/roll
IDL> index2map,outindex,outdata,sxt_map

Details on the use of rd_xda for reading SXT files can be found in the Yohkoh Analysis Guide. The procedure sxt_prep applies instrumental corrections to the SXT raw image that include (among other things) adjustment for spacecraft jitter, roll, dark current subtraction, and exposure normalization. Multiple images can be combined with the restriction that they have the same dimensions. Figure 4 shows a map created from an SXT full-frame AlMg filter image with the following properties:

IDL> help,/st,sxt_map
** Structure <40a74fe8>, 9 tags, length=1048648, refs=2:
   DATA            FLOAT     Array[512, 512]
   XC              FLOAT          -73.8006
   YC              FLOAT          -154.193
   DX              FLOAT           4.91000
   DY              FLOAT           4.91000
   TIME            STRING    ' 6-Jun-1996 19:30:37.000'
   DUR             FLOAT           1.00000
   ID              STRING    'AlMg '
   UNITS           STRING    'arcsecs' 

IDL> plot_map,sxt_map,/log,grid=20

Fig. 4 – SXT map

The above image is plotted using the keyword grid=20. This keyword enables overlaying of a latitude and longitude grid with a grid spacing equal to the keyword value in units of degrees. Setting grid to a negative value will disable gridding, but will enable plotting of the optical solar limb. The same effect is achieved using the keyword /limb.

TRACE files are read and converted to maps as follows.

IDL> read_trace,file_name,dset,index,data
IDL> index2map,index,data,trace_map
IDL> plot_map,trace_map

where the procedure read_trace is a special purpose reader for TRACE files.

FITS files can be converted to maps by using the procedure fits2map . The following example reads and converts a SOHO/MDI full-disk magnetogram FITS file into a map, and plots the result:

IDL> fits2map,'smdi_maglc_fd_19980331_1117.fts',map,header=header
IDL> loadct,0
IDL> plot_map,map

The keyword header optionally returns the string header of the FITS file.

Fig. 5 – MDI map

HESSI FITS files are converted to maps by using fits2map. HESSI images can be created using the HESSI GUI and saved as FITS files

The function drot_map rotates a map using the solar differential rotation formula of Howard, Harvey, and Forgach, Solar Physics, 130, 295, 1990. Since the formula is derived from statistical studies of small-scale magnetic features, it is most accurately applied to photospheric images and is less accurate when applied to transition region and coronal images observed by EIT and SXT, respectively. The following example demonstrates the differential rotation of the above full-disk SXT image over 4 days.

IDL> gmap=grid_map(sxt_map,256,256)
IDL> dmap=drot_map(gmap,4,/days)
IDL> plot_map,sxt_map,/log
IDL> plot_map,dmap,/log,/new,/limb

Fig. 6 – Rotated SXT map

Because solar rotation involves interpolating each pixel to a new location, processing large 512×512 or 1024×1024 images can be very time-consuming and memory-intensive on some systems. In the above example, the SXT map is rebinned to a more manageable 256×256 size prior to rotation. The function drot_map accepts map and duration (in hours) as input arguments. It also supports the following keywords:

• /days: specifies that input duration is in units of days.
• /secs: specifies that input duration is in units of seconds.
• time=new_time: specifies the new time to which the image is to be rotated. In this case, the duration argument should not be used (since it always takes precedence).
• missing=value: specifies the value assigned to pixels that have rotated out of the field or over the limb — the default is 0.

The function drot_map combines regridding, roll-correction, and translation through the following additional keywords:

• space=[dx,dy]: specifies new pixel spacings.
• roll=new_roll: specifies new roll angle (in degrees).
• center = [rx,ry]: specifies new roll center.
• trans = [xs,ys]: specifies translation shifts in the x- and y- directions.
• ncenter = [nx,ny]: specifies a new center coordinate for the solar-rotated image.
• ref_map=ref_map: specifies a reference map to which the input map is to be mapped (i.e, use reference map time, spacing, roll, center, ncenter, etc).

Maps are graphically overlayed using the keyword /over in plot_map . In the following example, an SXT map is contoured over an EIT map.

IDL>plot_map,eit_map,fov=sxt_map,/log  ;-- first plot EIT
IDL>plot_map,sxt_map,/log,/over,/rotate  ;-- then contour over SXT

The fov keyword is a map structure from which plot_map infers xrange and yrange values. In the above example, only the sub-region of eit_map that overlaps with that of sxt_map field-of-view is displayed. This keyword is optional. Different sub-regions can be displayed also via the xrange and yrange keywords.

The /rotate keyword corrects for solar rotation of the overlayed image relative to the first. This correction is important if the time difference between images is more than several hours. The overlayed image can be rotated to a specified time via the keyword time.

Fig. 7a – EIT	Fig. 7b – SXT

Fig. 7c – SXT/EIT Overlay

The following example shows an overlay of MDI magnetogram contours on an SXT observation of flare loops. The example illustrates the use of additional keyword options in plot_map.

Fig. 8 – MDI/SXT Overlay

IDL>set_line_color
IDL>levels=100+findgen(11)*100.
IDL>plot_map,sxt_map,/log,bottom=11
IDL>plot_map,mdi_map,/over,/rotate,/positive,lcolor=5,levels=levels
IDL>plot_map,mdi_map,/over,/rotate,/negative,lcolor=2,levels=-levels  

Each step is explained below:

1. set_line_color allocates a simple color table between 0 and 10, in which color=2 corresponds to yellow, and color=5 corresponds to blue. When using set_line_color, it is necessary that plot_map be called with the keyword: bottom=11 to ensure that the image data are scaled to the correct number of available colors above the 11 colors reserved by set_line_color.
2. findgen is used to define an array of contour levels: 100,200…1000.
3. the SXT map specified in sxt_map is plotted.
4. positive MDI magnetogram values in the map mdi_map are overplotted as blue contours.
5. negative MDI magnetogram values are overplotted as yellow contours.

The final example shows an overlay of a CDS Ne VI map on an EIT 171 map, for a limb active region.

IDL>plot_map,eit_map,/log
IDL>plot_map,cds_map,/over,cthick=2

The keyword cthick=2 specifies a double thickness contour for the overlay image.

Fig. 9a – EIT 171	Fig. 9b – CDS Ne VI

Fig. 9c – CDS/EIT Overlay

Fifth Solar Image Processing Workshop

This series of workshops brings together members of the solar physics and image processing communities to present and discuss advances in solar image processing techniques. The design and implementation of existing algorithms as reliable and robust tools are discussed, as well as automated techniques for processing very large amounts of data.

The fifth Solar Image Processing Workshop (http://sipworkv.sipwork.org/) will concentrate on the role played by solar image processing as we enter the petabyte era of solar physics. For example, the Solar Dynamics Observatory vastly increases the amount of data we have about our Sun, and solar image processing is taking a central role in reducing SDO and other data into useful information about the underlying physics.

Contribution to oral and poster sessions will be solicited in the second announcement, including presentations of image processing methods, software and visualization tools. Contributions involving SDO, PROBA2, STEREO, Hinode, SOHO are particularly solicited.

The workshop will consist of a 3.5 day meeting. In common with previous workshops in this series, mornings will be given over to talks, whilst in the afternoon the workshop will split up into working groups, each of which will cover a given topic in greater depth. Special attention will be given to the results from the Solar Dynamics Observatory mission. The meeting will address topics in the application of computer vision techniques to the challenges of solar physics, such as solar tomography, 3-d reconstruction of solar features, automated feature detection, multiwavelength and motion analysis, blind source separation, and distributed data analysis infrastructure.

For the latest updates please consult the meeting website http://sipworkv.sipwork.org/.

LOC Chair: Andre Csillaghy, University of Applied Sciences Northwestern Switzerland
SOC Chair: Jack Ireland, ADNET Systems Inc./NASA GSFC

JHelioviewer

Festival

Solar Weather Browser