AllskyTeam
Startrails - improve use and debugging
Startrails work for most people, but some people struggle getting trailed stars. The startrails documentation along with the allsky-config get_brightness_info command help users determine what Brightness Threshold to use, but some people still struggle.
This Issue is a catch-all for ways to improve startrails generation and make it even easier to find the right settings to use. See this Discussion for many more posts on this topic.
-
[ ] 1. Add an option in the WebUI to only look at nighttime images. This would use the capability in # 2 below to create a list of nighttime-only images. The default should probably be "Yes", although in general I don't like adding things that "break" existing functionality, which this could do if a user's startrails used some daytime images due to their Angle, Latitude, and Longitude. I think this is not very likely though. A correctly-set
Brightness Thresholdshould eliminate daytime image, but only looking at night images will make processing go faster (possibly twice as fast). Accepting a list of images would also make it easy to implement things like a user-specified start and stop time for image to process. -
[x] 2. Add an option to pass a list of images to process to the
startrailscommand, rather than process all images for a 24-hour period. This would also allow using images from multiple nights or directories. The images in the list would default to a specified directory unless the image name began with/in which case it would signify a full pathname to the image. -
[x] 3. Add
allsky-config compare_startrailsto create a list of 50 or so nighttime images, then call thestartrailscommand with a bunch of different Brightness Thresholds using that image list, so a bunch of different startrails are created for the user to look at and compare. It could even let the user know which setting resulted in the most images being used. This would automate what the startrails documentation tells the user to do manually. A WebUI "helper" page would have a form where the user would enter the desired test settings. Submitting the form would create the startrails and display a link to view them. -
[x] 4. When created at end of night, if no images were used, i.e., none were below the threshold, the
startrailscommand should exit with code EXIT_PARTIAL_OK which results in a System Message in the WebUI suggesting the user runallsky-config compare_startrails(or go to the web page described in # 3 above). This would make it easy for users to know what happened, and if we're lucky, reduce the number of "Startrails don't work" posts here and in Facebook (which almost all have the same, canned answer...). -
[ ] 5. UPDATE: this probably isn't needed if the "mean brightness" generated while capturing the image is passed to the
startrailscommand, since the brightness determined by thestartrailscommand when using a mask should be the same as the "mean brightness". Add an option to the WebUI for the user to specify an optional mask thestartrailscommand would use when determining the average brightness of an image, and hence whether or not to include the image in the startrails. Currently the whole image is used in calculating the average brightness, which means the brightness of buildings, trees, black borders, and other non-sky objects are included. This in itself probably isn't that bad, but it means the average brightness of an image can't be compared to theTarget Meansetting, which uses only the central portion of an image (which is likely to be only sky). A future Allsky release will allow users to specify a mask that the auto-exposure algorithm would use when determining mean brightness, and that same mask could be used by thestartrailscommand, thereby allowing theBrightness Thresholdto be compared to theTarget Mean. -
[ ] 6. For each startrails created at the end of night, save the data it produces (Minimum, Maximum, number of images used, etc.). This would allow looking for trends (what impact does the Moon have on the numbers?) and would allow creating a video of all startrails using daily startrails images that have trailed stars. The
allsky-config get_startrails_infocommand could use that list to determine better average numbers - it currently only looks in /var/log/allsky.log` which may only contain a few entries (and for the first day after an Allsky upgrade it won't contain any). -
[ ] 7. UPDATE: this isn't needed when # 8 below is implemented, since the database entries will have the fields listed in this item. When called from endOfNight.sh, have the
startrailscommand save information about every image it looks at, including the mean brightness and brightness threshold. It would save the info to a file in the same directory as the startrails file, i.e.,~/allsky/image/DATA/startrails, rather than in the database to keep it from getting too big. This would be handled in thegenerateForDay.shscript. -
[ ] 8. Information on every image taken should be saved in the new database. This includes exposure time, DAY / NIGHT flag, mean brightness, and other info. Every module like Star Count that creates per-image data should update the image's database entry. When determining which images to include in a startrails, the database would be queried for all images that meet certain criteria. That list would then be given to the
startrailscommand per number 2 above.
Hello Eric I like the first one (why would you use day time images for startrails ...). Your concern you have with this one is solved if you allow a user to keep the day images for startails. I thinks limiting to night images only will solve most of the problems.
I also like the last one, but I would add a file with the list of all images of the day/night, indicate if they have been used or not, and add the average brightness (and treshold brightness)
Another idea is to add on the overlay a field that mentions if the image is used for the overlay and a field for the average brightness of the image (and the treshold brightness) . So you can scroll through your images and learn from it.
Hope this helps.
@ova103, thanks for the comments.
why would you use day time images for startrails
In Allsky, "daytime" and "nighttime" are defined by the Longitude and Angle and define when the "Daytime" and "Nighttime" settings should be use, and are only loosly the same as what we generally think of as "daytime" and "nighttime".
I'm helping a user with an unrelated problem and noticed his Angle is -12 which means it's what most people would call "dark" at the beginning and end of his "daytime" for around half an hour, and images in those periods probably contain valid stars for a startrails. Using only "nighttime" image means he'd probably get an hour's worth less stars in his startrails.
It's cases like this that make me hesitant to have the default be "Use only nighttime images".
To implement the first change I'll probably have the saveImage.sh script, which does all the work after a raw image is saved like cropping, adding the overlay, and uploading the file, save the name of the image in a "DAY" or "NIGHT" file. If only nighttime files are included in a startrails, then the "startrails" command would be given the "NIGHT" list to process.
For the last one, I already changed the "startrails" command in the next release to include the Brightness Threshold in it's output along with the Minimum, maximum, etc. When you said:
indicate if they have been used or not,
do you mean "indicate if nighttime only, or all images" are used, or indicate for each image the "startrails" command looks at, whether or not it is included in the startrails, i.e., if it's above or below the threshold? I considered the later, but if a user has 3000 images that's a lot of data to keep. For debugging I can see where it would be useful to have an option to the "startrails" command that says "for each file, indicate if it was used or not".
@ova103, Thanks again for the input. I was hoping for some back-and-forth like this - it helps improve the final result.
add on the overlay a field that mentions if the image is used for the overlay and a field for the average brightness of the image (and the treshold brightness)
Should "if the image is used for the overlay" have been "if the image is used for the startrails" ?
I spent about 20 minutes writing a reply to this, figuring out how it could be done, then realized adding this info to the overly can't be done. The overlay is created immediately after an image is taken, but whether or not that image was used in a startrails isn't calculated until the end of night - too late for the overlay.
However, in order to help "learn from it", I just added change # 7 in my original post to have the startrails command save information about every image. We could then have a command (possibly an option to allsky-config get_brightness_info) that displays that information.
What are your thoughts on HOW to display the information so it would be useful to a user?
The ${MEAN} variable can be added to the overlay now - it's the average brightness (aka "mean") of the image as measured by the auto-exposure algorithm. The startrails command currently calculates the mean brightness of an image differently so its mean and the ${MEAN} of the image can't be compared. Change # 5 in my original post deals with having the startrails command compute the brightness the same way as the auto-exposure algorithm so the numbers are the same.
Allsky doesn't currently save information on each image, but if it did and it saved the MEAN value, then the startrails command could look at the save information and compare each image's saved MEAN value to the Brightness Threshold, rather than recompute the mean. If it did this, then the overlay COULD indicate if an image is going to be included in a startrails - it would simply look at the MEAN value and compare to the Brightness Threshold.
@ova103, thanks for the comments.
why would you use day time images for startrails
In Allsky, "daytime" and "nighttime" are defined by the
LongitudeandAngleand define when the "Daytime" and "Nighttime" settings should be use, and are only loosly the same as what we generally think of as "daytime" and "nighttime". I'm helping a user with an unrelated problem and noticed hisAngleis -12 which means it's what most people would call "dark" at the beginning and end of his "daytime" for around half an hour, and images in those periods probably contain valid stars for a startrails. Using only "nighttime" image means he'd probably get an hour's worth less stars in his startrails. It's cases like this that make me hesitant to have the default be "Use only nighttime images".
Maybe another idea: instead of saying you want to use Night images only, you could say if you want the use the images of astronomical twilight only, or also the ones from nautical, or also the one from civil, or also the one of the day. So it means you specify a 2nd angle for the usage of the images for the strartrail.
For the last one, I already changed the "startrails" command in the next release to include the Brightness Threshold in it's output along with the Minimum, maximum, etc. When you said:
indicate if they have been used or not,
do you mean "indicate if nighttime only, or all images" are used, or indicate for each image the "startrails" command looks at, whether or not it is included in the startrails, i.e., if it's above or below the threshold? I considered the later, but if a user has 3000 images that's a lot of data to keep. For debugging I can see where it would be useful to have an option to the "startrails" command that says "for each file, indicate if it was used or not".
I mean indicate for each image the "startrails" command looks at whether or not it is included in the startrails. To reduce the amount of data it could for example list only the images that have been used to make a startrail.
@ova103, Thanks again for the input. I was hoping for some back-and-forth like this - it helps improve the final result.
add on the overlay a field that mentions if the image is used for the overlay and a field for the average brightness of the image (and the treshold brightness)
Should "if the image is used for the overlay" have been "if the image is used for the startrails" ?
Yes indeed, it should be if the image is used for the startrails"
I spent about 20 minutes writing a reply to this, figuring out how it could be done, then realized adding this info to the overly can't be done. The overlay is created immediately after an image is taken, but whether or not that image was used in a startrails isn't calculated until the end of night - too late for the overlay. However, in order to help "learn from it", I just added change # 7 in my original post to have the
startrailscommand save information about every image. We could then have a command (possibly an option toallsky-config get_brightness_info) that displays that information.What are your thoughts on HOW to display the information so it would be useful to a user?
The
${MEAN}variable can be added to the overlay now - it's the average brightness (aka "mean") of the image as measured by the auto-exposure algorithm. Thestartrailscommand currently calculates the mean brightness of an image differently so its mean and the${MEAN}of the image can't be compared.
I did not realize $(Mean) is not same as the Mean value used by stratrail command. Would be helpful to specify this in the documentation
Change # 5 in my original post deals with having the startrails command compute the brightness the same way as the auto-exposure algorithm so the numbers are the same.
That makes a lot of sense.
Allsky doesn't currently save information on each image, but if it did and it saved the MEAN value, then the
startrailscommand could look at the save information and compare each image's saved MEAN value to theBrightness Threshold, rather than recompute the mean. If it did this, then the overlay COULD indicate if an image is going to be included in a startrails - it would simply look at the MEAN value and compare to theBrightness Threshold.
Yes that looks very useful. Additional info to save could be if it's DAY or NIGHT time, and the angle of the sun.
@ova103,
instead of saying you want to use Night images only, you could say if you want the use the images of astronomical twilight only
On our to-do list is allowing a user to specify a start and stop time for images to include in startrails, keogram, and timelapse.
The "times" could be an angle, an actual time, like 6:21 pm, or a time relative to sunrise or sunset, and maybe astronomical, civil, or nautical. The last 3 are already relative to sunrise and sunset so probably aren't needed, but might be easier for a user to understand, especially if the do astrophotography since some software uses those terms.
We'll need to think about how to present this in the WebUI so it's not too confusing and doesn't add a ton of new settings.
The current Angle setting is really just an offset from sunrise and sunset expressed in degrees, so in theory it could be replaced by the more general "times" above.
Having said all that, maybe the best thing for the next release is to simply add a "Use Nighttime Images Only" flag for startrails, and get user feedback on whether or not more granularity is needed.
perhaps it may be neat to be able to exclude images that have airplane light trails?
Don't need to solution it here, but maybe could be implemented by detecting lines across an image? not sure it a negative or not, but could potentially end up also excluding satellite or meteors as well, but since you are collecting ideas...
It would be nice to be able to use the -b brightness flag with the generateForDay.sh command for startrails testing, so one could easily try different settings for a given day. Maybe have it add the brightness level as a suffix for that startrail image? like startrails_20250729_0p15.jpg for a brightness level of 0.15? The bare startrails command is a bit cumbersome on its own.
I wonder if there's a way you could leverage the clear skies module to only use images with a certain percentage of the sky being clear, so it doesn't include images where clouds are passing through. (The brightness threshold can kind of work for this, but when there's only a few clouds it doesn't correspond quite as well).
@NiteRide, @brianboru82, Thanks for the ideas. I was hoping people would chime in, and they are. Multiple heads are better than one.
Having other criteria (besides just the Brightness Threshold) for filtering out images, like clouds or airplanes in the image I think would benefit from number 2 in my original post. All the intelligence would be in the module(s) that create and edit the list of images to use. The startrails command in theory would just take all the images it was given and create a startrails.
The next release of Allsky will have a database and @Alex-developer and I have talked about saving information on every image, like exposure time, mean brightness, DAYTIME or NIGHTTIME, and more. It would be easy for other modules to add data, like if any meteors were detected, number of stars found, cloud coverage, whether plane trails exist, etc., etc.
Part of the startrails creation process could look at the list and apply certain criteria, and write the image names that pass the all the criteria into a file, then pass that file to the startrails command. Users could pick the criteria they want to use by what modules they run. If none are used then just the brightness would be used as is done now.
It would be nice if someone volunteered to design the solution - no programming needed at this point, just someone that can think through problems.
@brianboru82,
Funny you should mention passing the brightness threshold to generateForDay.sh - I have been wanting to allow a way to pass ANY argument for startrails, keograms, and timelapse, I just haven't yet figured out the user interface. My first thought is by adding something like --startrails-args "-b 0.8" --timelapse-args "--fps 25 --width 960".
I think for more in-depth testing number 3 in my original list would be more helpful because it would produce a series of images you could compare. I've asked Alex about giving a script the ability to have a special overlay added to an image, so the startrails produced by number 3 could have the Brightness Threshold added to the image to make comparing them easier.
As one of the people who have had troubles with Startrails after the new exposure algorithm, I've mused about it for a while and tried different methods of sorting what may be cloudy and clear images. I'm a non-typical user, as some know. I capture the daytime images into images/YYYYMMDD/d so I can review them for interesting weather - have caught a few interesting events using this method. I don't store the daytime images in the core date folder because it'd be over 4,500 images most day + nights. and it makes it easy to delete the daytime only images if they're not of use.
I've thought about adding day or night to the image names, but 4,500+ images in a single folder is quite troublesome. So brute-forcing the /d folder in the saveImage.sh for the daytime images works for my needs/wants.
I thought about methods of star detection, sky clarity, or other methods and wondered if the Starcount module could help. Since it has been working successfully on my system for quite a while, I figured it may be a metric that may work for 'is this image something that is good for startrails'.
I spun up a rough metadata module, writing to a JSON file in the previously mentioned ${ALLSKY_IMAGES}/DATA folder.
Will let it run over night and see what I can glean from the data-grab I have it doing - hopefully the weather is semi-clear to at least grab a few frames with fair starcounts... Angle, Starcount, Mean Brightnes, and whatever else might be useful is grabbed, I know it's TOO much data to collect, but for testing, figured "if its there, grab it".
Working on a separate python script (probably module as well) that will dig through the JSON file, do a quick if "day_or_night" = "NIGHT", and "starcount" > 90, add file name to list ${ALLSKY_TMP}/starcount_trails.txt, then try and feed it into generateForDay as a --images and see what happens. Comparing it to the current startrails. I'll probably modify the generateForDay.sh a bit to get the --files working with the txt file, but should be able to farmer it together.
Not sure if this is going to work the way my mind wants it to, or even work at all... BUT - what are y'all's thoughts on a method like this? Anything I should try? or consider in the testing?
@jcauthen78, Jim, Thanks a ton for doing this!
I think this will most likely work and could easily form the basis for a script that checks multiple criteria - mean brightness, star count, cloud coverage, day/night, etc.
Some things to take into account when creating it:
- Assume it will use the database when we know how to use it, so try to compartmentalize references to the ${ALLSKY_IMAGES}/DATA folder so we can replace just that code.
- Assume there will be multiple criteria that could be used, and each will have a setting or something similar that determines if that criteria is actually used. For example, if a user doesn't have the Cloud Detection installed, the code would not include that criteria.
- If there are NO criteria that can be applied, then the list of files that
startrailslooks at would be the current list, which is everything.
You will probably want to install the newest startrails command since it accepts a "--images file_name" argument which you'll want to use. All the criteria checks should result in a file that contains image names for startrails to look at. To get the file:
cd ~/allsky/src
mv startrails.cpp startrails.cpp- ORIGINAL
# in GitHub, change from the `master` branch to `v2025.xx.xx` and go to the `src` directory
# click on the `startrails.cpp` file
# Use one of the icons to download the file to the directory you are in.
make
cp startrails ../bin
Echoing some bullets from the other discussion thread (https://github.com/AllskyTeam/allsky-modules/discussions/276):
- Agree that having the option to specify darkness level (civil, nautical, astro) makes a lot of sense to me. It could be a simple dropdown with an "other" option for power users to specify a different angle. Only near the equator does a fixed time really make sense. I think that people who are looking for specific times every night are probably power users rolling their own scripts.
- Because the auto-level algorithm shoots for a fixed brightness by adjusting exposure time and gain, and it take a few frames for responses to changes in brightness, the fixed image brightness is not a good measurement of how dark it is outside. You may well have night images that are brighter than day images, or cloudy images at night that are similar to clear. If you calculate brightness after dividing by the gain and the exposure time, that would normalize out those changes and give you a much more physical value of the scene brightness.
- Being able to provide a mask for where to determine brightness is pretty key in my mind.
@craigim, thanks for chiming in.
If you calculate brightness after dividing by the gain and the exposure time, that would normalize out those changes and give you a much more physical value of the scene brightness.
Could you give an example with numbers on what you mean? And how that's better than just comparing brightness? Use a nighttime exposure of 60000 ms (60 sec) and gain of 10 and daytime exposure of 0.5 ms and gain of 1.
Assuming a user can specify the start and stop times, e.g., via angles, should a brightness check ALSO be done?
Being able to provide a mask for where to determine brightness is pretty key in my mind.
For use by the auto-exposure algorithm during image capture, or by the startrails command?
Would a user ever want to specify different masks for brightness for the auto-exposure algorithm and the startrails command, and if so, often enough to add two new options in the WebUI?
Offhand I would think one mask during image capture is enough, and that mean brightness could be passed to the startrails command.
Here are part of three images. One from noon and two from around midnight on a clear and a cloudy night. The brightness values are different, and it is certainly possible to thread the needle to get just the dimmest sky, but to get that I had to push my daytime target threshold way up and my night threshold down.
| Image | Brightness | Gain | Exposure | Normalized Brightness |
|---|---|---|---|---|
| Day 1 | 0.482 | 1.00 | 175e-6 seconds | 2777 |
| Night 1 | 0.224 | 1.51 | 20 seconds | 9.26e-3 |
| Night 2 | 0.371 | 1.00 | 10.7 seconds | 3.47e-2 |
Using the normalized brightness, daytime is 7 orders of magnitude brighter than night as expected. No ambiguity, no careful trying to set the target brightness to get it just right. I can also now push the daytime target brightness down and the nighttime gain up. I could set them to be the same for that matter. Certainly you could also use the time to separate the images, but there is no danger here of a daytime image slipping in.
There is also a lot more room between the cloudy and clear night because on the cloudy night, it only took 11 seconds to get to my set point, but on the dark night, it hit my limit of 20 seconds and bumped up the gain to get over the minimum threshold. If I had set my tolerances tighter, the auto-exposure would have pushed the gain up until the brightness was closer to 0.35. At that point, using brightness alone, I would not have been able to separate them and filter out the clouds. The normalized value, however, would not change by much.
Using a mask to calculate those brightness numbers to just the sky will further separate the cloud/clear skies because the pixels outside the mask don't really depend on exposure time. Also, it's hard to provide advice to users on what values to set because every camera and lens is a little different, so the amount of black border and horizon is different. If limited to just sky values, then the numbers across cameras should be more consistent and independent of the gain and target brightness settings in each setup.
As for normalizing the brightness when combining images, it is certainly something I've thought about to smooth out brightness variations, but I'm not quite sure how I would do it without getting posterization artifacts when converting back to 8-bit channels.
Thanks @craigim, this is good and helpful discussion.
If you were to prioritize all the improvements and pick just 1 or 2 for the next release and plan other improvements for follow-on releases, what would you pick? Keep in mind that we'll almost certainly have a database in the next release where we can easily store per-image data like image name, night/day flag, exposure, mean brightness, gain, and possibly optional data like star count and cloud coverage. The startrails command will be able to accept a file name that contains a list of images to process (and they can be in multiple directories). All the intelligence about which images to include in the startrails could be contained in the script that creates the list of files (probably in generateForDay.sh or called by generateForDay.sh). @Alex-developer can correct me if I am wrong, but I am pretty sure the WebUI will have a way for users to create a mask, like to mask out everything but the sky. The RPi auto-exposure algorithm currently creates a mask internally that's (I think) a circle centered on the sensor and is 2/3 the height of the sensor. It would be a fairly easy change to allow it to read in a custom mask instead. The ZWO algorithm looks at the part of an image defined by the "Histogram box", but it doesn't use a mask so would take a non-trivial effort to read in a mask instead.
Are you willing to help with these improvements?
@EricClaeys, thank you for the updated scripts.
After two nights of logging the image capture data, and sorting it with a periodic test loging module, is successfully finding images that are more clear and dark than the default threshold using the Starcount metric. I'm attaching the stock version of startrails, as well as my sorting of 75 stars & 80 stars. The script still calls the threshold value, haven't figured out if there's a way to tell it to bypass the threshold, but its all good.
75+ stars:
80+ stars:
Stock AllSky startrails
I can post the cobbled modules (logger & sorter (sorter could have been just a little python script i guess..)) if anyone wants to test the method.
Runs in module manager as the LAST module before save (to catch a little extra data). Grabs the metrics and writes them to a CSV file in ~/allsky/images/DATA/ (just a holding path, no specific reason -but the sorting script calls the file from the DATA folder). The output of the sorted images is generated into ~/allsky/tmp/ .
For now though, I'm liking the output of the method. Starcount does seem to have some good promise in my testing. @EricClaeys helped by fixing up the logic in generateForDay.sh to enable the text-file list instead of a directory, as well as an updated startrails.cpp. It requires the updated generateForDay to allow the txt file pass through.
@jcauthen78, nice improvement.
Just so I understand, you're using the "Star Count" module to get a star count and somehow weeding out the images with too few stars, then you pass that list of images to the startrails --images file_name ... command or to generateForDay.sh --images file_name --startrails ... ?
The script still calls the threshold value, haven't figured out if there's a way to tell it to bypass the threshold
Which "script" ? The startrails command? If so, what I'm thinking is now that it accepts a file that contains a list of images, is to add the calculated mean brightness from the auto-exposure algorithm to each line in that file, so a every line would look like:
YYYYMMDD/image-20250710010203 0.234
When the startrails command see a number after the file name on a line, it would use THAT number when it compares the brightness to the Brightness Threshold, and not calculate its own value (which per prior discussions we know will be different due to the different ways the brightness is calculated).
Further, if the script that creates the list of files gets the "Brightness Threshold" from the settings file, it can add only images to the file that have a brightness less than the "Brightness Threshold". That means every image in the file will be included in the startrails.
@jcauthen78, nice improvement.
Just so I understand, you're using the "Star Count" module to get a star count and somehow weeding out the images with too few stars, then you pass that list of images to the
startrails --images file_name ...command or togenerateForDay.sh --images file_name --startrails ...?
Starcount module is always running on my system - don't think everyone has it running, but for this method, it's required. Starcount functionality could be added to the main logging module, but didn't want to reinvent the wheel since the module works pretty great as is.
So, image captures, modules process the image as normal, logging module runs as the last before save, saving data to a cumulative JSON file.
I run my periodic module in the morning to load the JSON file. Module has some basic criteria options of what to use as the filter. Filter runs as normal periodic, saves the filtered file-paths to a TXT file that lives in ~/allsky/tmp/.
~/allsky/scripts/generateForDay.sh --images /home/pi/allsky/tmp/starcount_trails.txt --output-dir /home/pi/allsky/images/20250801 --startrails
Image is generated.
The script still calls the threshold value, haven't figured out if there's a way to tell it to bypass the threshold
Which "script" ? The
startrailscommand? If so, what I'm thinking is now that it accepts a file that contains a list of images, is to add the calculated mean brightness from the auto-exposure algorithm to each line in that file, so a every line would look like:YYYYMMDD/image-20250710010203 0.234When the
startrailscommand see a number after the file name on a line, it would use THAT number when it compares the brightness to the Brightness Threshold, and not calculate its own value (which per prior discussions we know will be different due to the different ways the brightness is calculated). Further, if the script that creates the list of files gets the "Brightness Threshold" from the settings file, it can add only images to the file that have a brightness less than the "Brightness Threshold". That means every image in the file will be included in the startrails.
The filtering script could easily add the brightness to the string. But from the sounds of it, it'd be polling a database when it goes live. Either way, yes - file path + brightness would make a good check, bypassing the main threshold in allsky settings. Using the birghtness of the image is still valid - but adding in the requirement of Starcount # makes for a much cleaner result.
For now though, the current testing filter does a brightness check within a range, as well as if starcount > n, write path to txt file
Hopefully that makes sense.
@jcauthen78,
file path + brightness would make a good check, bypassing the main threshold in allsky settings
I'd think we do NOT want to "bypass the main threshold in allsky settings", but instead, use the Brightness Threshold setting along with the n in your star count check, and if the user has the Cloud Detection module, also use cloud cover in the check. And if the user checked the new "only use nighttime images" setting, use that as well i the decision of what to include in the list of files.
Do you agree?
I assume we want to make the star count threshold number a setting? Should it be an absolute number like 521 or a percent, or something else? If an absolute number that begs the question of how does a user know what number to use? And what can we put in Allsky to help them determine that number? Look at prior images of clear, moonless nights and count the stars? Etc.
@EricClaeys , You're correct - leaving the threshold in play is a good idea, and should be a used metric. My thought of bypassing it was mainly in testing.
since the database will be writing those details, the filtering should be fairly straightforward to pull Night only, Starcount #, brightness and pass it into the endOfNight.sh . I don't have an answer of where/how to pass it into the endOfNight yet - my testing has only been more of a manual push.
As for the global starcount # - that's going to be tough.... People living in Bortle 1-4 may be seeing 500+ stars according to the module, me in Bortle 5/6, on a near perfect night, I get maybe 120-140 stars out of Starcount. Maybe it's my tuning of starcount that its not pulling as many as it could, but still. Light pollution is going to be a tough one for quantifying a global starcount_base metric. Not sure how a % would work.... grab the high and low of the night and use the top 75%? It's going to need to be determined by the user I think - just as trying to find a good threshold setting. But with some thought, I'm sure we can come up with something. using a dynamic percentage could mean the startrails are very different night by night if the weather is messy.
I have the Starcount # written on my overlay, so I'm able to visually follow it in the timelapse across the nights. It's how I came up with my number.
@jcauthen78,
pass it into the endOfNight.sh
I'd vote to have the database query and creating the list of images that meet the criteria done in the "startrails" section of generateForDay.sh. That way, the correct files are used even when someone manually calls generateForDay.sh.
If there are no database records for the specified day, then startrails creation would be done as it currently is, with no criteria other than Brightness Threshold.
@jcauthen78
Not sure how a % would work.
just thinking off the top of my head and ignoring the difficulty in implementing...
If we created an allsky-config get_average_starcounts command, it could first check if there was any per-image data saved in the database that contained star counts. If so, it would use those starcounts from one or more nights. If not, it would look at some number of prior nighttime images and run starcount on them. Looking at records in the database would be a gazillion times faster than looking at actual images to determine starcounts. In theory, this should only be a factor right after someone upgrades to v2025.xx.xx, before it's had a chance to save image data to the database.
Or maybe, if there wasn't any database data yet, allsky-config get_average_starcounts would simply tell the user to try again after a couple clear nights. In the meantime, startrails creation would work like it does today, and use Cloud Cover module data if it existed.
Either way, allsky-config get_average_starcounts would then use those starcount(s) to determine an average number of stars. Maybe it needs to also keep track of the average brightness of all the images to account for moon-less and moon-full nights. Or at least track the moon visibility percent.
The average number(s) of stars would be saved to the database as well as the average brightness of the images used in calculating the average number of stars. For example, it might come up with 120 average stars for a night when the average image brightness was 0.3 and 150 stars when the average brightness was 0.2.
As the user gets more nights of images, they could run allsky-config get_average_starcounts again to get a better average number of stars under different conditions.
We'd add a new setting in the WebUI for the % of stars needed to include images in a startrails (in addition to the new setting for "Use nighttime only images" ??). The % the user entered into the WebUI would be the percent of the average number of stars that need to be in an image. The user wouldn't necessarily need to know what the average number is, but it probably wouldn't hurt to show it. On a night when the average image brightness was 0.3 it would be a percent of 120 stars. On a night when the average image brightness was 0.2 it would be a percent of 150 stars.
Entering a 0 for the percent would cause the starcount to be ignored.
We'd need to come up with a default percent - maybe 50% ?
@EricClaeys - a few thoughts:
Not sure how a % would work.
just thinking off the top of my head and ignoring the difficulty in implementing...
If we created an
allsky-config get_average_starcountscommand, it could first check if there was any per-image data saved in the database that contained star counts. If so, it would use those starcounts from one or more nights. If not, it would look at some number of prior nighttime images and run starcount on them. Looking at records in the database would be a gazillion times faster than looking at actual images to determine starcounts. In theory, this should only be a factor right after someone upgrades to v2025.xx.xx, before it's had a chance to save image data to the database. Or maybe, if there wasn't any database data yet,allsky-config get_average_starcountswould simply tell the user to try again after a couple clear nights. In the meantime, startrails creation would work like it does today, and use Cloud Cover module data if it existed.Either way,
allsky-config get_average_starcountswould then use those starcount(s) to determine an average number of stars. Maybe it needs to also keep track of the average brightness of all the images to account for moon-less and moon-full nights. Or at least track the moon visibility percent. The average number(s) of stars would be saved to the database as well as the average brightness of the images used in calculating the average number of stars. For example, it might come up with 120 average stars for a night when the average image brightness was 0.3 and 150 stars when the average brightness was 0.2. As the user gets more nights of images, they could runallsky-config get_average_starcountsagain to get a better average number of stars under different conditions.
Since there's functionality for the moon phase already being reported (if moon is enabled in overlay editor - i'd enable it by default i think), It's an easy metric to add into the database
- File path/name
- Exposure
- Gain
- Brightness
- moon %
- Starcount
- Cloud Cover (would be a great feature..)
- Meteor/Streak count (if people wanted to eliminate aircraft)?
- other potentially useful metrics..
We'd add a new setting in the WebUI for the % of stars needed to include images in a startrails (in addition to the new setting for "Use nighttime only images" ??). The % the user entered into the WebUI would be the percent of the average number of stars that need to be in an image. The user wouldn't necessarily need to know what the average number is, but it probably wouldn't hurt to show it. On a night when the average image brightness was 0.3 it would be a percent of 120 stars. On a night when the average image brightness was 0.2 it would be a percent of 150 stars.
Are you thinking the average data be generated with a Find my startrails settings button? or a page/module with basic settings that, during endOfNight, auto-generates the numbers based off the default values, so the user has a simple quick glance, maybe a button "Use suggested values for Startrails"?
Entering a
0for the percent would cause the starcount to be ignored. We'd need to come up with a default percent - maybe 50% ?
I don't know what a base starting point would be - here's a quick analysis of 2 recent nights. both semi cloudy, and both semi smoky off and on too. Maybe some of this may help some of the bigger brains with the determination. Again, this is only 2 nights, so not the most robust dataset.. but its something. Didn't want to clutter, so dropping a txt file. percents.txt
@jcauthen78
Are you thinking the average data be generated with a Find my startrails settings button?
I'm finding the allsky-config command to be very useful and have been adding more commands to it every release, so at a minimum, I'd like to use it to do the guts of the work.
When a user enters allsky-config on the command line, they are shown a menu of possible actions, similar to raspi-config. The action they choose may prompt for additional information if needed. When the action completes, it writes its output to the screen, then shows the user the menu again. Nice, but not useful to automate something.
However, if the user specifies an action to take on the command line, like allsky-config get_average_starcounts, that action is executed with no prompting. When the action completes it writes its output to the terminal and exits. It's possible to add arguments to the action, like
allsky-config get_average_starcounts --threshold 3.0 --images file_name
The beauty of this is that the WebUI could call the command, passing any arguments as needed, and the output can be displayed on the web page. So we could also have a user-friendly web page where the user enters some options, then the WebUI passes that data to the command. The real work is centralized in the command.
While developing this, we'd probably run the command on the command line. Once we know what works and what data is needed, we could create the web front end (which we may delay until a point release). I suppose it's possible that we don't need to prompt the user for much, and users only need to do this once, in which case we may not bother with a web front end.
Regarding WHEN this would be run, I think it would be really cool if the WebUI could figure out when it should be run, then prompt the user to run it. If we want to only use data saved in the database, it should probably be run after a clear night or two. The WebUI could also prompt the user to re-run it after a month (for example) of data.
Are you thinking the average data be generated with a Find my startrails settings button?
I'm finding the
allsky-configcommand to be very useful and have been adding more commands to it every release, so at a minimum, I'd like to use it to do the guts of the work. When a user entersallsky-configon the command line, they are shown a menu of possible actions, similar toraspi-config. The action they choose may prompt for additional information if needed. When the action completes, it writes its output to the screen, then shows the user the menu again. Nice, but not useful to automate something. However, if the user specifies an action to take on the command line, likeallsky-config get_average_starcounts, that action is executed with no prompting. When the action completes it writes its output to the terminal and exits. It's possible to add arguments to the action, likeallsky-config get_average_starcounts --threshold 3.0 --images file_name
I don't know enough about the allsky-config yet, so not sure what it can or can't do, I'll have to lean on your expertise on that end.
The beauty of this is that the WebUI could call the command, passing any arguments as needed, and the output can be displayed on the web page. So we could also have a user-friendly web page where the user enters some options, then the WebUI passes that data to the command. The real work is centralized in the command.
While developing this, we'd probably run the command on the command line. Once we know what works and what data is needed, we could create the web front end (which we may delay until a point release). I suppose it's possible that we don't need to prompt the user for much, and users only need to do this once, in which case we may not bother with a web front end.
Regarding WHEN this would be run, I think it would be really cool if the WebUI could figure out when it should be run, then prompt the user to run it. If we want to only use data saved in the database, it should probably be run after a clear night or two. The WebUI could also prompt the user to re-run it after a month (for example) of data.
That could work. It'll definitely need a fair average of nights to get initially tuned. If the user is lucky enough to have gorgeous skies 3 nights in a row, that'd probably be good enough. But a user like my situation, mostly cloudy for a few nights & smoky - mine is going to take a few more days to average out. The idea of a monthly check could be helpful, maybe have the update once a month in the background, add the values to the DB, letting the user see what their skies did over the months - following the averages.
@jcauthen78, Your percents.txt file is impressive. Eric
Thanks :) The bortle is a massive W.A.G based on a lot of assumptions from googling random methods of determining bortle a few years back. I wouldn't say its scientifically accurate - but was a fun test to throw in. The percentiles were cobbled from some of my other data analysis scripts from my weather station. I'm a data hoarder, lots of random stuff all over the place.
If you were to prioritize all the improvements and pick just 1 or 2 for the next release and plan other improvements for follow-on releases, what would you pick? Keep in mind that we'll almost certainly have a database in the next release where we can easily store per-image data like image name, night/day flag, exposure, mean brightness, gain, and possibly optional data like star count and cloud coverage.
Having access to the metadata is pretty key right there, whether from the Exif or from a database because it opens up a lot more sophisticated processing and analysis. Before I would make big changes to the algorithm, I'd want to have an opportunity to play around with those variables in the processing to see what works the best.
The RPi auto-exposure algorithm currently creates a mask internally that's (I think) a circle centered on the sensor and is 2/3 the height of the sensor.
That's basically what I was trying to recreate with my mask. I use 90% instead of 66%, but the idea is the same. My reading of the docs was that the whole image was used, but that could just be me skimming. In the python script I wrote, I made the size of the circle a command-line option with a default. Being able to point to a mask file would also be a good option.
Are you willing to help with these improvements?
If the changes are in python, I can spend a little time on it, but that and MATLAB are my only two languages. I also exclusively use GitLab instead of GitHub at work, so there is going to be a bit of a learning curve there.
@craigim,
My reading of the docs was that the whole image was used for auto exposure.
Do you remember where it said that?
I didn't write the RPi algorithm and it took me a while to understand part of it, so it's very possible I wrote that part of the documentation before I knew what the algorithm actually did.
When we allow users to specify a mask for auto-exposure we'll need to update the documentation.
Another thought for the backlog less technical than determining best images could be a feature/story to allow a user to apply an overlay mask at the end of creation to clean up the final image. eg to remove all the blurry changing text (timestamp, sensor data, etc)? example:
And maybe as a separate second sub-story to evaluate, possibly adding specific startrails image overlay text along with or separate from the mask. Of course the variables I have included below add more complexity to the idea. Maybe a user would want to add something like:
Startrails image from night of 2025-02-08.
380 of 700 images used with an average of 85 stars detected.
@NiteRide, Interesting idea. Assume for discussion's sake that we added a new "startrails" flow in the Module Manager that had its own overlay template, and that flow was executed at the end of startrails execution. Users could then add modules to the flow, like the Image Mask module followed by the Overlay module which would easily allow doing what you show.
v2025.xx.xx can now create multiple startrails or multiple stretched images using different settings (Brightness Threshold for startrails and Stretch Amount and Mid Point for stretches). It then shows the images on one page so the user can decide which is best, and hence which settings to used. Right now the file names have the setting values in their names and the file name is shown below each image.
I would like to add that info to the images, so I asked @Alex-developer about allowing a script to call a module or series of modules. Exactly as described above, but for any new flow with any overlay template. The script would create a test image, then create an overlay template with the setting values and appropriate text, then execute the flow with that template. The flow would call the Overlay module which would add the text. The script would then do the next test image.
Your suggestion and my request to Alex would both use the same mechanism, but with different parameters.
@Alex-developer, Thoughts?