Tagged: kstars Toggle Comment Threads | Keyboard Shortcuts

  • Akarsh Simha 1:38 am on January 2, 2014 Permalink
    Tags: , , , , kstars, , , scripting, shell scripting   

    Astro-scripting using KStars' D-Bus interface 

    I was telling Henry about
    an interesting use case of KStars a few days ago, and he
    suggested that I blog about it.

    I encountered this problem while preparing for a Practical Amateur Astronomy workshop that we were organizing. We had made lists of
    various celestial objects for people to observe, along with some
    hand-written descriptions. We edited the lists collaboratively on
    Google Spreadsheets, and at some point I declared the lists final and
    made a CSV export. I wanted the lists to be organized by constellation
    and also have some more vital information about the objects filled in.

    Enter KStars and D-Bus. KStars has D-Bus interface functions that let
    you access many of its features. I use qdbus to access
    them over the shell. (Note that the following is known to work on
    GNU/Linux. I am entirely unsure about Windows and Mac
    platforms). Here’s a brief example of making KStars point towards M

    qdbus org.kde.kstars /KStars org.kde.kstars.lookTowards "M 33"

    (Note: Due to some bug in KStars at the moment, you need to invoke the
    above multiple times to get the object in the center)

    Then, let’s say we want to query information on NGC 2903. We can do so
    by using:

    $ qdbus org.kde.kstars /KStars org.kde.kstars.getObjectDataXML "NGC 2903"

    and KStars outputs an XML blurb describing the object.

    One can now use tools like xmlstarlet to work with the
    XML on the command line.

    There. That has all the information I need to complete the
    checklists. So I went ahead and wrote a small shell script to order
    the objects by constellation and typeset a table using LaTeX. The
    results look like this:


    Many more wonderful things are possible because of the D-Bus
    interface. In fact, my Logbook project
    relies heavily on KStars’ D-Bus interface. The Logbook project uses
    KStars to produce amateur astronomers’ logbooks complete with fine and
    coarse finder charts, relevant data and DSS imagery.

    One can use qdbusviewer and qdbus to further
    explore the available D-Bus methods in KStars and profit from
    scripting using KStars.

  • Akarsh Simha 4:45 pm on January 2, 2011 Permalink
    Tags: , kstars, OpenGL,   

    KStars with experimental OpenGL support in RC2 

    Well, this was a little hurried and late, but I introduced some largish changes into what’s going to become RC2 just a few minutes back. No new strings, to the best of my knowledge. Let me explain what they are.

    Harry de Valence worked with KStars this summer and his (GSoC) project involved writing code that would render the sky map with OpenGL, while still keeping the native QPainter drawing, to ensure that KStars doesn’t crawl on older hardware without hardware acceleration. Well, Harry’s task was rather tough, because he had to deal with badly structured code, but he was able to give us a working OpenGL sky map with a few regressions at the end of his project. The most important unsolved problem, however, was that there was no way to switch between the two paint engines at run time.

    We decided not to leave the code in Harry’s branch, and merged it into trunk, so that the code would be more accessible, and we might arrive at a solution at least before release. When 4.6 was branched out from trunk, we had a version of KStars that would throw up a black screen with some text at the corners upon launching! This was one of the regressions with OpenGL — you couldn’t use infoboxes (those boxes that tell you what KStars is looking at, what the time of the simulation is etc.) with GL, so you had to manually disable them to see the sky map. And to add to that, we had a couple of other problems with GL. And you couldn’t switch out of GL without rebuilding KStars.

    Of course, one of the solutions was to just disable GL and fallback to QPainter, without adding any new functionality, but lots of new code. I didn’t want to subscribe to this — it gives me this feeling that I’m doing what some proprietary software companies do to enforce DRM.

    Our solution to this problem involved breaking up a class that’s very central to KStars — the SkyMap class, which took care of the sky map in totality — painting, projection, events. Not good. Harry had already broken away projection, and in the process of cleaning the code, solved several really strange bugs in KStars. What was left was to break up painting and event handling, so that we could change our canvas at run time.

    This time of the year being the winter break at UT Austin, I thought I should finish this. My implementation of this (warning: physics student trying to write code) is now merged into the 4.6 branch. I should’ve probably done it before, but yeah, it stretched to fit the time before RC2.

    The only regression I observe with this change over the usual native painting functionality, is that infoboxes flicker when you drag them around. I’m sure that’s a very small thing to trade for the awesome speed and smoothness that GL gives you, when you need it.

    So you can now switch backends at runtime:

    Screenshot explaining how to switch to OpenGL in KStars 2.0.0

    Switching to OpenGL backends at runtime!


    We most certainly need a whole lot of testing. Please help the KStars team by seeing if it builds, renders fine, switches backends with no issues, and file any bugs you may have on bugs.kde.org. We will try to fix them before the final tag.

    Thanks for reading.

    Time for me to get back to physics now!

    • Martin Gräßlin 7:17 pm on January 2, 2011 Permalink | Log in to Reply

      I just built kstars from trunk and gave it a try with fglrx driver. I am sorry to say that it does not work at all 😦 I only see a white screen and when I start to move the scene I get lot’s of flickering with visible stars in between.

      Btw: which OpenGL version are you targeting?

      • Martin Gräßlin 8:01 pm on January 2, 2011 Permalink | Log in to Reply

        Just tried on my other system with nouveau driver (which renders KWin GLES correctly) and I see some rendering artefacts in the milky way.

        See: http://wstaw.org/m/2011/01/02/plasma-desktoprL2578.jpg

        It does not mean that there is a problem in the rendering, it could as well be a bug in nouveau. Nevertheless it might be worth to look at it 😉

        • Med 8:54 pm on January 2, 2011 Permalink

          If i remember it was reported that it worked fined with mesa’s software rendering. I have no way of testing that easily before the final version is out. Wouldn’t it indicate that the problem is in nouveau? As for the fglrx driver, do you have any clue where the problem might be?

        • Martin Gräßlin 9:13 pm on January 2, 2011 Permalink

          If i remember it was reported that it worked fined with mesa’s software rendering.

          The mesa software rasterizer has nothing to do with the Gallium3D state tracker used in nouveau

          Wouldn’t it indicate that the problem is in nouveau?

          Maybe? Maybe not? Difficult to say. As I have problems with other drivers as well I would not bet on driver bugs.

          As for the fglrx driver, do you have any clue where the problem might be?

          No sorry, I do not know the KStars code at all. So I cannot comment on it.

        • Akarsh Simha 2:56 am on January 3, 2011 Permalink


          I want to ask if the QPainter backend works properly on these systems. If that is not the case, this would be release critical, and we may need to revert the entire OGL stuff.

          Can you see the Sky map in QPainter mode with no regressions?


    • Manuel Mommertz 8:24 pm on January 2, 2011 Permalink | Log in to Reply

      With intel graphics, it works very well. I couldn’t see any rendering glitsches. Works quite fast. Though I had to deactivate the rendering of the milky way while moving as this was very slow.

      • Akarsh Simha 2:58 am on January 3, 2011 Permalink | Log in to Reply

        Oh. I haven’t had Milky Way trouble. But when running at 2 minutes / frame speed, I got 16 fps with OpenGL and ~ 6 fps with native painting.

        • Manuel Mommertz 3:12 am on January 3, 2011 Permalink

          milky way is deactivated on move per default. so if you don’t explicitly activated them, you don’t see it 😉
          how do you get the fps numbers?

        • Akarsh Simha 3:22 am on January 3, 2011 Permalink

          Oh, didn’t realize that. I hardly twiddle with the hidden objects settings 🙂
          If you built with debugging, then you’ll see the FPS numbers being written to the console. Maybe we should do something more elegant.

  • Akarsh Simha 3:23 pm on September 14, 2008 Permalink
    Tags: kstars, USNO NOMAD   

    USNO NOMAD 1e8 Support for KStars – Screenshots 

    Stars to mag 16.x in KStars

    Stars to mag 16.x in KStars

      Stars to mag 16.x in KStars

      Stars to mag 16.x in KStars

      The Core of the Milky Way

      The Core of the Milky Way

    • Stephen Uitti 7:20 pm on June 22, 2009 Permalink | Log in to Reply

      I installed kstars using the package from Ubuntu Jaunty. The setup wizard walks you through downloading stuff via the kstars add-on installer. All the other downloads work, but after downloading USNO, it never does work. I’m sure others have run into this. I have 32 bit Athlon and Intel systems, and an Intel 64 bit system, all showing the same behaviour. The default filesystem block size for e2fs is 4096, which is enough for very, very large files. One of the leads found on the usno site suggests that perhaps KNewStuff2 is involved in this failure. I’d like even a manual way of getting this to work.

    • Akarsh 10:16 am on June 24, 2009 Permalink | Log in to Reply

      Yes, I guess it’s some KNewStuff2 problem, or something wrong with the server. Many people have reported problems like this on the mailing list etc.

      The workaround is to go and download the catalog tarball from here

      Put the tarball into your KStars home directory, which is at ~/.kde4/share/apps/kstars/ by default, and unpack it there.

      When you load KStars after doing this, it should pick up the USNO catalog and load it.

    • Stephen Uitti 10:59 am on June 25, 2009 Permalink | Log in to Reply

      This totally did it for me. 16th mag stars. Totally what i need to find Pluto this summer. Now is a good time to start that project.

      And, it turns out, i’ll be using kstars in my talk at the club today. Well, it is entitled “Observation Planning with Free Software”. IMO, Stellarium and Celestia are not as good for planning. But i include FireFox as “free software” that you need for this.

      And the blog post version:

    • MadEye 5:34 pm on August 21, 2009 Permalink | Log in to Reply

      Okay, I have installed kstars.. The first interactive window I see is a Startup Wizard. It prompts me
      to “Download Extra Data”. I clicked on the first catalog I see and suddenly I find I’m stuck (without warning) with a 6-hour download! I cancelled the download, hoping to restart it later that night and let it run overnight. But I find I can’t restart it. The program says it’s installed, and I don’t get any second chance.
      Then I reinstall, few times, wiith deps, expecting see the startup wizard giving me a clean slate and a chance to avoid the surprise of a 1.6GB download, but it still shows that catalog is already downloaded!
      Clearing ~/.kde3.5/share/apps/kstars doesn’t fix this problem
      Im using owncompilled KDE on Gentoo.
      Please help me!

    • Stephen 6:26 pm on August 21, 2009 Permalink | Log in to Reply

      When i did the install, it put the file in /tmp/kde-myusername. It wasn’t named USNO-NOMAD-1e8-1.0.tar.gz – or even with any kind of tgz extension. But it extracts with tar xzf filename. I manually put the result in
      and it’s happy with it.
      If you launch kstars, the Settings -> Startup Wizard
      will bring you to the downloads screen. You should be able to Uninstall, then install. But really, it’s easier to get the file from the source, extract it, and put it where it goes. For example.

      wget -c http://download.kde.org/apps/kstars/USNO-NOMAD-1e8-1.0.tar.gz

      I always use -c. If your connect fails, you can pick up where you left off.

    • Zescemnseex 7:25 am on May 17, 2010 Permalink | Log in to Reply

      Very nice vidps3atxvipx

  • Akarsh Simha 1:28 am on July 17, 2008 Permalink
    Tags: , kstars   

    Memory Management UI – Trial #2. 

    I’m going on my third north Indian trip tomorrow, spiritual purposes only. So I’m off the net for next 2 days. I happened to hurriedly do this:

    I’d want comments on that UI, because I have no idea about UI design.

  • Akarsh Simha 2:33 am on July 14, 2008 Permalink
    Tags: , , kstars, Tycho-2   

    2.5 million stars in trunk! 

    Yay! All the machinery for loading 1e6 stars has been moved to trunk and the 2.5-million-star Tycho-2 catalog has moved to the ‘Download Data’ (Get Hot New Stuff) feature. I plan to put up a screencast on how to use this and the conjunction tool from KStars sometime, along with a whole lot of other features.

    To get the Tycho-2 deep catalog, just click on File->Download Data and click ‘Install’ next to ‘Tycho-2 Star Catalog’.

    • Carlos Scarsi 3:53 am on September 2, 2008 Permalink | Log in to Reply

      Hi. I’m new in linux and kstars. My kstars only goes up to mag 9, not 12. The tycho-2 catalog is installed. I’m using it on ubuntu (gnome). Do you know why? Thank you very much. Carlos Scarsi

    • Akarsh Simha 1:02 pm on September 20, 2008 Permalink | Log in to Reply

      @Carlos: Sorry for such a late response. It is probably because you aren’t using the latest version.

      The Tycho-2 catalog works only with KDE 4.1.60 or something like that (and above). Currently, the 2.5 million stars are in what we call the ‘trunk’ (the source code that developers work on). You will either need to wait till Ubuntu ships the new version of KStars or compile it from the sources.

      Mail me at akarshsimha () gmail ! com if you need a faster response. (Replace the brackets by @ and ! by .)

  • Akarsh Simha 3:50 am on July 12, 2008 Permalink
    Tags: , , kstars, Proper Motion   

    KDE.IN Monsoon Hackathon – Day 1 

    Day 1 was almost entirely spent by me in the following activities:

    • Install Debian on one of the systems Atul had so kindly provided us with. (They have a local Debian mirror, so it rocks!!)
    • Copy the KDE sources from Sharan’s harddisk
    • Play around SSHing into my system
    • Build KDE
    • Discuss about FOSS.IN 2008 and KDE’s place
    • Frantically realise that you’ve done nothing at the end of the day and try to commit something that builds, whether it adds some value or not

    I had a nice time being with all the KDE kontributors around. We also had a few talks by Pradeepto, explaining David Faure’s method of setting up the KDE source tree and svnmerge.py.

    Other folks did useful things – Pradeepto made a release (of what, I don’t know. Definitely will have to do with KDEPIM or KMail). Tejas commited his Bonjour plugin for Kopete.

    I learnt something about Bonjour from Tejas. Nice thing it is. Sharan has agreed to help me use EMacs more like an IDE than like “Notepad”.

    Dinner @ Nandini, RMV Extension. Dinner back @ home as well, because I had promised the folks at home.

    Although we could only get the stuff building today, the inspiration from the KDE Hackathon got me working all night till now (despite the fact that I need to get to Day 2 tomorrow) fixing some stuff. Finally, it looks like I have “achieved” all my GSoC goals. Anyway, that apart, the proper motion code is tested and found to be proper – that’s a good thing. I finally learnt how KStars draws lines on screen (many thanks to Jason. I’d have been lazy to find out myself :P). I also commited the data files that had the duplicate entries, because they seemed to work without any trouble.

    Finally, I thought I must blog about ‘Day 1’. Atul was insisting that we all blog, so here it is :). We are also actively microblogging on twitter at http://www.twitter.com/kdehackathon

    Looking forward to Day 2. I hope to:

    • Ensure that binfiletester also verifies sanity of data. That way, I’ll have the ultimate testing tool to receive that catalogs to come. That way, I’ll also get a hint on why KStars is spewing out trixel jump message of late. (Wasn’t doing that before I remodelled the trixel2number and number2trixel code).
    • Random bugfixes for KStars
    • Thankfully, I have access to my phpmyadmin from there 🙂

      BTW, Photos by Kushal are here.

  • Akarsh Simha 5:49 am on June 4, 2008 Permalink
    Tags: , kstars   

    KStars loads 41560 stars in 225ms!!! 

    “We all know Linux is great…it does infinite loops in 5 seconds.”
    –Linus Torvalds

    KStars is now no longer far behind, thanks to James Bowlin. James seems to know every bit of computer architecture. One interesting thing that I learnt from him, after he repeatedly tried to put it into my head, is that malloc()s are like hard disk seeks. You had better do a BIG malloc() at once than make several small malloc()s. He knew for sure, that much of the time KStars spent in loading stars in the StarComponent::readData() method went into the constructors!

    So he suggested something that I initially thought was un-implementable: Forget C++ constructors. Let’s do our own memory management. Create a template StarObject with some default data initialized in it. Whenever you want to create a new StarObject, just memcpy() it to make a new one!

    Now, the first question I asked is what about those memory allocations that the constructor does? For instance, StarObject::StarObject() creates a new QString to store the spectral type. James said we’d take care of that by allocing them in a StarObject::init() function that sets up our freshly copied StarObject. I still had a lot of doubts in mind.

    I decided to jump in and see what happens. Went and made some changes in StarObject – implemented a StarObject::init() that did the job of a constructor, and after a few segfaults, changed StarObject::SpType from QString, to QString *, so that I could alloc it freely at my will. Now, this could create some bugs and memory leaks in KStars if not used properly, but every programmer will have the sense to look at my “WARNING:” comments. I couldn’t believe that it actually worked! And I was really amazed to see the whooping 6x increase in speed, with the readData() method taking 6 microseconds per star instead of the earlier 42!!!

    I had some funny idea of how C++ might store the class, but it turned out to be different. I still don’t know how it does that – it looks fuzzier after I implemented this.

    I’m pretty sure that things will break (and segfault) when KStars learns to remember the user-added information links and observation log in the Detail dialog. We will probably fix this in the trunk before the KDE4.1 release, but that means that I’ll have to make some more changes before it safely merges into the branch.

    I’m now trying another suggestion that James made, about loading all star name data into memory, to avoid the disk head seeking between two different files. Now that the fread() that grabs the data from the binary files takes a significant fraction of the load time, this might be an important factor. Earlier, it would’ve simply gotten buffered by the time StarObject::StarObject() would finish. This requires me to add a header to the star name file describing the number of records, so that’s going to change everything right from the data file generating program. I can’t wait to see how much of an efficiency boost I’ll get. It might not be much, though.

    • arunchaganty 7:34 pm on June 5, 2008 Permalink | Log in to Reply

      I’m just wondering, have you tried profiling KStars to see where things are getting bottlenecked?
      <pimp class=”shameless”>
      Anjuta has a great profiler plugin, which gives you a beautiful call graph and stats table among other things…

    • Akarsh Simha 1:45 am on June 6, 2008 Permalink | Log in to Reply

      Well… I’m still far from using an IDE. I don’t know how to use KDevelop / Eclipse / Anjuta. Some day, I must spend time converting EMacs into the powerful IDE that it can be. Something that integrates with my terminal would be heaven.

      Well, you must teach me how to use Anjuta to do such things. I dunno if other IDEs provide such features, so I might want to use Anjuta for these things.

      Thanks for the tip, and happy hacking.

    • Gopala Krishna 4:00 pm on June 8, 2008 Permalink | Log in to Reply

      Looks like very interesting work 🙂 Nice to know 🙂
      Just in case, you might probably also try to use placement new[1] to allocate StarObject.

      Also, would it be possible to load the star data in separate thread so that you can be responsive atleast. Ofcourse this doesn’t increase the loading time, but the stars will get loaded in the background.


    • Akarsh Simha 8:41 pm on June 8, 2008 Permalink | Log in to Reply

      Hmm… I hope the placement new will not “construct” the object. Thanks for that information. I’ll test the speed of this operator and of it doesn’t cause any overhead, I’ll consider modifying the code to use that.

      We were already considering loading stars in a different thread, but maybe that’s for later. Besides, this portion of the implementation is only for the stars that are loaded once, during startup, where loading in a different thread is of no use. However, that, and nonblocking file reading will help immensely for dynamic loading of stars, during runtime, when we need to display fainter stars.

  • Akarsh Simha 1:42 am on May 31, 2008 Permalink
    Tags: , kstars   

    Two more bugfixes to KStars 

    Fixing bad memory management in the Conjunctions Tool – All my fault! 😀

    Instance management in KSMoon

    • arunchaganty 7:58 pm on May 31, 2008 Permalink | Log in to Reply

      Regd. the 2nd bug fix, doesn’t KDE have a mechanism for taking care of object references? Glib has g_object_ref and g_object_unref, for the same purpose. Also, without looking at the source, the ks_moon is a static *class* variable, does this mean KSMoon is a singleton class? (just out of curiousity), or possibly just the star data is…

    • Akarsh Simha 6:14 am on June 4, 2008 Permalink | Log in to Reply

      I don’t think the KDE API has such a mechanism. Actually, it wouldn’t be as important here, because we are using C++ and not C.
      KSMoon is not a singleton class, but has a few static members in it, that describe coeffecients of various terms in a sinusoidal series used to compute the moon’s position (I don’t know the details).
      Interestingly, this concept struck me because of my minor experience with GLib. g_object_ref and g_object_unref was what gave me the idea of adding a reference count.

    • Gopala Krishna 10:58 am on June 7, 2008 Permalink | Log in to Reply

      Though KDE doesn’t have the reference counting mechanism directly, its inherited from qt4.
      One of the mechanism is using QSharedData and QSharedDataPointer classes, although the classes primarily are for implicit sharing.

      Secondly, qt4.4 has uncovered its atomic api a bit, which helps in safe reference counting across threads. Here is a link

    • Akarsh Simha 8:52 pm on June 8, 2008 Permalink | Log in to Reply

      Ahh… while I think that QSharedDataPointer etc might help here, I think they are too much of an overkill for something as simple as we required here, as you said. Thanks for the information.

  • Akarsh Simha 10:06 pm on May 30, 2008 Permalink
    Tags: kstars   

    Astronomers actually use KStars to control their observatories! 

    Well, I didn’t expect that people would be using KStars to control observatories! I knew it was capable of that [Implements INDI protocol for control of instruments], but I didn’t know it would actually be used for that!

    At the Vainu Bappu Observatory in Kavalur, they use Windows to control the 1m telescope observatory dome, CCD and capture images. [Ugh!]. The telescope control software for the 40″ is written in Delphi by someone in IIA, and cannot seek directly to an object. One has to look up the co-ordinates of the object in huge catalog books listing RA and Dec of various DSOs, Planet Ephemerides etc or go down to the computer lab and use SIMBAD to read the coordinates, and then slew the telescope manually to that RA / Dec. The software is only capable of reporting the current RA / Dec of the telescope, and slewing the dome appropriately to follow the telescope, if I remember right! I doubt it the telescope / CCD support INDI. I wish we could provide them with and request them to move to better FOSS solutions.

  • Akarsh Simha 4:39 am on May 30, 2008 Permalink
    Tags: , kstars   

    The find dialog works to my satisfaction, at last! 

    I used to find the Find Dialog in KStars rather inconvenient. I’d just hit Ctrl+F to fire it, type away “M 97”, hit enter, and it would land me at Andromeda Galaxy instead of Owl Nebula – Because that was the default selected entry in the List View and it would update the list view with the new search filter only after some delay (half a second, I think).

    This commit fixes that by keeping track of whether the list has been filtered after the most recent text entry, and ensures that the list is filtered first thing after entering slotOk().

    So you can simply hit Ctrl+F, type away the full name (or even a part of the name – Kentaurus landed me at Alpha Centauri 🙂 ) and hit enter, and it’ll slew you to the right object instead of Andromeda Galaxy. I’ve tried to ensure that it is as bug-free as possible.

    If you’re running on trunk and have kdeedu compiled, please do test it.

    I’ve made 5 commits in 24 hours. This certainly means I need to get a life (and some sleep)!

    • Prasanna 5:01 pm on May 31, 2008 Permalink | Log in to Reply

      One suggestion. Wouldn’t it be nice of you could type ‘m97’ and still find it. Right now, you _have_ to type the whitespace.

    • Akarsh Simha 6:11 am on June 4, 2008 Permalink | Log in to Reply

      Correct. I’ve had trouble with that too.
      It looks a little difficult to change with the current codebase. I’ll think it over and see how I can change this. Atleast, I could provide one solution quickly – if you type “m97” and _no other object matches_ “m97”, then we could interpret that as “m 97” and slew you there.

      Thanks for the suggestion.

    • Akarsh Simha 7:49 am on June 4, 2008 Permalink | Log in to Reply

      Fixed: http://lists.kde.org/?l=kstars-devel&m=121254565830750&w=2

      I managed to provide the general solution itself. Now, as long as you type out M93 and “quickly” hit enter, it will slew to M 93. But if you wait for more than a second, or select one of the other items from the list, it will go to them.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc