Reading out 16-bit RGB with SDK.

tcumming

I can successfully read out both my ASI071MC and ASI2600MC with no problem using python and the SDK as long as I'm using asi.ASI_IMG_RGB24 that has only 8 bits per color. Both cameras have ADC's greater than 8 bits (16 bits in the case of the ASI2600MC) yet there is no setting that I can find to tell the camera to read out greater than 8 bits per color.

This is getting kinda urgent, as I'm trying to convince my employer to purchase 10+ of these cameras, (or maybe ASI2400's). I just need more color depth for my demo.

Thanks, tom

Tech@ZWO

Hello,
Have you tried ZWO demo in SDK?

tcumming

@tech@zwo#49196 I've looked at the demo source code and it only attempts to use ASI_IMG_RAW16, ASI_IMG_RGB24 and defaults to ASI_IMG_RAW8. I also checked the demo source code for the amount of memory allocated for the readout, and it does not allocate enough memory to get RGB at greater than 8 bits per color per pixel.

So, no I didn't run it, but it's pretty clear in the source.

FYI; The computer's headless and I'm accessing it remotely so it's not easy to run GUI's on it.

tcumming

I tried to google for a solution, and I found many other people asking the same question, and not getting an answer. I recommended this product to my employer based on the advertised 16 bit ADC, and now I don't understand how to get access to this data. My boss is asking me for answers. Please help!

Tech@ZWO

tcumming
Have you at least first read our PDF manual in SDK? Normally we don't provide tech support for developers who are using our SDK unless it is a bug report.

tcumming

Yes I have, and there is nothing in the SDK manual on how to read out RGB values with greater than 8 bits per color. Since the ADC does provide 16 bits per pixel, that implies that the camera can debayer to RGB values greater than 8 bits.

Therefore, if the SDK does not provide access to these additional bits, this is a bug in the SDK. Should I file a bug report?

Tech@ZWO

tcumming
Hello, do you know what is ADC first?

tcumming

Yes, I know what an ADC is. I also understand that "RGB48" is not that common.

The problem is that if I read out RAW16 to get greater than 8 bit resolution, I then have to debayer it myself. This is not unusual for the software that amateur astromomers use, but in my case, having the camera handling the debayering would improve the throughput significantly. I am using a computer similar to a raspberry pi that does not have that much processing power.

My project will take an image once per minute 24/7 continuously for many years. This means I have to do the exposure, then process the image in less than a minute. I have 10 cameras in a remote location at over 4000 meters altitude. Servicing will be difficult.

Because "RGB48" is not a common image format, I am concluding that I will have to do the debayering myself. Figuring out these issues is what engineering is all about!

thx, tom.c

w7ay

tcumming I also understand that "RGB48" is not that common.

16 bits per component, 3 (RGB) or 4 (RGB + alpha) components per pixel is actually very commonly used in imaging circles.

iOS and macOS's NSBitmapImageRep API allows it (48 and 64 bits per pixel), and macOS handles Images drawn with the bitmap seamlessly to a view (I haven't looked carefully at iOS, but am pretty sure 16 bit per component RGB works on iOS too).

In fact, if you import an MP4 movie file written by ASIAIR to Lynkeos (a planetary stacking and post processing program that runs on macOS) and export individual TIFF frames from Lynkeos, it writes it out as 16-bit per component RGB.

You can deBayer the 16 bit raw images yourself and get much better result than the libraries which ZWO used to perform deBayering anyway (lots of Moiré from ZWO's RGB output).

Chen

tcumming

@w7way; Thanks for that tidbit of information. I'm not in an "imaging circle" so I appreciate your comment.

If there are imaging people who use RGB48 (or whatever you'd call it) it seems that ZWO (and other astro-camera makers) would support it if the camera debayer/ADC supports it. I understand that imaging people are likely really picky about their debayer (or demoziac-ing) because of weird effects on edges, etc. My experience with my project it doesn't matter that much.

Right now, I'm exporting the image down the mountain as a raw16 then doing the hard lifting on real computer at the base facility.