×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

ASI Camera bit size persistence issue

  • Posts: 12
  • Thank you received: 0
Hi,

I am using ASI cameras that support a 12-bit ADC. When I use the default Ekos/INDI settings I notice that the INDI Control Panel shows that the 8-bit Raw Format is selected. This then results in my captured images being saved as only 8-bit FITS files i.e. stats show a maximum value of 255. Reading the docs, I picked up that 8 and 16 bit FITS are supported and to recover the extra 4 bits I will need to use the 16-bit format. When I then view the FITS stats, am I correct in saying that the 12-bit values are scaled up to fit a 16 bit values i.e. 0-4096 -> 0-65535? Also, when I exit and re-run the software the Format always defaults back to 8-bits. Is there a way to force the setting to stay at 16-bit?

Many thanks.
4 years 4 months ago #45704

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
Going up to 16 bits will store 12 bits faithfully, is not scaled in any way to fill 16 bits. The extra bits are just zeros.

Save the ASI INDI driver configuration to have it remember the 16bit setting.
The following user(s) said Thank You: Jasem Mutlaq, Alfred
Last edit: 4 years 4 months ago by Andrew.
4 years 4 months ago #45717

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
This was recently discussed here:

www.indilib.org/forum/wish-list/5997-dri...ebth-as-default.html

As you can see Jasem has made sure that in future versions of INDI the default bit depth is set to 16 bits. Please read the rest of the comments in the thread as well.


HTH, Wouter
4 years 4 months ago #45726

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133

Uh, no. At least the ASI cameras save their 16bit data left-aligned, i.e., the counts will be 0->65535, but increasing in 4bit = 16 count steps.
4 years 4 months ago #45816

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
Curious why it's better to have the data left shifted, I can't think of any good reason.

Chris
4 years 4 months ago #45817

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

I don't believe my statement was incorrect. For reference I found this explanation.
engineering.stackexchange.com/questions/...ustified-adc-results
If I understand correctly, Left-justified would be read as 0x123456789ABC0000 (would be binary in reality). Example being representative of 12 bits of information in a 16 bit register. The extra bits being zeros, as I said.
4 years 4 months ago #45844

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
Might be a semantic disagreement ;)
Yes, the result from the ADC will be padded with zeros. Padded on the right side. So the max value from the ADC (4095 = '111111111111') will be placed in 16bit as '1111111111110000'. Expressed in 16-bit, this is a four-fold bit shift left of the value 4095, which corresponds to a multiplication with 16. I'd well call that 'scaling'.
Upshot is, the data you get from ASIs is 0->65520, not 0->4095.
4 years 4 months ago #45860

Please Log in or Create an account to join the conversation.

  • Posts: 984
  • Thank you received: 160
The data is shifted only, it's not being scaled.
4 years 4 months ago #45864

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
Somewhat getting ridiculous.....
At least tell me then how 'scaling' would look in your opinion (and why multiplication is not scaling.....)
4 years 4 months ago #45870

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
Point is the data is faithfully stored within. There is no loss or additional information, just some padding.
4 years 4 months ago #45882

Please Log in or Create an account to join the conversation.

Time to create page: 0.859 seconds