TallFurryMan wrote: Yes, sorry, I think I completely missed your point. One question though, what is the data structure of the FITS file that is captured when you configure your camera as uncompressed colored full frame? In other words, what is in the FITS header of the file?

-Eric

Thanks, Pit, makes sense. I was wondering, though, how others here are handling the processing of their OSC images.
Nonetheless, processing at acquisition time is exactly what is being done when acquiring and saving the FITS file as RGB24, i.e. reduction of the color information to 8 bits per channel, while maintaining full resolution. I realize that processing through nearest neighbor interpolation for a 16 bit image would be inferior to just saving the non-debayered raw image and that this kind of processing could still be done afterwards. I was merely wondering whether it would be POSSIBLE to do that at acquisition time, because it would save more complex postprocessing steps and many beginners especially would appreciate it if they could go with the simplest approach that gives them the highest resolution with the best possible result from a OSC camera.

Obviously, the best results will always come from a monocamera using a filterwheel and combining narrowband with LRGB - especially from light-polluted areas. I found this out the hard way myself over the last year. But by keeping the activation threshold as low as possible, we would get more people into the hobby, which would mean more demand for equipment, resulting in dropping prices and faster progress of technology.... In other words, I was thinking ahead on the supply and demand side and how it could benefit all of us in the future.

Cheers
Jo

Read More...

Thanks, Eric!
There is a misunderstanding, which results from my using the term 'grayscale' for the 16 bit image I get with my ASI1600 MCPro. What I meant to convey is that at 16 bits the non-debayered FITS image contains only "grayscale", i.e. light intensity information at full scale, i.e. 4656x3520 pixels. Debayering ascribes a color to the specific pixels, which is then being used to compute the final 16.7 M color tone image contained in a 24 bit RGB image at full resolution, but at the expense of bit depth.

But when I am taking non-debayered 16 bit OSC images obtained with the ASI 1600MCPro (resolution of the original FITS file 4656x3520 pixels) and process them in DSS or PixInsight, I am ending up with half-resolution (i.e. 2326x1760 pixel), but 16 bit (!) color images. In other words, it looks to me as if the program takes the image, bins it 2x2 and then takes the embedded color information from that binned (i.e. lower resolution) image to compute a 16 bit color image by preserving color bit depth, but averaging the color information over each 4 pixel array and then ascribing it to a single pixel.

My question was whether there is a way of preserving the 16 bit color depth at full resolution DURING CAPTURE without losing resolution. The experience of my astrophotography club buddies suggests that that may be possible. If so, it would greatly improve the processing of one shot color images without losing quality.

But maybe I am also doing something wrong during the processing and debayering of the OSC images in DSS and PixInsight. If so, it would be great to hear suggestions what to do differently.

Thanks to you all,

Jo

Read More...

Thanks, Jasem and Eric. More than likely I am doing something wrong, but I am ending up with a lower resolution image (half the size in each dimension) when I record on my OSC ZWO ASI1600MCPro in 16 bit (resulting in a file size of ~32.8 MB) than when I record in 24 bit RGB (~49.2 MB). These numbers arise obviously from the number of pixels on the sensor (16 MP) multiplied by the number of Bytes required to encode them (2 Byte for 16 bit, 3 Byte for 24 bit). My understanding why this is the case is because of the Bayer pattern on the sensor, which basically splits the color information over 4 pixels. Essentially, the color matrix results in a 2x2 binning of the information. In RGB, this information is computationally interpolated so the color information for every individual pixel (whether it has an R, G, or B filter on top) on all three channels is "guessed" from the corresponding intensity of the nearest neighbor and the known spectral curves for each filter. Therefore, the information in the resulting output file is effectively tripled, i.e. a 16 bit image corresponding to ~ 65,000 ADU for a 16 MP sensor would now swell to 3 x 32.8 MB, i.e. ~ 98 MB) if the color information where encoded by 16 bits instead of 8 bits.

As Jasem writes, I did not think that the RGB conversion algorithm would support this and had intuitively reasoned that this is because the interpolation is by definition not exact, but an approximation, so calculating an interpolated value to an accuracy of 65,000 (16 bit) instead of settling on 256 (8 bit) was overkill, but the other day in our astrophotography club I was "ridiculed" for this. One of the members showed his images, obtained with an ASI294-MCPro, which has an ~11.7 MP sensor. He reportedly gets a ~70 MB FITS file, which by the same calculation I laid out above for the larger sensor of the ASI1600-MCPro works out to 11.7 M x 2 Bytes (16 bit) x 3 (1 each for R, G and = 70.2 MB. Unfortunately, he did not remember what capture software he was using. However, because he correctly stated the file size that would result from the capture of 16 bit image with an OSC correctly, I suppose it is possible?

Read More...

When I am using a one shot color 16 bit camera, I am nevertheless limited to recording on 24 bit RGB in Ekos. When I set Ekos to record at 16 bit, my OSC camera will only record gray scale, not color.

Would it be possible to increase the bit depth to 48 bits? I am losing a lot of information when I am using Ekos and a one shot color camera like the ZWO ASI1600MC-Pro.

Thanks,

Jo

Read More...

Of course, you are right , Chris! Shows us what sleep deprivation is doing to our brains. When M33 was passing through the meridian it was at almost 88 degrees altitude. All I could remember the next morning was the AZ reading spinning like a compass at the North Pole.

Problem solved. I hang my head in shame.

Read More...

Has anybody else noticed the same issue?

It is possible that this is already fixed in the nightly version, if so, please let me know. If not, it might be worth looking whether the aberrant data impact on other functions of Ekos and could potentially cause some of the other problems I have been reading about here recently.

Read More...

The Azimuth in the Ekos dashboard is not calculated correctly. As the mount is approaching the meridian, the azimuth value shown in the dashboard decreases by 1 degree (!, not minute) every few seconds and continues to count down rapidly. Last night as I was collecting a whole night's worth of images on M33 it approached 249 degrees within a few minutes after flipping, then it reversed itself and started counting up towards 359 again. It did not affect the functioning of the mount or its ability to flip on time, but if you are keeping an eye on the azimuth to gauge when the mount should flip, it won't work.

Here the log from last night.

www.dropbox.com/s/otd7k2rq4h7orri/log_19-26-29.txt?dl=0

Read More...

I agree for the most part. The primary objective should be to put together a Wiki that lays out the overall strategy and a boiler plate approach to get basic images very quickly. That is the part where one loses new users fast. If the hurdles are too high or if there are too many bugs then people get frustrated and abandon EKOS. If success arrives quickly, that will boost excitement and keep them interested, Then they can be gradually introduced to the more complex steps including automation using the scheduler. I cannot stop emphasizing how important that is for me, who has a professional life and cannot afford prolonged sleep deprivation. That will be another sizeable fraction of future users, so a well functioning scheduler would be a HUGE attraction over any other more basic software that does not have that functionality.

Apart from that, I still think that Trevor would be a perfect conduit to get the word out. He has worked hard and put together a fantastic blog and YouTube channel that by now reaches 10s of thousands of people. Most of those may never have heard of EKOS or consider the entry effort too high. Those we have to reach and once there is a critical mass then word of mouth will do the rest. Currently, we do not yet have that critical mass.

Do not underestimate the power of advertising.

Read More...