Color bit depth

any question related to our SDK and driver

Moderators: yang, ray, chad

Post Reply
dbainbridge
Posts: 9
Joined: Tue Aug 30, 2016 10:10 pm

Color bit depth

Post by dbainbridge » Tue Dec 18, 2018 5:30 am

In the header for the SDK it states:
8bit mono:width*height
16bit mono:width*height*2
RGB24:width*height*3

My question is why are we not able to get more then 8 bit values for each color channel (the RGB24 option)? If I am using a ASI178MC I would have expected to be able to generate 14 bit per channel values. Is there something I am not understanding?

Thank you for any assistance.

User avatar
chad
Posts: 603
Joined: Thu Feb 09, 2017 4:58 am

Re: Color bit depth

Post by chad » Tue Dec 18, 2018 8:42 am

HI,
1st, As we know, for a color image sensor, each pixel only have one color, red or green or blue. Usually, they are putted together in the order that Bayer invented. That's why we need to know a color camera's bayer pattern.
2nd, For a 14bit sensor, it means we can get the value of a pixel with 14 ‘0’ or ‘1'.
3rd, for computer system, usually, we use 8bit, 16bit, 32bit or 64bit to store a data.
Now, we know, for each pixel, we could get a 14bit data of one channel's color. For a resolution, we get (W*H*14) ‘0’ or ‘1'.
If we want to save the data into 8 bit, it means the space is ( W*H*8). So it is not enough. So we have move 6 bit away for each pixel. Usually, we move the low 6 bit away.
If we want to save the data into 16 bit, it means space is (W*H*16), data is not enough, we need to add 2 '0' on the space bit for each pixel.
If we want to save the data into 24 bit, it means space is (W*H*24), but for RGB24, it means each channel of color for RGB only have the 8 bit to save the data, So it should be (W*H*3*8), Now for one pixel, we only have 8bit to save the current pixel's data, have to move 6bit away. And we still need 2 other channes' data. Usually, we will use the nearest pixel's value which has the same color channel. For example, this pixel is red, this pxiel's green value will be the value of its adjacent green pixels, same as the blue value.
Usually, these 3 kinds of data is enough, but sometime, our customer do not want to lost any bit for a pixel, in other word, they want (W*H*16*3), Just like RGB24. I think it is easy to know how to get the value of each pixel's each channel.
At the end, for the length, We need to divide by 8 to convert bits into bytes.
Thanks
Chad
ZWO Driver Engineer
Location:lon=120.6 lat=31.3
SuZhou China

dbainbridge
Posts: 9
Joined: Tue Aug 30, 2016 10:10 pm

Re: Color bit depth

Post by dbainbridge » Tue Dec 18, 2018 2:55 pm

Thanks Chad for the explanation. You said
I think it is easy to know how to get the value of each pixel's each channel.
How exactly do you do that (what API call and settings do you use)? From the header it is not obvious how to do that since it only specifies the 3 types of image data you can request.

With only 8 bits per channel for color I am seeing sharp gradients in image under certain conditions. This is especially true if the camera is used as an all sky cam and takes daytime pictures as well night time. I have images where there is only 2 RGB colors used for 20% of the image because of the limited color palette.

Thanks
David

User avatar
chad
Posts: 603
Joined: Thu Feb 09, 2017 4:58 am

Re: Color bit depth

Post by chad » Wed Dec 19, 2018 1:29 am

Hi David,
For (W*H*16*3), it is not a common format, that's why we do not offer it. So if you want to use it, you have to malloc the buffer by yourself. And get the 16bit raw data from our SDK, then use the nearest pixel's value which has the same color channel to fix the current pixel's losing channel.

I am not sure your mean of sharp gradients , and 2 RGB colors. Can you show me the image that have the problem at here?
Thanks
Chad
ZWO Driver Engineer
Location:lon=120.6 lat=31.3
SuZhou China

dbainbridge
Posts: 9
Joined: Tue Aug 30, 2016 10:10 pm

Re: Color bit depth

Post by dbainbridge » Wed Dec 19, 2018 1:36 am

This is under an acrylic dome and there is circular artifact from the dome itself but I am referring to the gradient where the sun is rising. It is saturated where the sun actually is but then next color is single blue spread across quite a large area.
liveview-image 3.jpg

User avatar
chad
Posts: 603
Joined: Thu Feb 09, 2017 4:58 am

Re: Color bit depth

Post by chad » Wed Dec 19, 2018 1:57 am

Hi David,
This is a optical problem. Not the camera's problem. Generally speaking, this is caused by the atmosphere. it is normal.
Thanks
Chad
ZWO Driver Engineer
Location:lon=120.6 lat=31.3
SuZhou China

dbainbridge
Posts: 9
Joined: Tue Aug 30, 2016 10:10 pm

Re: Color bit depth

Post by dbainbridge » Thu Dec 20, 2018 3:01 am

You mentioned I can get the raw 16 bit values for all pixels on color version of camera through the SDK. Would I get that via ASIGetVideoData? something like ASIGetVideoData(1, (unsigned char*)imageData, (W*H*16*3), -1) ? Then would have to demosaic that image data.

What value would I need to use for the image type sent to ASISetROIFormat?

Thanks.

User avatar
chad
Posts: 603
Joined: Thu Feb 09, 2017 4:58 am

Re: Color bit depth

Post by chad » Thu Dec 20, 2018 7:25 am

Hi David,
No, our SDK do not offer W*H*16*3, we only offer W*H*16, you can use this data to generate your own (W*H*16*3) data. Using the following method:
chad wrote:
Wed Dec 19, 2018 1:29 am
Hi David,
For (W*H*16*3), it is not a common format, that's why we do not offer it. So if you want to use it, you have to malloc the buffer by yourself. And get the 16bit raw data from our SDK, then use the nearest pixel's value which has the same color channel to fix the current pixel's losing channel.
Thanks
Chad
About Mosaic, after debayer, it will disappear. It is normal for a color camera.
Thanks
Chad
ZWO Driver Engineer
Location:lon=120.6 lat=31.3
SuZhou China

User avatar
chad
Posts: 603
Joined: Thu Feb 09, 2017 4:58 am

Re: Color bit depth

Post by chad » Wed Jan 02, 2019 2:12 am

Hi Herber,
I am not sure what you mean is.
Thanks
Chad
ZWO Driver Engineer
Location:lon=120.6 lat=31.3
SuZhou China

Post Reply