John,

This isn't something I've done for many years... however, since nobody
else has spoken I'll try to help.  There may be other algorithms
developed in recent years.  If there's one in particular you'd like to
recreate and it's not as described below, please mail again with
details and/or a citation.

> I'm trying to build a pipeline for wide-field data reduction and at
> the moment I'm dealing with the problem of fringes subtraction.

Have you seen ORAC-DR?  This offers the infrastructure freeing you to
concentrate on the details of the processing steps.  It's modular too,
making it easy to insert extra steps.  www.oracdr.org.

As ever much depends on the details.  I take it that you want something
automatic, i.e. no manual intervention.  It does depend what calibration
data you have.  Will your pipeline have fringe maps made by combining
lots of frames say at the start of the night?  Are the fringe maps
stable?  Can you use one from an earlier night?  Do you need to process
in realtime?

The general principle is to make a `superflat'.  This superflat often
reveals gradients in the background (e.g. from light leaks or a nearby
very bright source) or the fringe pattern.

A superflat is created by combining for each filter many flatfielded and
normalised empty or sparse fields, or even the whole night's exposures.
I wouldn't recommend the second unless the frames are devoid of bright
stars and large (with respect to the the frame size) galaxies.  See
CCDPACK:MAKECAL and the like.  You must filter well to reject outliers,
say clipped mean to get a mode, or a median filter if the density of
sources isn't high.  My preference is to pass the superflat frames
through (S)EXTRACTOR first to identify the sources to a faint isophote
and then, using the created catalogue, mask the sources before combining
frames.  That might be trickier if you have strong fringes;
you'd make a first estimate of the fringe pattern without object
masking, apply the fringe correction, mask the objects and repeat.  If
the fringe signal is weak you could want to mask first.

The next step is to extract the fringe pattern from the superflat, or
put another way take out the sky background and large-scale variations.
Some people also like to apply a large-kernel smoothing filter
(KAPPA:BLOCK) to the superflat and subtract the unsmoothed superflat to
make the fringe map (KAPPA:SUB).  It's a form unsharp masking.  SURFIT
could work too if you choose the parameters wisely, i.e. not track the
fringes.  Like many problems you have to experiment and prototype with
actual data to discover what works best in practice.  There's a new task
in the new package CUPID, called FINDBACK that might do a good job too.

Since the amplitude of fringe pattern scales with the sky background you
could determine a representative sky level for a frame (perhaps
EXTRACTOR then KAPPA:HISTAT and PARGET to obtain the median value) and
likewise for the smoothed superflat.  Then you subtract the fringe
pattern times the ratio of these two representative sky levels
(KAPPA:MATHS).

If you were looking for a single routine for de-fringing in Starlink
unlike IRAF, I think you'll be disappointed.  Even CCDPACK does not have
one.  There are too many variables.  Thus in Starlink our approach was
towards elemental applications that could be strung together to achieve
complex reductions.  There was an interactive task in the original
Starlink Interim environment over two decades ago called FRINGE that let
you select a clear region of sky in which to scale the fringe pattern
rather than using a global frame value.  This approach is no good if you
want an automated pipeline.

> Also I want to ask if it is harmless (and of course if it is better) to
> subtract the sky(after fringe correction) using Kappa's SURFIT
> before any photometry mesurements take plase.

It does depend on what you're going to do with the final reduced frames
and the analysis software applied to it.  If you want to measure the
brightnesses, sizes, and shapes of the objects, then EXTRACTOR has a
SURFIT-like sky-estimation step so that it knows the local sky levels.
PHOTOM works in relatively small areas and it determines the sky from an
annulus about a source or from specified regions.  Now if your
photometry package divides by the sky, as one widely used package from
Oxford did, then removing the sky would not be a good idea.  I generally
don't use SURFIT in that way.

I hope that you can follow my English and the above helps.  I've not
gone into great detail about commands and parameters because I don't
have enough information about your particular data, requirements, and
analysis goals.

Malcolm Currie