New Script: Calculate Sky Limited Exposure

Sean,

Thanks, that explains it.

Regarding the zero, so you're telling me I've forgotten nothing  ;)

Cheers
        Simon
 
Ok, here's version 1.0.

  • Added more Canon presets
  • Cleaned up UI a bit
  • Switched the max ADU to a bits value for ease of use

Also, I've created a GitHub project for the script.  If anyone wants to contribute please feel free.  It's really easy to download the git client, pull a copy of the repository and push changes.  Hopefully the new updates system will support user contributed scripts so we don't have to publish updates on the forum.

https://github.com/seanhoughton/CalculateSkyLimitedExposure
 

Attachments

  • CalculateSkyLimitedExposure.js
    21.3 KB · Views: 74
THanks for the feedback Sean.
I ran the Starizona Subexposure calculator (on Starizona Website) and for a QHY9 (Same chip as mine) with a median background value of around 2700ADU (see screenshot attached for the statistics of the image) and a 180seconds exposure, I get an ideal subexposure time of 130 minutes.

?

I am lost.

 

Attachments

  • Screen shot 2010-11-30 at 9.32.58 AM.png
    Screen shot 2010-11-30 at 9.32.58 AM.png
    24.1 KB · Views: 68
Hi Sean,

Welcome to PixInsight development!

Nice work. If you don't mind, I'd like to include this script in the standard set released with the next version.

I have attached a modified version of your script that fixes all screen alignment and sizing problems. The most important modifications include the following:

- When you create a NumericControl control, it already includes a Label subcontrol (its label property) that you must use. There's no need to define an independent Label and a HorizontalSizer to group it with the NumericControl.

- To visually align all controls on a dialog, use the font property of Dialog to compute a minimum width in pixels for the longest label. Then use that value to set the minWidth property of all labels.

- You can (should) define the width of all Edit controls in the same way. in this case you must force a fixed width for the edit subcontrols of all NumericControl items, as Edit controls shouldn't be resizable in general. However, you must call edit.setFixedWidth() after calling the setPrecision() and setRange() methods of NumericControl, as these methods reset the edit's width automatically.

- There is no need to set the label.textAlignment property, as it is already set to TextAlign_Right|TextAlign_VertCenter by NumericControl's constructor.

- Try to avoid leaving potentially unrooted child controls in a dialog's constructor. For example, if you write:

Code:
   function MyDialog()
   {
      ...
      var foo = new Label( this );
      ...
   }

this code should normally work as expected, i.e. foo will be a child control of MyDialog, and in most cases it won't give problems. However, by doing that you take one risk: under certain conditions, the JavaScript garbage collector may decide that foo has become out-of-scope and is unreferenced, and if that happens, foo will eventually be destroyed behind the scenes, with catastrophic results. Although I have been very careful to prevent that to happen with all GUI objects, JavaScript's internals are too complex as to ensure that no unexpected garbage collection may happen sometimes.

To prevent these side effects, always define all subcontrols as properties of their parent controls. In the case above:

Code:
   function MyDialog()
   {
      ...
      this.foo = new Label( this );
      ...
   }

is safer because as long as an instance of MyDialog is referenced, its foo child control will also be referenced.

- When a dialog must be user-resizable, always try to force at least one fixed dimension ?either the width or the height, as appropriate? whenever possible. In your script, I have set a fixed width of 420 pixels:

Code:
   this.setFixedWidth( 420 );
   this.adjustToContents();

which allows only changing the dialog's height. This ensures that a valid geometry will be set on all supported platforms (Mac OS X is particularly problematic in this regard).

Hope this helps.
 

Attachments

  • CalculateSkyLimitedExposure.js
    19.3 KB · Views: 72
Hi Sean,

Just tested your script and it works fine! I think it would be handy if the previously set ccd selection could be retained
each time the script is run.

Best Regards
Tasos
 
Hi Sean,

I've tested it on a number of different exposure length subs and it always seems to come out with sensible answers.

I agree with Tasos, if it could hold the last entered values, then that would be really great. Not sure if this is possible with a script though?

Cheers
        Simon
 
Thanks for the fixes and best practices Juan, that's helpful for the future.

I wasn't sure about the GC ramifications of using local variables for UI elements but I had assumed that adding them as children to the sizers would create a reference chain that would keep them alive.

Most of your improvements involve deleting code - my favorite kind.

Including it as part of the distro is fine.  Some people are reporting strange values so I'm going to do another pass on the math to make sure everything is correct.

Persistent settings is a bit tricky in a script.  I can write out a text file with the saved values but file permissions might cause issues.
 
Emanuele,

I think you plugged in seconds when the page is asking for minutes  :surprised:

When I use the values you provided (including "3" for the exposure) I get 2.25m as the limited exposure, which ends up being 1.125m suggested exposure.  So far all my test images line up with the results from the web calculator you linked to.

Remember that low value can actually be a benefit because it means you can take advantage of subexposure integration and get better pixel rejection and a reduced penalty for an image with defects.
 
Hi Sean,

yes, my bad on that webpage.
I still don't understand how is it possible that I get a suggested exposure time of 1.25m from a 21.5SQM sky!  ???
E.
 
Remember that low value can actually be a benefit because it means you can take advantage of subexposure integration and get better pixel rejection and a reduced penalty for an image with defects.

Very true! However, faint targets are a different story and what matters then (in terms of sub duration) is to register target data!

A very interesting approach for sub duration is also presented here:
http://www.cloudynights.com/item.php?item_id=1622

Tasos
 
Hi Tasos,

I agree wholeheartedly with you re faint targets, especially if you are doing an HDRComposition so that the bright stars are not massively oversaturated. I really liked that paper!

Cheers
        Simon
 
I enjoyed a quick read of the paper and I'll do another careful one tonight.

It sounds like providing another value, "Total Exposure Time", to the script would let me go further and calculate a second subexposure value. It might be possible to provide a target image and have the script suggest an appropriate exposure based on its flux, the star saturation level, and the tides.

This is turning out to be more complicated than I expected when I first decided to 'write a simple script to learn the API'  ???

One of my goals in dusting off all of my equipment and having another serious go at astrophotography has been to audit and improve every aspect of my imaging pipeline.  This means working through hardware issues, such as PE in the mount, all the way through final image processing.  This is turning out to be a very interesting part of that process.
 
This is turning out to be more complicated than I expected when I first decided to 'write a simple script to learn the API'

I confess that I posted the article link hoping it would provide a challenge for enriching the script.  ;)

Tasos
 
I'm working on a new version of the script but after studying that paper I can't seem to make sense of a few details.  The formatting is not doing it any favors for readability.

I have two questions:

  • Is lambda = "?" = Tgtsignal?  All three symbols seem to be used interchangeably.  This is a critical part of the final equation but the paper does not explain these symbols at all.  If lambda is Tgtsignal it means that subexposure length goes up linearly with target signal, which seems wrong.
  • Equation (14) uses E_total in the denominator, but then uses the value measured for Etotal/min which is not the same as Etotal.  We can't calculate Etotal since we don't know the exposure length so I'm assuming it's an error.

 
Sean,

I think the author has used Etotal/min to denote Etotal in units of minutes......more usually wriiten as Etotal(min). But that's just a hunch, I may be wrong!

I'm not sure about the other equations. Could you contact the author for clarification?

Cheers
        Simon

***** Ignore the above....I've just re-read it......and I'm talking rubbish!!! ******
 
Sean,

Wow, that paper is a difficult read! (or is it just me???)

Yes, lambda is ?, but its not too clear what lambda actually is. From the paragraphs just above eqn 14 it does look like it is something to do with the target signal. And if you click on the link to the info on the Poisson distribution then lambda is defined as "a positive real number, equal to the expected number of occurrences that occur during the given interval. For instance, if the events occur on average 4 times per minute, and one is interested in the probability of an event occurring k times in a 10 minute interval, one would use a Poisson distribution as the model with ? = 10?4 = 40." And that sounds like the faint target signal level to me.

But if you go down to the bottom of the paper to the final paragraph before the Conclusions, then it talks about lambda in a different way. It looks like its a factor that you can enter depending upon how close you want to be to a normal Poisson distribution.....with a value of 15 being a "good" value. IF this is correct, then lambda is effectively a constant....one that you choose at the begining.

I've got this feeling that what the author is saying is something like this......the maths analysis assumes a Poisson distribution. A Poisson dist becomes normal when the faint signal becomes > 5, with 15 being a 'good' number. So if you put 15 into the equations, then they will be valid and will give you the optimum subexposure for the faint parts of the image that have a signal level of 15. However, if you want to get the optimum subexposure time for parts of the image that have a signal level of 10 (or even 5) then it will still hold true.

This value of 15 is the signal level of the faint part that we are concerned about during the exposure, i.e. it is not the value per minute, but the value per minute multiplied by the subexposure time.

IF any of the above is correct then it still doesn't make much sense. The equation seems to be dimensionally incorrect....S seems to be in units of sqrt(T)?

I have no idea if any of this rambling helps at all????

Cheers
        Simon
 
That definition of lambda is what I initially thought and how I initially implemented the code.  Somehow I missed the conclusion where he clearly states that and went off reworkng everything to use target signal.  Now I'm glad I started using git to track revisions :)

I think the remaining confusion boils down to the unclear definition of ETotal and it's components.

No matter how many sub-frames you want to stack, there is going to be a limit in total exposure time, call it TTotal. The final combined stacked photo?s total noise term,  will be

image108.gif


Where: ETotal is the total noise for a shot of time T.
S is the sub-frame length in units of time T
TTotal is the total time in units of time T

I'm fairly certain that ETotal is the error for the sum of all subexposure time, not for each subexposure time. However, in his example he uses the value for ETotal/minute: 16.5 instead of the value his equations would produce for an ETotal for a 45 minute T (16.5 * 45 = 684 with no camera noise).

Adding to the confusion is the equations for light pollution noise that are not consistent with each other:

image083.gif

image074.gif


???  I'm going to email the author and see if he'll take a look at this thread.

 
Sean

Only just got round to testing the latest version of the script

Seems to work okay but when i close the image I have run th escript on I get this error

After this I cannot run the script again without restarting PI

Windows 7 64 bit

Nigel
 

Attachments

  • Untitled.png
    Untitled.png
    25.6 KB · Views: 55
Emanuele said:
Thanks Sean. Works fine now  :)

I am not understanding something though: I image from 6800ft, at a location where we have a 21.5SQM skies.
And the ExposureCalculator is telling me that the suggested exposure should be 53 seconds?

How is that possible?

I'm also getting some 'unusual' figures for my Luminance subs - suggested exposures of 16s on a 300s Lum sub???

That said my Ha subs appear to be almost spot on? I don't profess to understand the maths here so perhaps someone could enlighten me :-[

Nigel

 
Ok, version 2.0 is ready for testing out. It includes my best effort at the Anstey equations for limited exposures.

  • Anstey model
  • Realtime updates
  • UI tweaks
 

Attachments

  • CalculateSkyLimitedExposure.js
    28.7 KB · Views: 67
Back
Top