Subject: Re: JEM-X mosaic - wishlist


  Dear Niels and Niels Jørgen -

  Roland seems to be absent today, so I'll try to give a quick answer
before discussing with him further tomorrow. A lot of the functionality 
you describe below is actually realized in image_mosaic as long as
it uses data output from the normal software and thus containing
all sorts of useful, standardized information in its headers.


Niels Lund wrote:
> 
> We assume that the tool will be working from a list of basic image
> files [...]

  This is for me already a too specific assumption. The current
image_mosaic uses an Index of images (or an observation group
from which the Index then is derived internally) that then by default 
allows all sorts of smart selections. In this way the user can always
chose on the fly or create subsets of useful data very quickly
and easily (e.g. by using fcopy on an existing Index). The overhead
in creation is larger, but the use afterwards much smarter.

  Evidently, one can build an Index from a list of DOLs, or do 
something similar within the tool if one ones to treat data not
dropping out of the pipeline. Note that this assumes well-organized
images with corresponding data structure and Index templates.


> 
> 1) Specification of the output image.
>    [...]
>    - Quality criteria to be applied to each output pixel before the
>      completed image is output. (The purpose is to eliminate noisy
>      regions of the image). We can think of the following criteria:
>         - minimum effective exposure
>         - maximum relative rms
>
  All but the quality criteria do already exist, as far as I know;
they are an interesting point.
 
> 2) Selection of input images to include.
>    - instrument selection (JEMX 1 or 2 or both)
>    - energy range (energy band)
>    - time period
>    - pointing restrictions
>    - minimum effective observation time
>    - type of input image (raw_mosaic, no_source, source_only ..)
>
  Once you have a well-organized Index as input this is mostly trivial to 
implement, actually a cfitsio selection string will do, though for
some selections special parameters may be more user friendly.

  Naturally you can also open each image, look at its properties
and then chose. My point is that we have Index structures especially
to facilitate this kind of selection and it is probably better spent
effort to build an Index for input than to add lots of specific code
to the tool.
 
> 3) Input image processing and pixel selection
>    - image filtering (removal of large scale trends)

  Why would this be done during mosaicing? Just curious ...

>    - zero offset to add to variance map at pixel level
>    - maximum off-axis angle to accept at pixel level
>    - minimum variance value to accept at pixel level
>    - minimum sky exposure to accept at pixel level
> 
  Here I think would be some real need for added functionality
and reasons to discuss how this would be best implemented.

  Another point - from my discussions with Jérôme today it seems
to me that we would gain a lot if we could do the following:

* Define a common image size for all 'branches' of JEM-X imaging
  (I would assume with finer pixels than 4'*4') and deliver a common
  vignetting model with that resolution.

* Give Niels Jørgen the time to write out variance maps with his images,
  or maybe combined "weight factor" maps taking into account variance
  and vignetting. If I'm not mistaken, image_mosaic could make much
  better mosaics _already_ if we had this kind of information.


  regards,
  Peter