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

16bit you get a bayered image, not grayscale. I don't think they support 48bit natively.

Just to clarify on the wording, you may have three 16-bit channels as R, G and B, but that will still result in a bit depth of 16 bits.
If you observe your captured frame is "24-bit RGB", it means that each channel has a bit depth of 8 bits.
Now about the grayscale picture, which bit-depth does it have?

-Eric

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 B ) = 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?

PS: I am aware that all the information the OSC sensor can capture is contained with the 32 MB 16 bit FITS file. Any software should be able to do the same interpolation later on that 16 bit file. However, when I use Deep Sky Stacker, I am ending up with an effectively 2x binned image (~2300x 1700 pixels) instead of ~4600x 3500 pixels). Have not tried this in PixInsight yet, but for practical reasons, it would be great if I could directly feed a 16bit color image into DSS (effectively what happens when I take the picture with my DSLR in RAW - I am not losing resolution).

Nothing much to add.
If I understand the ZWO specs of the ASI1600, the Bayer matrix is a 4656x3520 BGGR, with 12 bits for each photosite. Capturing a monochrome frame thus should bin to half the original dimensions, as you mentioned.
If your mono image ends up 32MB, that means each binned pixel is stored in a 32-bit cell. 4656/2*3520/2*32/8=32.25MB.
EDIT: This is indeed wrong. 16MB, not 32MB. What's up here?
If your color image is transferred as BGGR in 32-bit cells, 4656*3520*32/8*4=256MB. You observe 49MB, so it's transferred as BGR with 8-bit data cells. You need to review your driver configuration to get the four channels. As Jasem says, the thing to check is the debayer procedure.

-Eric

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

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

Just keep in mind that those 3*16bit full resolution images contain interpolated, i.e., not real data. You just don't have the full color information in every pixel, always only one color. I'd say, if you want to do quality data, only save the 16bit 'grayscale' FITS. It contains every bit of real information there is.
If you want such a 3*16bit full resolution image just take the result from DSS and upscale it a factor of two. That also is an interpolation just like the one the debayering does. In short: The huge files of your buddies are just that: larger. They don't contain more information or have better resolution (unless you use sophisticated processing methods like drizzle debayer - but that again is nothing you do at acquisition time...)

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

It is whatever is being output when I am using my ZWO ASI1600MCPro using the ZWO driver provided within Indi/Ekos. It gives the full resolution of the sensor and the Bayer pattern.

Sorry, can't send you an example right now, since I am traveling again and need access to those files on my machine back home. Will do when I get back. Perhaps someone else can provide the FITS headers for an image shot with an ASI1600MC with 16 bit resolution selected in the ZWO driver under Ekos.

I can't imagine why a 1K$ astrophotography camera would restrict you to debayered 8-bit RGB. You have to be able to get the 12-bit BGGR full-resolution raw data in a FITS file. You should contact ZWO directly.

-Eric