Scaling darks or not

[vicent_peris]

Vincent, thank you for the formula!
My ML8300 has 8 -e read noise so I shouod be good with 64 biases. I have took 100 biases just to round up
The thing is that biases are only good for scaling darks, because otherwise darks already contain bias.


E.

Yes, but you must always to rescale dars, specially if your camera is not cold enough (say -10ºC or -15ºC). I made some tests with an Apogee Alta at -10ºC. Temp during imaging was oscillating +-0.1ºC. After calibrating and combining the images, the difference was quite obvious if you don't rescale dark signal. Dark signal scalig factor was always between 0.95 - 1.05.


Vicent.

[Emanuele]

Ohh I understand! Alright, so you are saying that even if I build a dark library of darks taken at the same temperature and exposure time of the Lights, I should always rescale with Biases for temperature fluctuations.
My ML8300 is VERY steady with the temperature but will try what you are suggesting.

[mmirot]

I think he talking about using the automatic darks scaling.

Bias drift can only be compensated with overscan. This has to be implementmented by the camera mfr. Most cameras don't have it yet. Hi heard the latest SBIG driver now has it and FLI.

Max

[Emanuele]

Yes, I was talking about automatic dark scaling as well. Biases are needed for that.
Yep, FLI has overscan now.

[vicent_peris]

To scale dark signal, you must first subtract the bias frame to the dark frame. If not, you would be rescaling dark AND bias.


V.

[NKV]

just acquire 13^2=169 bias to reduce read noise to 1 e-. The same with darks...

OK, I got enough bias/dark frame to reduce read noise to 1 e-.

What about storage(file format)? Integrated Light frame ofcourse 64bit. What about intermediate frames?
I want to preserve the power of huge amount of frames.
1) Must I use 64Float for Master frame or ?
2) And if I use 64Float Masters should I store individual calibrated Light as 64Float too?

Thanks.

[Emanuele]

Oh!
I always save my integrated light as 32bit Float! Didn't think e 64bit option was necessary! Am I clipping something? 

[Niall Saunders]

I had a quick 'mental refresh' (courtesy of Google ), and came up with the following, taken from
http://steve.hollasch.net/cgindex/coding/ieeefloat.html

The range of positive floating point numbers can be split into normalized numbers (which preserve the full precision of the mantissa), and denormalized numbers which use only a portion of the fractions's precision.

	Denormalized	Normalized	Approximate Decimal
32-Bit Single Precision	± 2-149 to (1-2-23)×2-126	± 2-126 to (2-2-23)×2127	± ~10-44.85 to ~1038.53
64-Bit Double Precision	± 2-1074 to (1-2-52)×2-1022	± 2-1022 to (2-2-52)×21023	± ~10-323.3 to ~10308.3

So, as you can see, even the 32-bit range is HUGE

In fact, the actual 'resolution' that can be supported in 32-bit format is controlled by the 'fraction' part of the number (similar to sayning that 1.23456 can be identified as being 'different' from 1.23457) - and in each of these two Float formats, the 'fraction' part of the number uses either 23 bits or 52 bits.

So, if you think that your 'calibrated image data' is liable to require more than 2²³ discrete levels, then you should be working in 64-bit float during the calibration phase.

However, given that our image data is only generated in 16-bit mode (which gives 2¹⁶ discrete levels), my instinct is that the 'extra' 2⁷ levels provided in 32-bit Float mode should be MORE than adequate to allow for 'fractional parts' of ADU values during the calibration phase. After all, 2⁷ is 128 - so that means (to my way of thinking, at least) that PixInsight will handle the Calibration Data (in 32-bit Float mode) to ¹/₁₀₀th of an ADU value right from the outset.

Personally, I actually stick to 16-bit INTEGER format right through the calibration phase, and I haven't been able to tell whether I have lost ANY data due to this self-imposed restriction.

Cheers,
   

[Niall Saunders]

Well, after another brief Google search, I also came across the following link (which I should perhaps have read before posting the last reply!!)
http://en.wikipedia.org/wiki/Floating_point

Towards the end of this page there is the following summary:-


Single Precision, called "float" in the C language family, and "real" or "real*4" in Fortran. This is a binary format that occupies 32 bits (4 bytes) and its significand has a precision of 24 bits (about 7 decimal digits)

Double Precision, called "double" in the C language family, and "double precision" or "real*8" in Fortran. This is a binary format that occupies 64 bits (8 bytes) and its significand has a precision of 53 bits (about 16 decimal digits)


My 'extrapolation' from these two statements is that about 25% of the available bits can eventually be used to represent 'decimal places' (note - this is 'wet finger in the air guesstimation' ), so that might suggest that about 4 decimal digits might be available in 'half-precision' (16-bit Float) mode - which gives a 'little' bit of credence to my "¹/₁₀₀th ADU" proposition in my earlier post

Once again though - do you really need ADU values to SIXTEEN decimal places during the calibration phase? Do you even need ADU values to SEVEN decimal places?

If not, then stick with integer formats (to save time and hard-drive space, if nothing else) until you are ready to start working with your MasterLight - at which point 32-bit Float starts to become 'meaningful'. (IMHO, of course).

Cheers,