10/12/14 bit FITS Natural Bit Depth

Anything that doesn't fit into any of the other forums
mAnKiNd
Posts: 308
Joined: Sun Jun 11, 2017 4:55 pm
Location: Long Island, NY
Contact:

10/12/14 bit FITS Natural Bit Depth

#1

Post by mAnKiNd »

Hi everyone :)

Don't mean to appear clueless, as I have a clue as to why, but I always find it best to ask even obvious questions to ensure I'm on track :)

Would someone please point out some quick reasons/scenarios when it would be best to enable this feature vs simply stretching them to 16-bit as always?

"Version 3.1.5049.0 - Add option (general settings) to write FITS files from 10/12/14 bit cameras at their natural bit depth, not stretched to 16 bits [Advanced use cases only - saved files will appear dark unless stretched]."

Thank you :)
Minos
mAnKiNd
Posts: 308
Joined: Sun Jun 11, 2017 4:55 pm
Location: Long Island, NY
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#2

Post by mAnKiNd »

Maybe I should rephrase my question to this: why stretch to 16-bit?

Cheers
Minos
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#3

Post by admin »

Hi Minos,

Two reasons really

* Consistency
* Beginners

The consisntency thing is because a number of cameras do this behind the scenes anyway - ie although they are 12 bit cameras the data you get back from the SDK is already stretched out to 16 bit. For the cameras that do give back the original 12 bit data I stretch to 16 bits in SharpCap to make sure that all brands of camera do the same thing.

The beginners thing is more important though - for someone getting started there's a big pitfall if you don't stretch - they see their image on screen just fine, save a few files and then when they view the saved files they look basically black. They're frustrated and they think SharpCap has a bug - so basically it would be a big usability flaw to default to saving unstretched files.

Now, my original plan was for this new advanced option to work with all cameras, but I'd forgotten that a number of brands don't give me the info on the actual ADC bit depth, so I can't make this feature work yet on those brands. Right now it only works correctly on Altair cameras (and maybe ASCOM cameras if they correctly report their MaxADU value as 4095 not 65535).

Also you will have to be careful when using this feature as some camera features like brightness/contrast/gamma that are applied in digital space in the driver/SDK may be operating on already stretched 16 bit values. What this means is that the data comes in from the camera in the range 0..4095, then gets stretched in the SDK, multiplying by 16 to get a value in the range 0..65520 but with steps of 16, then gets brightness/gamma/contrast applied (stillin the driver/SDK) which can basically shift all the values around so they are no longer multiples of 16. Then if you ask SharpCap to save without stretch, it tries to undo the 16x scaling by dividing by 16 and is throwing away data in the process. That's why it's marked as an advanced option - if you use it with that sort of digital processing enabled then you degrade your image data.

cheers,

Robin
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#4

Post by oopfan »

May I add that this is important if you want to do science with your camera like photometry and spectrometry. To be successful at it you need to know the range of linearity of the sensor. If the SDK is stretching the image but SharpCap cannot unstretch it then you have a problem. Buyer beware.

Brian
mAnKiNd
Posts: 308
Joined: Sun Jun 11, 2017 4:55 pm
Location: Long Island, NY
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#5

Post by mAnKiNd »

Thank you both for your replies, much appreciated :)

Robin, I don't touch the brightness/gamma/contrast controls, so that should be ok then, no? It wouldn't mess up the multiples when dividing back by 16. EDIT: just re-read your post, so the SDK might be doing this anyway hmmm need to know how best to approach this for cameras that do this.

Also, judging by your statement that only Altair cameras support this fully, then I suppose my QHY183C is stretching the data to 16-bit in its SDK, correct?

Furthermore, does this mean the rest of us without Altair cameras are stuck with leaving the "stretch to 16-bit" option enabled?

I would encourage a list of which cameras currently support this feature be published so that users don't unknowingly and mistakenly uncheck this option and mess up their acquisition files.

Brain, I have a diffraction grater and was hoping to get more into my spectroscopy science so thank you for point this out.

Cheers
Minos
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#6

Post by admin »

Hi Minos,

ZWO have updated their SDK to include this info - new version that supports this in ZWO cams coming today. QHY have said they will add this, but the SDK is not ready just yet.

cheers,

Robin
mAnKiNd
Posts: 308
Joined: Sun Jun 11, 2017 4:55 pm
Location: Long Island, NY
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#7

Post by mAnKiNd »

Cheers for that buddy :)
mAnKiNd
Posts: 308
Joined: Sun Jun 11, 2017 4:55 pm
Location: Long Island, NY
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#8

Post by mAnKiNd »

Hi Robin and Brian,

I'm resurrecting this old post as I'd like to once again kindly ask for your help in this matter so I can better understand the working behind this option so as to better apply it.

so here's my understanding:

12-bit = 4096 shades of grey from 0-4095. 0 is black, 4095 is white and everything in between a shade of grey.
16-bit = 65,535 shades of grey from 0-65,534. 0 is black, 65,534 is white and everything in between is a shade of grey.

Now when the camera SDK or Sharpcap stretch the 12-bit data to 16-bit by multiplying the 12-bit information by 16, this means that for example, a single recorded shade of say 0 in 12-bit is now 16 times in 16-bit and so on, so essentially the transformation will be something like:

0 (12-bit) -> 0000000000000000 (16-bit)
...and by extension, a recorded shade of 1 will be transformed to something like:
1 (12-bit) -> 1111111111111111 (16-bit)
and so on and so on...

Is this the case for the upscaling of bit depth to 16-bit from 12-bit, involving the transformation above (by multiplying each value by 16), or is it simply that 0-4095 from the 12-bit data remains as is but now with a ceiling of 65,534 (16-bit) being the white point (and from what I've understood from Robin's post above, this is not the case).

If the transformation stands in that it multiplies each shade point identically by 16, then what benefit would this offer to post-processing in astrophotography?

I appreciate the points made by Robin that a beginner may feel there is a bug in Sharpcap because the data "looks" darker, but I'm not bothered by that. I'm simply thinking that working with a 16-bit space over 12-bit space for post processing offers no advantage, because one is simply dealing with 15 more values of the identical same shade..no? What I can appreciate though to keep 16-bit selected, is what Robin mentioned about the fact that certain "brightness/gamma/contrast" controls, when changed, won't scale back correctly resulting in the loss of data. Again,if one leaves these controls untouched at default, then once again, what is the benefit of using 16-bit over 12-bit?

Furthermore, the brightness control for ZWO cameras is the recorded offset. I'm not sure what it means for other vendor cameras, I presume the same. Brightness/offset is a control that I do change, therefore, does Robin's concern about changing "brightness/gamma/contrast" controls apply here? If yes, then unticking the option and allowing the stretch to 16-bit is obviously the better choice. The reason I'm confused about the use of the word brightness here, is because before switching to a ZWO camera, my old QHY camera had separate offset and brightness controls. I only ever changed offset for the QHY, not brightness. Now with my ZWO, I have no offset and only a single brightness control.

Thank you again for helping me climb out of this cave.
Minos
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#9

Post by oopfan »

Minos,

Regarding:
12-bit = 4096 shades of grey from 0-4095. 0 is black, 4095 is white and everything in between a shade of grey.
16-bit = 65,535 shades of grey from 0-65,534. 0 is black, 65,534 is white and everything in between is a shade of grey.
When scaling from 12-bits to 16-bits SC is just multiplying the 12-bit number by 16 (that is, 2^(16-12) = 16), so you are still getting 4096 shades of gray.

That is my understanding.

Brian
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: 10/12/14 bit FITS Natural Bit Depth

#10

Post by oopfan »

I'll let Robin be the final judge :D
Post Reply