han59

Great. I hope you have clear sky soon and can test it's performance! The lack of information makes many wondering.....

Hello Paul,

I'm playing a little more with Astrometrica. What is very strange is that when I solve your image in ASTAP (subsample force on 2) and then feed it to Astrometrica, the solution is read correctly and data reduction works straight out of the box. No rotation has to be entered. So the format of keywords CRVAL1, CRVAL2 data  in new_V image is a little different or for an other unknown reason only readable by Astrometrica if written by ASTAP. If I modify keywords OBJCTRA/OBJCTDEC or RA/DEC keywords in an ASTAP solved file nothing changes but when I modify CRVAL1/2 Astrometrica adapts. So this proves that reading keywords CRVAL1/2 is available and has preference in Astometrica!

Quote

 

SOFTNAME= 'SWarp   '

CRVAL1  =   2.815575885946E+02 / World coordinate on this axis 

CRVAL2  =  -1.019726821377E+01 / World coordinate on this axis 

 

ASTAP:

CRVAL1  =  2.815575679693E+002 / World coordinate on this axis

CRVAL2  = -1.019724485224E+001 / World coordinate on this axis 

 

ASTAP write the solution to the FITS header both in the new convention (CRVAL1/2, CD1_1, CD1_2....)  as the old convention (CRVAL1/2, CDELT1/2, CROTA1/2. The old convention is partly readable by Astrometrica.

So to improve your work flow, it could help to find out how to make the FITS files readable by Astrometrica. Have a look what happens with the file header if you use in Astrometrica in settings "Auto-Save FITS with WCS". If your desperate, I could help with a conversion routine to update existing headers to the old convention.

Han

Okay, I did some other tests. Astrometrica writes the image center and rotation to a solved FITS file using keywords OBJCTRA and OBJCTDEC and more or less obsolete rotation keywords CROTA1 and CROTA2. Unfortunately only the position is read back by either OBJCTRA, OBJTDEC or the RA, DEC keywords but not the rotation angle.  Awkward.

The Astrometrica solver is very limited and can't process any large position offset of maybe 10 arcminutes and no rotation angle. Easiest way to process would be to solve the image in nova.astrometry.net or ASTAP and then to copy/paste the exact position into Astrometrica and if solving fails enter the rotation NEGATIVE as indicated below.

The flip vertical/horizontal settings are also essential for solving. See previous posting

It is pity the standard WCS solution keywords  (CRVAL1, CRVAL2, CD1_1, ......,CD2_2) are not read and used as a starting point for solving. That would be a tiny mod in Astrometrica.

Han

Okay I have it now running. The pixel size should be BEFORE binning. So FL=2600mm, pixel size 3.678 micrometer

This took some time. I loaded first an image of the Coathanger before it came clear. Also the flipping setting Astrometrica is confusing.  For an image North up, East left, the setting in Astrometrica for vertical flip should be checked.

What is also important it reads RA and DEC keywords. This is the position of the MOUNT.  The WCS solution position is written to keywords CRVAL1, CRVAL2.  Copy the position of CRVAL1, CRVAL2 keyword to keywords RA, DEC. Then they will be read in Astrometrica or enter the position manually in Astrometrica

Same asteroid as in ASTAP, T9364 seams equal to 299364:

Some important settings:

Not sure if below are the best settings, but it worked for me:

Okay did try image new-V in Astrometrica. I assume the focal length is 2600 mm, pixel size 7.356 micrometer. But failed to do the Data reduction.  What helps with the initial position is to write the following in the header:

RA      = '18 46 13.8'   
DEC     = '-10 11 50'

Han

I can find only one minor planet in the image new-V with a magnitude 20.1. The limiting magnitude of the image is about 17 so it is not visible. The image is oversampled so the limiting magnitude is relative low.

I experimented with a trial license twice which are now expired. Only during the second trial, I succeeded in getting it running.  What I remember you have to set the solving parameter very close to the correct values. It will ignore the WCS header.

No problem to try is once more on my laptop (different computer), but can you share a better image then "new-V" ?   To identify and measure a minor planet position you wil be faster with ASTAP which will use the existing WCS solution in the header.

Han

I experimented with astrometrica some time.  The solving in astrometrica is very tricky to get working and not very forgiving. I have struggled with it too. Once you have it working, the automation for measuring and reporting of minor planets is superb.

Han

Yes no problem. It will easilly detect a few hunderd stars and have enough redundancy.

Han

The mount is still on sale as Trident mount for US$ 4995,-  I assume this webpage has not been updated since 2020. The mount has disappeared from the JTW webpage. After years of waiting still no first light image. We have no idea if the mount is performing.  Note this mount is based on early version of  a German design. They split due to disagreement years ago. The German group is still developping further. See Das OGEM. "Das OGEM" will go on sale in the future.

Screenshot of the JTW mount (OGEM, now Trident) :

As pdf:trident-ogem mount.pdf

Maybe a coincidence, but I made ASTAP a little faster. I noted a flickering progress indicator at the Windows taskbar and removed an unnecessary action. ASTAP v09.526b : http://www.hnsky.org/astap_setup.exe

I would love to make the application faster but that is not easy. Most of the time the program is for stacking simple shifting data around. Multitasking that in separate tasks in not easy. ASTAP is a single core application. But the speed test of @Festoon indicates that it is performing  okay against DSS which is a multi core application. I'm a fan of efficient coding rather the brute force solutions.

For sigma clip average method it has to load each image three times. That is not so efficient but the program memory usage is as a consequence  very moderate. Only for ctrl-Z action it keeps up to 3 images in the memory. Stacking 1000 images or more is not problem.

And I'm programming just for the fun. 

It is clear sky here so time to get the equipment running.

Han

Problem fixed download at: : http://www.hnsky.org/astap_setup.exe  Feedback is appreciated.

almcl,

30 minutes is very long. Especially colour  and images with large dimension take time.  Stacking 46 mono images  2328 x  1760 pixels, method Sigma Clip takes about 115 seconds. I have them on a solid state disk. Have a fast disk system helps. ASTAP doesn't keep the images in memory but loads them from disk. That is a design choice to avoid memory problems. 

Han

Unfortunately there is a bug in the flat&dark selection in this development version. I will fix it this afternoon.

Han

The first new ASTAP version 0.9.526 is ready. 

1) Master flat and master dark can be created based on date.  So you can add all flats to the flats tab and per day a master flat will be created. This is activated by option "classify by date for master creation"

2) For the light the master dark and flat with the nearest date will be selected.  This will happen if more then one compatible flat or dark is found.

Download developments version: http://www.hnsky.org/astap_setup.exe  Feedback is appreciated.

Han

Yes that is correct and is one option.

Note that I will have later today a new version which will select the most suitable master flat and master dark based on the time in the FITS header. So you have to a prepare master flat for each night. So it is a little different then DSS where selection is folder/directory based. ASTAP looks only to the FITS header(s)

What you could do now is to calibrate only. The dark and flat-dark master is applied to the light and the light is stored as calibrated.  For each night series you do that with the appropriate dark and flat. Then just stack the calibrated lights.  The calibrated files and up in the results tab and can be copied to the lights tab again for stacking.

When your imaging with a mobile setup and disassemble the setup at the end of each night it could be better to take flats each night.

I could modify ASTAP to look for all compatible flats in the flat tab. If two compatible flats are found (same dimensions, and filter if selected), take the flat with the closest date. That would not require an new menu option and will work automatically. The user  has just to add the flats to the flat tab.

At the moment it just takes the first flat found. Same action could be applied for darks.

Han

20 hours ago, festoon said:

I'm still to find a way of applying different flats to datasets from different nights using ASTAP. Using DSS this can be done by grouping data. To me this is an advantage of DSS, unless it can be done in ASTAP.

There is no clear way at this moment.

Would the flats be very different?  I have a fixed setup, so I would use the same flat for lights of different dates.  The only difference could be a dust particle added between the image sessions. I have added lights from several years together and didn't find experience any problem.

At the moment you can classify the flats on filter used. So the red flat is used for the red lights and so on. What I could envision is a "classify" on flat date.  An other way would be to stack each night separately and then stack the different nights  again together, but then sigma clip will not work so well.

So a classify on a date for a flat could be an idea, but is this really required?  I make flats only once in a few months. An what would be the time span to classify, one Julian day, one week, one month? Or classify them by selection. That would be tricky to realise.

Han

Command-line programs are not my favorite but you could share the median and mean stacked sample images.

A practical test would be interesting.  Just see what the photometric standard deviation is for a reference/check star over a longer period.  Any long image series will do.  I have no problem to measure the standard deviation,  but I don't have a program which can stack median.

Lets say you have 60 images from one night. Create 20 images using median and 20 images using mean from  image 1,2,3 and 4,5,6.... sorted in observation time.

Han

In general taking the median value brings more noise to the signal compared with average (mean).  For photometry average (mean) will be better.

Assuming you want to avoid trailing the median value will ignore a part of the signal especially around the stars because they move around.

Han

For stars x,y positions only you could xy files from Astrometry.net or use the ASTAP command-line option -extract which give the x,y, snr and hfd values of the stars. See http://www.hnsky.org/astap.htm#astap_command_line  

Han

For testing of my own software,  I'm looking for a series of DSLR images  of a variable. Is there anybody who could provide me with one or more image series for testing? The DSLR or OSC type of images are required to test the extraction and processing of the green channels correctly.

Thanks, Han

After so reading some discussions and guides, the most convenient method to process an DSLR image for photometry would be to combine each 4 raw Bayer pixels R, G1, G2, B into one RGB pixel.   But the combining should not happen as the normal Debayer method since the luminance is adjusted using the neighbour pixels. So the RGB green would be simple (G1+G2)/2 and R and B stay the same . That would halve the image dimensions in pixels but preserve the colour information for photometry.  This would intuitive be a better method then split an image in four seperate images called R, G1, G2, and B. But the software has to be able to process the RGB image and select the colour of interest, most likely green as TG.

Han

Later,

the only problem is these images while photometric correct look weird. Three method without halving the image dimensions or split them in four:

1) This is what you get when you when you spread the R,G,1, G2, B as RGB colours over each Bayer 2x2  matrix.  The stars colours tend to follow the Bayer matriz. So top-left & top-bottom =green, top-right=red, bottom-left=blue.

2) And this is what you get when you spread the R,G,1, G2, B  as RGB over 4 pixels in one direction:

3) An other possibility is to just to colour each pixel according the Bayer pattern. But that looks most weird and green is by definition twice as strong:

The advantage is that all information stays in one image and is photometric correct. But no standard software will be able to process it.

Probably it is better to split the raw images in three separate files raw red, raw green combined and raw blue at half dimensions of the original file and process them separately.

As a programmer I'm currently working on new the photometry routine in ASTAP. There are two methods  I'm considering for DSLR:

 1) One is to extract from raw the two green pixels of each 2x2 bayer matrix and combine them. But since you uses only 50% of the  of the image you have to assure that the star size (HFD, FWHM) is much larger then a pixel size. If the peek of the star is  at the blue or red sensitive pixel you will get an measuring error.  So having a slightly de focused image seems important.

2)  The second method is to de-bayer and then extract the green. Probably less reliable but at least the luminance channel is correct for sharp images

I assume 1) is the best as long your a little out of focus and the stars are over-sampeled. But up to now I could not find a proper evaluation

I your member of the AAVSO you can use the free online VPHOT tools . The videos are impressive but haven't worked with the online tool itself.  For automated photometry, the Lesvephotometry program works very well. But you have to buy a Pinpoint solver license. You can work/experiment 60 days or so using a Pinpoint trial license.

Han