Closed sebmueller closed 3 years ago
Good idea. I'm not going to merge your patched version; there's a lot of duplicated code and doesn't have the quite the scheduling control I'd like to have. But it's a good start that I can build on... Thanks for the suggestion.
hi chris, i saw, the code was not cleaned. I'm sorry. But I'm happy that you like the idea.
:)
No worries - you contributed some actual code and that's extremely helpful. This is also relevant to my interests, since I reprocess on my workstation with lots of cores and memory.
Re the dimension check, there was already a check with the -s <width>x<height>
flag that you can use to restrict processing. startrails -s 123x456 ...
would only operate on images that are 123 pixels wide and 456 pixels high, for example. Let me know if that doesn't do what you need it to.
I'll do keogram in a separate diff.
hi,
i played around with the allsky software and had to run the startrail app often, to find a good brightness level.
there I found, that it was very slow. in htop I saw, only 1 core of my raspberry was used, 3 cores had nothing to do.
after investigating the code, I got the idea to run the mathematical part of startrails in more than 1 thread.
so I extended the code to 4 threads, controled by a new command line flag (-m).
see the screenshot of htop, using all the raspberry calculating power. the calculation of the startrails is almost 4 times faster than the single core code.
please see here the modified file. it is not optimal, but fast an good for raspberry 3 / 4.
I also added a dimension check of the images, because i use image cropping and sometimes, the images are in original size, not cropped.
startrails.zip