I am hoping someone might be able to shed some light on a curious problem that appears in the merged orders of eShel spectra processed in ISIS. The artefacts appear as 'bumps' at the points where individual orders meet in a merged spectrum and are particularly evident towards the red end, and almost completely absent at shorter wavelength merge points.
I've attached some screenshots that show the effect: a merged spectrum where you can clearly see the 'bumps', and a couple of screen shots that show unmerged orders plotted adjacent to one another that show the cause. The effects are almost absent at the 'blue' end, but increase to the extreme at the 'red' end and appear as pronounced deviations at one end of a typical order.
I have been fortunate enough to have had access to several eShel spectrographs and have been able to rule out hardware issues by swapping out fibres, calibration units, camera lenses and cameras as well as other items in the eShel package. I've also tried various flat lamp exposures as well as numerous permutations in both acquisition and processing in ISIS.
I am now at the point where I'm hoping that someone with an eShel might be able to shed some light on this, perhaps taking a closer look at unmerged orders in their own spectra processed in ISiS to see if the issue exists elsewhere (I have seen varying degrees of the problem in the eShel spectrographs that I've tested through ISIS processing).
Any other thoughts would be gratefully received.
Paul
eShel merged orders issue
-
- Posts: 103
- Joined: Tue Jun 24, 2014 5:08 pm
- Location: Perth, Western Australia
Re: eShel merged orders issue
Hi Paul,
Because you excluded almost all "hardware" issues, can you give it a try to process your data with a different software reduction program?
I am thinking of Demetra for eShel.
It is a while ago that I used Demetra for eShel, since I have no longer access to an eShel spectrograph, but I remember that there were issues too with stitching in the early beta versions of Demetra for eShel. However, Alain an François from Shelyak solved these problems very well in the final release.
If you feel unconfortable with Demetra for eShel, I am willing to try the reduction for you if you provide me your necessary raw data.
Best regards
Hugo
Because you excluded almost all "hardware" issues, can you give it a try to process your data with a different software reduction program?
I am thinking of Demetra for eShel.
It is a while ago that I used Demetra for eShel, since I have no longer access to an eShel spectrograph, but I remember that there were issues too with stitching in the early beta versions of Demetra for eShel. However, Alain an François from Shelyak solved these problems very well in the final release.
If you feel unconfortable with Demetra for eShel, I am willing to try the reduction for you if you provide me your necessary raw data.
Best regards
Hugo
-
- Posts: 103
- Joined: Tue Jun 24, 2014 5:08 pm
- Location: Perth, Western Australia
Re: eShel merged orders issue
Thanks Hugo,
Demetra has been suggested, and it is certainly on my list of things to try. I was secretly hoping that another eShel user or two had seen this specific issue.
Much appreciated,
Paul
Demetra has been suggested, and it is certainly on my list of things to try. I was secretly hoping that another eShel user or two had seen this specific issue.
Much appreciated,
Paul
-
- Posts: 1267
- Joined: Thu Sep 29, 2011 6:35 am
- Location: Rhône Alpes FRANCE
- Contact:
Re: eShel merged orders issue
Hi Paul,
There may be several reasons for this effect on the continuum of the merged spectrum:
- The number of flats and their ADU levels (many flats are needed, at least thirty or so, with a level of around 50,000 ADUs).
- If it's a CMOS sensor, apply the CMED algorithm to take into account the telegraphic noise of this type of sensor.
- instrumental response must be made at the same height as the target
- When setting up each order, it's important to define the X position of the areas to be processed order by order
The fact remains that there may be residual separation of each order, as can be seen on this cropped spectrum, where each red arrow indicates the fusion of 2 orders.

and the whole merged spectrum taken in automatic mode reduction (no manual processing with ISIS in remote conditions)

There may be several reasons for this effect on the continuum of the merged spectrum:
- The number of flats and their ADU levels (many flats are needed, at least thirty or so, with a level of around 50,000 ADUs).
- If it's a CMOS sensor, apply the CMED algorithm to take into account the telegraphic noise of this type of sensor.
- instrumental response must be made at the same height as the target
- When setting up each order, it's important to define the X position of the areas to be processed order by order
The fact remains that there may be residual separation of each order, as can be seen on this cropped spectrum, where each red arrow indicates the fusion of 2 orders.

and the whole merged spectrum taken in automatic mode reduction (no manual processing with ISIS in remote conditions)

LHIRES III #5, LISA, e-Shel, C14, RC400 Astrosib, AP1600
http://o.garde.free.fr/astro/Spectro1/Bienvenue.html
http://o.garde.free.fr/astro/Spectro1/Bienvenue.html
-
- Posts: 1952
- Joined: Mon Sep 26, 2011 4:41 pm
- Contact:
Re: eShel merged orders issue
Hi Paul,
I don't know the cause but It seems to me that it is not a stitching problem but a problem with the individual orders which show flip ups at the edges. The stitching is trying its best to fit to include those edge effects. A problem with the blaze profile in those regions ?
Cheers
Robin
I don't know the cause but It seems to me that it is not a stitching problem but a problem with the individual orders which show flip ups at the edges. The stitching is trying its best to fit to include those edge effects. A problem with the blaze profile in those regions ?
Cheers
Robin
LHIRES III #29 ATIK314 ALPY 600/200 ATIK428 Star Analyser 100/200 C11 EQ6
http://www.threehillsobservatory.co.uk
http://www.threehillsobservatory.co.uk