WR-134

[vlaiv]

7 minutes ago, Rodd said:

Isn't total exposure time the important thing.  If you have a stack nade from 20 10 minute exposures (taken with CCD) and I have a stack of 3.3 hours made from 200 60 sec exposures using CMOS, with a lower read noise andmuch higher efficiency, wont teh stacks be comporable?

Total exposure is important as far as SNR goes.

As far as absolute values go - single exposure time is important.

You average single exposures (most of the time), when stacking - and hence resulting stack will have same absolute signal values as single exposure.

If you decide to stack using sum method (in that case - no fancy weighted methods nor sigma rejection) - you will get same absolute values regardless of exposure length - for same total duration.

[Budgie1]

1 hour ago, Rodd said:

The strnet tool in my PI does not work with linear images--the results you get are way, way horrible.

The version of StarNet built-in to PI is the original version known as StarNet or StarNet++. The new version is called StarNet2 and has to be downloaded & installed into PI via the link I posted earlier. There's also a tutorial on that site which runs you through the installation process.

Once installed, it will appear in the Process menu, along with the old version, and includes a tick box which allows you to choose whether the image is linear or non-linear.

[Rodd]

6 minutes ago, Budgie1 said:

includes a tick box which allows you to choose whether the image is linear or non-linear.

Ahh....I will try and get it

[Rodd]

1 hour ago, vlaiv said:

As far as absolute values go - single exposure time is important.

You average single exposures (most of the time), when stacking - and hence resulting stack will have same absolute signal values as single exposure.

This is tru for a 1:1 comparison between sensors.  But how about when comparing CCD and CMOS, one is designed for long exposures and one is designed for short exposures.  According to CMOS method, as soon as sky fog is exceeded, there is no reason to keep exposing and another sub is started.  I have seen amazing images of M51 taken with 2 sec exposures (many hundreds even thousands)

[vlaiv]

5 hours ago, Rodd said:

This is tru for a 1:1 comparison between sensors.  But how about when comparing CCD and CMOS, one is designed for long exposures and one is designed for short exposures.  According to CMOS method, as soon as sky fog is exceeded, there is no reason to keep exposing and another sub is started.  I have seen amazing images of M51 taken with 2 sec exposures (many hundreds even thousands)

Yes, that is correct (although CMOS are not designed for short exposure - but rather allow for short exposure, due to their low read noise) - but that has nothing to do with what I've said.

It has to do with brightness of the target - which has some flux - or some photons per second.

If target has say 0.5e/s flux (we here convert to electrons and assume known QE of sensor) - in 30s exposure it will accumulate 15e, while in 300s it will accumulate 150e.

These are absolute numbers per exposure and they change based on what exposure length you use - regardless of CMOS vs CCD thing.

If you take bunch of subs with about 15e of signal and stack those using average method - well, average of bunch of 15e will be 15e. Resulting stack will have that absolute value.

Similarly - bunch of subs with 150e averaged will produce stack with 150s signal.

Although both stacks produce same image (same SNR) - they will differ in absolute value.

Shorter exposures will simply produce smaller values. And if you have very short exposure and very small values - 16bit integer format will produce rounding errors. Simple as that.

[Rodd]

13 minutes ago, vlaiv said:

Although both stacks produce same image (same SNR) - they will differ in absolute value.

So the question is, for most images (not super short exposures where there could be rounding error) is there a manifest difference?  Maybe with super dim targets?  But most images of common targets?

Regarding CMOS design--well, one can say they were designed to be what they are--very clean.  Whos to say if the designers knew or intended that a byproduct of their design would be the ability to takevery short subs.  I bet they knew and did design them for this.  There are many advantages of short exposures for the amateur astronomer--up to a point.   

[vlaiv]

1 minute ago, Rodd said:

So the question is, for most images (not super short exposures where there could be rounding error) is there a manifest difference?  Maybe with super dim targets?  But most images of common targets?

In my view - it is fairly simple. Use 32bit for all your processing and then you don't have to worry about any of that - whether you use short exposures or you use medium exposures of 1-2 minutes but you have 15h of total imaging time (same thing happens - as long as you have good SNR in low signal areas, 16bit will add rounding errors to it).

In order to utilize StarNet V2 in 16 bit format - do linear stretch so that faint target parts become clearly visible (set white point), but do it in such way it is reversible, so you can scale back result and calculate star only version from it.

 

[Rodd]

10 minutes ago, vlaiv said:

but do it in such way it is reversible, so you can scale back result and calculate star only version from it.

That's easy--make a clone (copy) and do it to that.  Then the original won't be effected.

[Sunshine]

That is a beautiful image!

[Rodd]

51 minutes ago, Sunshine said:

That is a beautiful image!

Thanks Sunshine!

[The Lazy Astronomer]

Just to say, there is an advantage to the ghs script pointed out by one of the creators that you can stretch an image then run starnet/starXterminator/whatever, and do an inverse stretch (again in ghs, just use the same parameters as before) to go back to linear. Et viola, 32bit linear star removal

[vlaiv]

9 hours ago, The Lazy Astronomer said:

Just to say, there is an advantage to the ghs script pointed out by one of the creators that you can stretch an image then run starnet/starXterminator/whatever, and do an inverse stretch (again in ghs, just use the same parameters as before) to go back to linear. Et viola, 32bit linear star removal

That does help, but it is still not the same as 32bit.

[The Lazy Astronomer]

2 hours ago, vlaiv said:

That does help, but it is still not the same as 32bit.

Could you explain why, please? 

[vlaiv]

9 minutes ago, The Lazy Astronomer said:

Could you explain why, please? 

Because at some point you need to convert it to 16bit and you loose precision.

You loose less precision where it matters if image is stretched but you still loose precision.

Ok, for the sake of argument - let's do some math to see what is going on.

Let's assume that "fidelity" of signal is about 0.1 (0-65535 units) at low scale of signal - say around absolute value of 5. So you have signal with good SNR that is 5.1 and you also have signal with good SNR that is 5.2 and those two can be distinguished.

16 bit data will put those two at 5 rounded - so they "posterize" or rather you no longer can distinguish them.

Let's see what happens if you stretch your data. We will take gamma of say 0.2 as stretch factor (very hard stretch).

5.1 represented in 0-1 range is  0.00007781982421875 (I'm copying from calculator so sorry for number of digits, don't want to round things up at this stage)

5.2 represented in 0-1 range is 0.000079345703125

Now we can take these two numbers and apply gamma on them

5.1 after stretch is 0.15073636882582656930879380243356

5.2 after stretch is 0.15132290938844934280215215782172

Now all we need to do is convert those numbers in 0-65535 range and see if we can distinguish them after rounding.

5.1 is 9878.6586673693700462211106362855 after stretch or 9879 after rounding

5.2 is 9917.0981896814161298818438150042 after stretch or 9917 after rounding

This shows that by stretching we can save some precision - but that does not mean that you don't introduce error. Let's run things in reverse for first number.

9879 converted to 0-1 range is 0.1507415771484375, with inverse gamma that is 7.7833269506148273600361174641031e-5 and converted back into 0-65535 range that is

5.1008811503549332586732699412746 = ~5.1009

So even with hard stretch of gamma being 5 (or 0.2 depends which direction you observe) - we still have some error due to rounding. It is much less than when working with linear data, but it is still there.

Smaller stretch than that would raise rounding error, and apparently latest version of StarNet does not like overly stretched data.