StellarSolver for Android? #85
Comments
|
So that I do not know, I do not have any experience with that. A big first question is whether all the dependencies are supported on Android. If so, then it could be possible. |
|
Hi @rlancaste The library mentioned in this comment is NOT a dependency of astrometry.net but it has a detailed description, how to build a library using NDK for Android platform. Can be used as a starting point. I also will try start with dependencies one by one and build them. |
|
Would the idea for this be to have it included in KStars for Android? |
|
I have an Android build of astrometry.net that seems to be working at least partially. Now trying the pure binaries (including also the dependency libraries and some index files) directly on my Samsung Galaxy S20+ device (rooted). Output from Android Terminal:
The above error message comes from the bl.c source file. Is there any option or switch to force astrometry to use less memory? Or I don't know, what to do with this error. Anyway I will try to rebuild while experimenting with the build settings. BR, Ladislav |
|
FYI, I successfully built the whole astrometry.net including dependencies. Tested were following tools from suite:
All of them worked perfectly! Question is, what's next? BR, Ladislav
|
|
Ah that's cool. So next would be to see if we can build StellarSolver on Android or if we have to make any changes to make it work there. If it does work on Android, then we could include plate solving and Ekos on Android perhaps |
|
So I just asked Jasem about it and he said that there isn't anybody currently working on or maintaining KStars for Android. While we could certainly get StellarSolver working for android, based on your success so far, the issue would be that next step. |
|
OK, I will try to build StellarSolver for Android (armv7a and aarch64 architectures) and let you know. Android NDK has LLVM toolchain with clang compiler, it works pretty much the same way, as in Linux. |
|
If you just build the library you should get libstellarsolver in the lib directory, as well as some include files in the StellarSolver subfolder of the include directory. If you also build the tester, then you should get StellarSolverTester in the bin directory |
|
Hi @rlancaste Trying to build StellarSolver for Android platform, and the cmake somehow can't find the gsl library, but it founds cftitsio. Here is how I call cmake: ...and here is the output:
As you can see I am exporting PKG_CONFIG_PATH variable and setting its value find all the dependencies. Any idea, why it does not work for GSL ? BR, Ladislav |
|
I don't know if this is relevant or not, but sometimes when people have trouble finding GSL on their systems, it's because they don't have the dev version of GSL installed. Is that an option on Android? |
|
I have this version: I built this for Android and as output I have headers and library files as usual. BTW there is a note on the above page, that the gsl build should be configured with:
Is that maybe required? I did not start configure with the above switch. |
|
Were you able to get this to work on Android? |
|
Hi @rlancaste I was not able to build this project for Android. It always failed to detect GSL library. BR, Ladislav |
|
Hi @rlancaste Not directly related to this topic, rather a general question to StellarSolver: BTW I gave up fighting with StellarSolver build for Android. The cmake simply cannot found the GSL dependency. BR, Ladislav |
|
Hi there, it depends on what solver you are using. If you are using the external solver, it makes parallel threads and each one calls solve-field with different parameters. All the threads share the same config files. If you are using the internal solver, it creates parallel threads and each one runs the solving methods with different options. It doesn't use any config files at all in this case. Sorry to hear about the issue with Android. Sorry I couldn't help, I have no experience with android. |
|
Hi @rlancaste In case of an external solver (solve-field) what is the benefit of parallel threads sharing the same config file? I would expect parallelism to speed up the solving time but I can't really imagine, how could the same shared config file help with that. In such a case for each thread, the same index files are processed in the same order. I am talking about the case of varying field input images. For example, for a narrow-field ( < 1 degree ) input image, the solver engine must process many index-files while finding the matching one. When all threads do exactly the same index files processing in the same order, it is just a waste of CPU/IO resources, or am I wrong? Regarding the StellarSolver build for Android: The problem is NOT related to Android. The build system is very similar to or almost the same as on the desktop Linux systems, it is an LLVM toolchain. Also, the build itself happens on an Ubuntu Linux machine. The problem is somewhere at cmake and/or CmakeLists.txt and/or modules/FindGSL.cmake. BR, Ladislav |
|
The reason is because the config file just sets a couple of the parameters, most of the settings for astrometry.net get set using options, not the config file. In the separate parallel threads, to speed up the solve, I have multiple instances of astrometry searching different scales or alternately different "depths" (a term astrometry.net uses). You could also search different areas of the sky simultaneously, but I think there was a reason I didn't do that one. But I guess you could use the config file if you wanted to since there are options in there that could be set differently for different simultaneous solves. I don't want to do that myself because that means more files need to be generated and Raspberry Pis don't like too much of that. It was just as easy to parallelize the scales and depths, which are just different parameters/options and don't require extra files. |
|
OK, thanks for explanation. First I will try multiple solver threads with different scales option while sharing the same config. BTW you can try my experimental Android build of astrometry.net if you want. I can send you the APK file you can directly install on your smartphone. Are you interested? |
Hi @rlancaste A bit late but back to the quoted question: Now the additional question: BR, Ladislav |
|
Hi again Ladislav, Good to hear that you have progress! As for skipping QT5, I don't think that would be possible right now because I used QT a lot in the coding of the main classes for StellarSolver. Yes, you can certainly build the library without the GUI, since that is done all the time for KStars on all the OS platforms, but it still relies on QT classes. Certainly if you find a way to avoid that, or make a change that might support everything it currently does but does not make other things not work or sacrifice its cross platform performance, then wonderful and I would be glad to accept changes. At the moment, I can't really embark on a big project like that because I am in the middle of starting up the school year since I am a teacher, and I am also taking classes for a masters degree, and working on some other projects as well. But if you want to try to make changes and want me to check them out and provide feedback, or accept changes once you add something, then great! Thanks, Rob |
|
OK, understand. |
|
No, the library itself is just meant to be a workhorse for programs like kstars. As far as I recall, the GUI related items are all in the Tester program, the batch solver program, the utils library (for other programs to use), and other example programs. |
I mean for example the and similar things. I guess they are some basic QT5 data types and nothing GUI related... |
|
Yes, I used QT as the basis for my coding since it is cross platform and KStars is a QT program. That stuff should not be related to GUI since the stellarsolver library has no GUI. The other programs based on it do, but the library itself does not. |
|
if we make big changes like in parameters.h or data types though, we will need to take our time and do it in a branch and get feedback from others and test it thoroughly, since changing data types that the other programs are built upon will change what they are expecting to get. Even then, making changes like that can cause problems still because of people using older versions of the library vs. newer versions of kstars or vice versa. |
|
I know I changed the data structs a few years ago, and it was a few weeks to months before all the issues worked themselves out |
@rlancaste |
|
Sounds great! |
|
Hi Now I am at the point when the linking fails - output of make command:
Any idea, what is this qsort_r symbol, what library it is coming from or how to workaround it? BR, Ladislav |
|
So, qsort-r is a system method and it as well as several other features are tested for by astrometry.net in os-features.c which is one of the first things that cmake does on your system. As far as I remember, it runs a test program and if it finds the symbol in your system, it will use that method, but if not, it will declare its own method to perform the function. That way there won't be a conflict with two symbols with the same name. I found it to be a little clunky, but I tried my best to implement that functionality in stellarsolver as close to what happens in astrometry.net as I could. When I made stellarsolver in 2020, it was on version 0.76. I think the fixed this issue in version 0.82 by removing those tests and always using their in-house functions somehow. Updating the code now so that it is based on the latest astrometry code would take a lot of work and I cannot undertake that project now. But during a summer I certainly could. To see what is wrong in your build, why don't you check what happened after the test code was run. The results are saved in the include folder in os-features-config.h. Perhaps on your system qsort-r needed to be declared and set up but it was not? |
|
Good news! Finally, I built StellarSolver library plus tests and demos for Android. Now the question is, what do we want to do with this? Maybe a PR to a new branch? Update: Example:
|
|
Hi guys, first I would like to congratulate both of you, for the huge effort invested into porting a very complex code. I am currently dealing with the acquisition of burst stack astrophotography, using the Android camera2 API. My ambition is to forward a stacked pan uint32 little-endian array to Android SEP (without FITS conversion), for background and source extraction. A less ambitious goal, involves intermediate DNG to FITS step, but I would like to avoid it... My kind questions, for you: With Best Regards, DD |
|
Hi Sarajevo67, Sure I can definitely include this if it can be included in a way that doesn't break anything else needed for other operating systems. A number of big projects like KStars currently depend heavily on this and I don't want to break it. laheller, I would be glad to include your work if you can get together a pull request and we test it throughly to make sure it doesn't affect other things. We could also add scripts and instructions for working with it on Android vs. the other systems. Sorry I have been kind of busy recently and haven't worked on much, but I am going to have more time in the spring/summer that I can work on things again. Thanks, Rob |
|
From my side what I miss in this library is a small C language wrapper around some of the C++ API functions, see my previous comment for examples. Beside that I already built the library for Android and I have the binaries. BTW what is your goal with Android Camera2? BR, Ladislav |
It is library anyway and adaptation for different job entry points looks natural. For me it is around bayer.c, but it depends what @rlancaste find appropriate, that doesn't break anything else needed for other operating systems.
Yes, and it is, most probably, true intent of Android port. Originally I wanted to use Mark Harman Open Camera TakePhoto widget, but overall package is too massive for simple, single purpose infinity/ISO/exposure/burstCount - acquisition. When we have embedded acquisition, it seems logical to do Bayer level stacking, noise and hot pixel removal in NDK, then forward array to bayer.c, for demosaicing (in that case single uint16 array is forwarded). Your suggestions are welcome. |
|
OK, I will share my build scripts including some instructions in the fork of this repo. Once available, will let you know. A hint to the raw images processing got from Camera2 API: |
|
You can clone the fork here and follow the instructions: |
|
Thank you!!! BR, DD |
|
Hi @laheller
I couldn't find in OpenCV (in SEP also), pre demosaicing, hot pixel detection/correction? Most of tools available, doing hot pix processing after deBayer, when noise already blended in the neighborhood. Stellar Solver utils bayer.c, has nice demosaicing collection, from simple to HQ and it would be great to complement it with hot pixel correction. Problem is not a trivial one and traditional 'difference from median' approach, does not work well for automated astrophotography (2 pixel distance for same color R and B pixels). BR, DD |
@Sarajevo67
The hot pixel detection/correction could be done by using OpenCV's median filter function, as described in this answer. Good Luck! |
|
boofcv( java image deal lib) can be instead of opencv to deal image |
sir, I encouter the same problem , Could NOT find GSL (miss :GSL_INCLUDE_DIR) , Can U share how to solver the problem,
sir, I encouter the same problem , Could NOT find GSL (miss :GSL_INCLUDE_DIR) , Can U share how to solver the problem, |
It won't work using the You have to specify in cmake command line: |
thank u sir ! BR |
Hi @rlancaste
This is not an issue, just a question.
What do you think, is it possible to build this library for Android platform using the Android NDK?
BR,
Ladislav
The text was updated successfully, but these errors were encountered: