Jump to content



  • Posts

  • Joined

  • Last visited

Everything posted by han59

  1. The image have a lot gradient do to over-correction of the flat. The bias /flat darks where missing during stacking and probably causing this effect. I tried to correct that with an artificial flat and some other tools with limited success. The M45 tiles are difficult to correct. Anyhow I used them to test the tool "ring equalise" in ASTAP, tab pixel math 1 and made some improvements for next ASTAP edition. Below the result before I gave up. It is maybe a little better but still not good. For a good result "flat darks"are essential. ICE in general will produce better result but I don't know how good it is with gradients. Han
  2. Have you tried in ASTAP the option crop images and maybe "Merge overlapping background=off"? Probably it also works better if you equalize the background of each image before making the mosaic. For testing/experimenting, if you could share the 4 or 6 raw images, I could try to get it better. An alternative for making a Mosaic is to use the free Microsoft program ICE which is discontinued but still can be found at some unofficial places. Han author ASTAP
  3. You should have installed index files down to about 20% or 30% of your field of view. Which index files do you have and what is the field of view? What configuration settings for solving are set? What does the log say?
  4. If you upload it to Youtube it is convertered anyhow.
  5. The light pollution will not make a difference. Note it will only effect nebula. Just try it. As soon you say layers in faint part of nebula, you know you have to switch to processing in floating point. Just one more remark: The only reason why you don't see layers in the 8 bit display or 8 bit jpeg is that the image is properly stretched. Nebula in the sky will increase the ADU's in your camera with only a few ADU's. Your 16 bit astro image has a huge range. Stars will generate a lot of ADU up to saturation but you nebula will generate maybe 4 ADU's max. One you stretch the 16 bit (stacked)image, these 4 ADU's are equivalent to 2 bit or 4 levels. After stretching the 16 bit image to 0 ... 255 your nebula has maybe levels 0, 4, 8, 12 and 16 and nothing between. So the nebula will appear as having layers. If you would process in floating point values, the nebula will have any value between 0 and 16 and the nebula appear as being smooth. Han
  6. The bit depth increases with stacking. If you combine 2 pixels of value 101 and 102 you get 101.5. How do you want to store that? In 16 bit your image will show strange pattern in grey level. Especially because faint nebula are in the low range of your 16 bit. Nebula will look like this (without the numbers)
  7. The dimensions in pixels so width x height is too low. So in most cases the binning is too high. Keep the final image dimensions above 1280x960 pixels. So don't bin more then 2 or if you have a small sensor keep binning at 1 or better 0 (= auto) Han
  8. Raw images are displayed grey scale. That is normal. The pixels have green, red and blue filter in front in a so called 2x2 bayer pattern. From this single colour so grey scale image is later a colour image created by a process called de-mosaic or de-bayer. The reason this is not done immediatly is that the are several methods for and some don't work good in astronomy. Second reason is that the dark has to be subtracted prior to de-mosaic processing. Han
  9. Alain, For this topic a guiding graph in arcseconds will be most interesting. Furhermore slew to accuracy. So if you slew 90 degrees or so in RA, are you on the correct location? Many times in the past years performance test data was promised but never released and excuses ware made. So many readers are very curious how this mount performs in your setup. There is somehow a cloud of secrecy around this mount. If it performs well, there is no reason not to release some performance data. This was specified on march 2018 or earlier: Han
  10. Does it work? Looking to your picture, your polar axis seems to be set for the northern part of Europe. Not for the south of France ???
  11. There is a 30.000 object deep sky database included. The object outlines are plotted if selected. See screenshot below. Select objects or all. The exposure time doesn't do anything at the moment. Unfortunately the Ascom Sky Simulator camera reads the images produced by the program only in 8 bit. That give doesn't give much range for playing with exposure intensity without compromising the solvability of the image. So for the moment the exposure time is ignored. You could try the deep-sky-survey download option but that could be a little slow. Keep the image size in pixels small or be patient. Use here exposure times of 10 seconds or more since downloading of the images takes time an the image should be ready when the camera is read out. Han M42 view with object selected.
  12. Great. I hope you have clear sky soon and can test it's performance! The lack of information makes many wondering.....
  13. 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! 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
  14. 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
  15. 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:
  16. 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
  17. 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.
  18. 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
  19. 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
  20. Yes no problem. It will easilly detect a few hunderd stars and have enough redundancy. Han
  21. 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
  22. 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
  23. 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
  24. Unfortunately there is a bug in the flat&dark selection in this development version. I will fix it this afternoon. Han
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.