The seeing was not great tonight but at least there was something to see other than cloud Between imaging Saturn and Jupiter we went past Neptune for a look. Here is what we saw.
I’m puzzled why the apparent diameter of Triton is so large compared to Neptune, nearly 25%. At that distance it should be not much greater than a dot or Neptune should appear larger. Am I missing something here? I can only put it down to seeing.
I’m puzzled why the apparent diameter of Triton is so large compared to Neptune, nearly 25%. At that distance it should be not much greater than a dot or Neptune should appear larger. Am I missing something here? I can only put it down to seeing.
Thanks to all for your kind comments.
Astro744 - you are absolutely correct, the size of Triton is incorrect. There are two reasons for this. One is the use of a small aperture scope means that the Airy disk exaggerates the size of small objects. In this case the apparent diameter of Triton at that time was 0.13 arc seconds & the Airy disk for a 6" scope at 560nm is 0.939 arc seconds. This considerably exaggerates it's size by a factor of approx 7 times. The second reason was we made a mistake in processing as when we created the mask for the increased exposure of Triton, we didn't allow for the bloat created. We were just rushing a bit as we had been happy to actually capture Neptune close to opposition (17/9). Considering the weather we didn't think it was going to happen and this is probably as close as it will get. We have attached a corrected version of the image with Triton closer to an appropriate size compared to Neptune. The actual ratio is approx 18:1.
Thanks to all for your kind comments.
Astro744 - you are absolutely correct, the size of Triton is incorrect. There are two reasons for this. One is the use of a small aperture scope means that the Airy disk exaggerates the size of small objects. In this case the apparent diameter of Triton at that time was 0.13 arc seconds & the Airy disk for a 6" scope at 560nm is 0.939 arc seconds. This considerably exaggerates it's size by a factor of approx 7 times. The second reason was we made a mistake in processing as when we created the mask for the increased exposure of Triton, we didn't allow for the bloat created. We were just rushing a bit as we had been happy to actually capture Neptune close to opposition (17/9). Considering the weather we didn't think it was going to happen and this is probably as close as it will get. We have attached a corrected version of the image with Triton closer to an appropriate size compared to Neptune. The actual ratio is approx 18:1.
Thanks to all for your kind comments.
Astro744 - you are absolutely correct, the size of Triton is incorrect. There are two reasons for this. One is the use of a small aperture scope means that the Airy disk exaggerates the size of small objects. In this case the apparent diameter of Triton at that time was 0.13 arc seconds & the Airy disk for a 6" scope at 560nm is 0.939 arc seconds. This considerably exaggerates it's size by a factor of approx 7 times. The second reason was we made a mistake in processing as when we created the mask for the increased exposure of Triton, we didn't allow for the bloat created. We were just rushing a bit as we had been happy to actually capture Neptune close to opposition (17/9). Considering the weather we didn't think it was going to happen and this is probably as close as it will get. We have attached a corrected version of the image with Triton closer to an appropriate size compared to Neptune. The actual ratio is approx 18:1.
So you shoot two different exposure times and make a mask in Photoshop? Is that the process?
You don't need a second over exposed image. We use 16 bit SER files for capturing which have a lot of bit depth for each pixel and the moons are just buried low down in the original correctly exposed image. We use GIMP but Photoshop will do. So just make a duplicate layer of the original stacked and sharpened image. On the top layer add an alpha channel and change the exposure level until the moons are visible, you don't need to go overboard here, its just until the moons are visible. It often doesn't take much to bring them out. Then place a feathered mask around the moons (this is the step that we did incorrectly on the first version) allowing for any bloat from the over exposing. Invert the mask and delete the selection. And there is your image.
8 bit videos are fine for the planets (and extracting Triton).
Thanks Andrew.
We are sure that you are correct but 8 bit high speed videos unfortunately don't serve much use in our situation. We do use 8bit high speed videos extensively doing mono imaging of the sun. In our planetary set up, the limiting FPS factor is usually exposure. With our smaller aperture there is just not enough photons to use exposures short enough that the high speed 8 bit videos are of benefit. Also we are capturing more pixels with the ASI178 than the ASI224 which means that file size and data transfer rate become an issue. With colour videos ironically 8 bit videos are larger files than 16 bit videos. This is due to AVIs having a separate byte for each colour channel per pixel therefore giving 24 bits (3 bytes) per pixel. Whereas the 16 bit SER files are undebayered and only have a single byte (16bits) per pixel, two thirds of the size of the AVI files.
Hope this makes sense. We were just saying what our set up is and not suggesting that it was the best or only approach.
You should be capturing your colour videos in non-debayered format, this is how (nearly) everyone else does it. In fact, Firecapture actively warns you against transferring debayered videos as the transfer rates are reduced and filesize is 3x larger, as you say.
Autostakkert has a unique "drizzle" debayering algorithm which will fill in the colour pixels without using a lossy algorithm as most other programs do. This technique is much preferred over using an algorithm in the capture software and transferring more data than required.
While the ASI178 does have a larger sensor with more pixels, you could also be recording a smaller FOV, Firecapture has a "cut-out" box which you can draw around the planet and it will only record the smaller cutout section. For instance, when I capture Jupiter I usually record a 400x400 pixel box at 150 fps for 3 minutes in raw8 (undebayered) format, and my filesize is around 4 GB. You can capture undebayered video in ser or avi format under Firecapture.
If you like, you can watch me capture and process Jupiter, Saturn and Neptune in Firecapture with my C9.25" SCT, 2.5x powermate and ASI224MC here. https://youtu.be/yUPhM2kdxNI?t=81
You should be capturing your colour videos in non-debayered format, this is how (nearly) everyone else does it. In fact, Firecapture actively warns you against transferring debayered videos as the transfer rates are reduced and filesize is 3x larger, as you say.
Autostakkert has a unique "drizzle" debayering algorithm which will fill in the colour pixels without using a lossy algorithm as most other programs do. This technique is much preferred over using an algorithm in the capture software and transferring more data than required.
While the ASI178 does have a larger sensor with more pixels, you could also be recording a smaller FOV, Firecapture has a "cut-out" box which you can draw around the planet and it will only record the smaller cutout section. For instance, when I capture Jupiter I usually record a 400x400 pixel box at 150 fps for 3 minutes in raw8 (undebayered) format, and my filesize is around 4 GB. You can capture undebayered video in ser or avi format under Firecapture.
If you like, you can watch me capture and process Jupiter, Saturn and Neptune in Firecapture with my C9.25" SCT, 2.5x powermate and ASI224MC here. https://youtu.be/yUPhM2kdxNI?t=81
Hope this helps,
Andrew
Thanks Andrew. It all helps.
There is a little bit of horses for courses though.
1. Firecapture, whilst available for Linux, no amount of coaxing makes it provide as high a frame rate as the ZWO ASICAP software, so we don't use it.
2. The 178 also has smaller pixels than the 224 and therefore has less arc seconds per pixel. This means that regardless of the ROI there are more pixels for a given capture object. This is deliberate and exactly what we are after.
3. We do always use a ROI.
4. SER files are un-debayered.
5. We would not be able to capture at 150FPS simply because this means our exposure time would have to be equal to or less than 6.667ms, which even at maximum gain, is not enough for Saturn for instance with the 6" scope.
6. We have not seen un-debayered AVI files. We only capture monochrome AVI files. When test capturing colour AVI files with ASICAP, they have always been RGB. We'll have another look and test the files again. There has been a recent update so there maybe some changes.
Thanks again for the interesting discussion.
Some of your statements appear to be specific to ASICAP only, they are not correct in general. In general, both SER and AVI movie formats are able to hold debayered and undebayered frames, it is not specific to the file type. Firecapture for instance can create both ser and avi files in debayered and undebayered formats with 8 bit resolution. It can only create undebayered frames with 16 bit resolution. It sounds like ASICAP only allows you to create 16 bit undebayered frames in ser format, and debayered avi files in 8 bit resolution. This is unusual.
SER files include information about the bayer pattern used for the frames in the file header, avi files do not. So when Autostakkert reads a ser file, it reads the header to find out which debayer pattern to use and so always gets it right. However in the case of avi files, AS!3 has to make a guess at the bayer pattern, it usually gets it right but not always. This is not an issue, if you know the correct bayer pattern to use for your camera (and it's usually pretty easy to tell if it's wrong by the colour cast), then this can be manually selected and AS!3 will not have a problem from then on.
The best format to use for planetary imaging is to create undebayered 8 bit ser (or avi) files. Unfortunately for you it appears that ASICAP is unable to create this format, Firecapture and SharpCap can. For people using these capture programs this is the recommended format, not 8 bit debayered or 16 bit undebayered.
In terms of your camera pixel size, best practice is to match the focal ratio of your system to the pixel size of the camera. The rule of thumb is to set your focal ratio to be around 5x the pixel size of the camera in microns in good seeing, this allows you to capture the optimal resolution for the camera. So the optimal focal ratio to use with the ASI178 is around f/12, while the ASI224 is around f/19. Capturing at these focal ratio puts the same number of pixels on the target, there is no advantage in using the smaller pixels. Smaller pixels are in general less sensitive then larger ones (simply because they are sample a smaller surface area) so there should be no impact on the amount of light collected. Sampling at too high a focal ratio for the camera means that the image will be dimmer than optimal and you will not be getting any more resolution than the camera will allow. There is a mathematical "proof" of sorts on the Cloudy Nights website, backed up by better and more experienced planetary imagers than I. https://www.cloudynights.com/topic/4...-which-barlow/
I capture Jupiter at 150fps and Saturn at 100 fps using my ASI224MC at a focal ratio for around f/21, or 5.6x the pixel size of the camera. The size of the OTA doesn't matter, it's all about the camera sensitivity and pixel size.
Between imaging Saturn and Jupiter we went past Neptune for a look. Here is what we saw.
