Projects/Edu/KStars/JuniorJobs: Difference between revisions

From KDE TechBase
< Projects‎ | Edu‎ | KStars
No edit summary
m (Fixed few issues)
 
(23 intermediate revisions by 4 users not shown)
Line 10: Line 10:
See [https://mail.kde.org/mailman/listinfo/kstars-devel The List Information Page] to subscribe.
See [https://mail.kde.org/mailman/listinfo/kstars-devel The List Information Page] to subscribe.


If you prefer IRC, we hang out on #kde-edu on irc.freenode.org
Chat with other KStars developer at [https://webchat.kde.org/#/room/#kstars:kde.org| KStars Official Chat Channel].


We keep track of bugs and wishlists on [https://bugs.kde.org The KDE bugzilla]
We keep track of bugs and wishlists on [https://bugs.kde.org The KDE bugzilla]
Line 18: Line 18:
== The Tasks ==
== The Tasks ==


=== Debug the Sky Calendar ===
=== Import Washington Double Star Catalog ===
 
Import [http://vizier.u-strasbg.fr/viz-bin/VizieR-3?-source=B/wds/wds&-out.max=50&-out.form=HTML%20Table&-out.add=_r&-out.add=_RAJ,_DEJ&-sort=_r&-oc.form=sexa Washington Double Star] catalog into KStars. This is a very challenging task because KStars does not support double-stars metadata natively. Neither starData nor deepStarData structures contain fields for double star metadata like separation angle, discovery date..etc. Furthermore, many star in WDS exist already in KStars own Hipparchus and Tycho2 catalogs. To avoid duplication and since Tycho2 is the larger data set of the two, one solution is to update Tycho2 to accommodate WDS data by cross-referencing. If there is another solution to duplicate stars, please suggest it.
 
=== Migrate KPlotting classes to QCustomPlot or Qt Charts ===
 
Many classes in KStars are still using KPlotting library but since it is not actively developed, we would like to migrate away either to QCustomPlot class or Qt Charts module. You can start by migrating the AVT widget from KPlotting to QCustomPlot or Qt Charts.
 
=== Display FWHM and Star Profile in FITS Viewer ===
 
KStars FITS Viewer tool can calculate the overall Half-Flux-Radius (HFR) of stars in an image by summing each star's own HFR and then taking the average. Some users are interested to know the HFR of a single star, in addition to Full-Width-Half-Modulation (FWHM) and star profile (pixel distance from center vs. intensity). A tool-tip like popup when clicking on individual stars in the FITS image would be ideal as it would give users a quick access to some important information regarding a particular star.
 
Start by looking at how stars are detected and how HFR is calculated in FITSData class. Then calculate FWHM and construct a simple stellar profile diagram if the user clicks on a particular star.


The Sky Calendar tool lives in the Tools menu of KStars. The tool now has the labels that it needed badly. However, some lines still don't get labelled because the code isn't robust. The tool also fails at high latitudes. It would be helpful if the Sky Calendar was made complete and bug-free.
=== Auto-suggest well-placed objects for observation / imaging ===


=== Debug the Conjunction tool ===
'''Aim:''' To auto-suggest objects that are well-placed in the night sky to users


The Conjunction tool, for some reason, doesn't seem to be predicting solar eclipses correctly. There are some bugs on our bugzilla related to this as well. It would be useful if the Conjunction tool were made completely bug-free
'''Step 1:''' Move the wishlist feature into a database and support multiple wishlists, and rename it to something else. Ship pre-loaded wish-lists along with KStars, of varying levels of difficulty / experience / instrument requirements.


=== Add Lunar Eclipses ===
'''Step 2:''' Create a backend that will efficiently determine which objects are well-placed (lower than some threshold airmass set by the user) from one or more wishlists.


KStars doesn't predict Lunar Eclipses. Neither does it display them. It would be really useful if it could do these things.
'''Step 3:''' Create a UI that will present one well-placed object to the user. The user may skip objects / cycle through suggestions. Skipped objects should not be displayed for a long time.


One way to do this would be to create a virtual Sky Point, maybe called 'EarthShadow', whose position would be just opposite the sun. An eclipse will be a conjunction between EarthShadow and the moon.
For more details, contact Akarsh Simha


Another possible way to do it is to add functionality to KSMoon, so that we check if the moon is in the shadow of the earth before drawing its image.
=== Debug the Sky Calendar ===


=== Fix the angular distance ruler crash ===
The Sky Calendar tool lives in the Tools menu of KStars. The tool now has the labels that it needed badly. However, some lines still don't get labelled because the code isn't robust. The tool also fails at high latitudes. It would be helpful if the Sky Calendar was made complete and bug-free.


There's an irritating crash condition on our bugzilla where trying to measure angular distances hangs KStars under some conditions. The backtrace is right there. It will be useful if this is fixed.
=== Fix refraction bugs ===
Because the refraction correction and its inverse are not perfect inverses, there are a whole bunch of problems when refraction corrections are turned on. It would greatly help KStars if this was fixed.


=== Fix all those translation bugs ===
=== Fix all those translation bugs ===
Line 49: Line 62:
Implementing this will fix a whole lot of translation-related bugs that are on our bugzilla, and make life for people who use localized versions easier.
Implementing this will fix a whole lot of translation-related bugs that are on our bugzilla, and make life for people who use localized versions easier.


=== Generalize JupiterMoons, SaturnMoons ===
=== Fix JupiterMoons ===


This was originally a GSoC idea, but I thought it was a bit too "small" for a whole summer. The idea is to implement a class that handles moons of planets in the solar system in KStars.
This was originally a GSoC idea, but I thought it was a bit too "small" for a whole summer. The idea is to implement a class that handles moons of planets in the solar system in KStars. Calculations for Jupiter Moons are incorrect which forced us to disable the tool until it is fixed. Identify what is wrong the algorithm and fix it.


Currently, we have JupiterMoons and SaturnMoons (thanks, Vipul!) classes. What should be done now, is to pack all the machinery that goes into these two classes into one generic class (probably called 'SolarSystemMoons'), various instances of which, could represent the moons of Jupiter, Saturn, Mars...
Currently, we have the JupiterMoons classes. What should be done now, is to pack the machinery that goes into this class into a generic class (probably called 'SolarSystemMoons'), various instances of which, could represent the moons of Jupiter, Saturn, Mars...


All our class would need to do, to assume the form of say, JupiterMoons, would be to read off data corresponding to JupiterMoons from some file, say "solarsystemmoons.dat"!
All our class would need to do, to assume the form of say, JupiterMoons, would be to read off data corresponding to JupiterMoons from some file, say "solarsystemmoons.dat"!
Now, the next task...


=== Generalize the Jupiter's Moons Tool ===
=== Generalize the Jupiter's Moons Tool ===
Line 63: Line 74:
See Tools -> Jupiter's Moons. What if I could do this in general with SolarSystemMoons? [See earlier task for details]
See Tools -> Jupiter's Moons. What if I could do this in general with SolarSystemMoons? [See earlier task for details]


=== General Relativistic Effects! ===
=== Add Bortle Simulation ===
 
There's a wishlist filed on bugs.kde.org that suggests that KStars must account for the bending of light around the sun, as predicted by General Relativistic calculations.
 
A quick hint is that the deflection in General Relativity is exactly twice what you would get if you assumed that the laws of gravity were Newtonian and the photon behaved like a massive particle.
 
There seems to be a rather detailed analysis in a  [http://www.newtonphysics.on.ca/ECLIPSE/Eclipse.html paper by Marmet and Couture] that I found off Google. It would be nice if we could correct for all those effects.
 
=== Comets that looks like comets! ===
 
Comets in KStars are currently drawn as dull green circles (at least in the default color scheme). That's not what they look like, in reality!
 
The machinery required to estimate nucleus and coma sizes, and tail lengths of comets are all there in KSComet and KSPlanetBase. What needs to be done, is to provide a proper representation of a comet based on these data on the Sky Map.
 
Remember that a comet's tail points away from the Sun! You can use this to fix the direction of the tail - so you have all information required to draw the comet.


Re-implement CometsComponent::draw() to draw better comets.
Light pollution unfortunately affects most astronomers around the world, amateurs and professionals alike. Introduce a way to simulate the effect of the light pollution using the Bortle scale by limiting the brightness and number of stars and other objects drawn in the screen.


And...
=== Update KStars Documentation ===
=== Fix those inconsistencies with comets ===


Jeamy Lee, a KStars user and contributor, notices that our Sun-Comet distances are wrong! This makes all calculated parameters come out incorrectly. Find his mail with some details [http://lists.kde.org/?l=kstars-devel&m=123454066010918&w=2 here].  
KStars documentation could always need some help to improve it. Here is what you can do:
+ Make new screenshots if the old ones are out of date.
+ Annotate the screenshot to help users easily find what each control means.
+ Add new sections for any missing tools or feature that is yet undocumented.
+ Revise and expand existing documentation. Check spelling & grammar issues.
+ Update the keyboard shortcuts commands.


The aim of this task is to compare some more data against other software, step through the code, and find out where we are going wrong. You could use Jeamy's MPC Reader site to download the [http://mpcreader.sourceforge.net/ latest comet elements] in KStars' format.
=== KStars Startup Tutorial ===


=== Merge NGC data from the SAC catalog ===
Introduce a tutorial mode for new users upon startup. The tutorial should utilize no more than 4-5 screen to explains the basic feature of KStars like searching, panning, zooming, time and simulation settings, downloading data..etc.
The Saguaro Astronomy Club catalog* is an amazing catalog with a lot of deep-sky objects within the reach of amateur astronomers. It has data for most (all?) of the NGC objects, but not for all IC objects. Our current NGC/IC catalog which you can find in data/ngcic.dat is far from accurate, but has data for all NGC/IC objects. Merging the SAC catalog and KStars' NGC/IC catalog would help a lot of our users.


[*We have obtained permission to use it with KStars]
It should enable new users to utilize KStars a lot faster than blind exploration of the application. It is similar to the kind of tutorials used for mobile apps.


== Ideas are welcome! ==
== Ideas are welcome! ==


If you are a user of KStars and have some cool, simple ideas that would make your experience with KStars better, you are welcome to add them to the list above, or discuss them on the kstars-devel mailing list (or post them as wishlists / bug reports on the bugzilla).
If you are a user of KStars and have some cool, simple ideas that would make your experience with KStars better, you are welcome to add them to the list above, or discuss them on the kstars-devel mailing list (or post them as wishlists / bug reports on the bugzilla).

Latest revision as of 22:09, 24 February 2019

What this page is about

This page is intended to list out some small jobs that, if completed, would help KStars become better and more usable. There are both easy ones and hard ones.

If you are interested in contributing to KStars, but don't know where to start, this is probably the best place.

Keeping track of Development

The best way to keep track of Development in KStars is to use the mailing list: [email protected] See The List Information Page to subscribe.

Chat with other KStars developer at KStars Official Chat Channel.

We keep track of bugs and wishlists on The KDE bugzilla

Please do not hesitate to ask if you need help with contributing! We're always looking out for contributors and will be happy to help you out.

The Tasks

Import Washington Double Star Catalog

Import Washington Double Star catalog into KStars. This is a very challenging task because KStars does not support double-stars metadata natively. Neither starData nor deepStarData structures contain fields for double star metadata like separation angle, discovery date..etc. Furthermore, many star in WDS exist already in KStars own Hipparchus and Tycho2 catalogs. To avoid duplication and since Tycho2 is the larger data set of the two, one solution is to update Tycho2 to accommodate WDS data by cross-referencing. If there is another solution to duplicate stars, please suggest it.

Migrate KPlotting classes to QCustomPlot or Qt Charts

Many classes in KStars are still using KPlotting library but since it is not actively developed, we would like to migrate away either to QCustomPlot class or Qt Charts module. You can start by migrating the AVT widget from KPlotting to QCustomPlot or Qt Charts.

Display FWHM and Star Profile in FITS Viewer

KStars FITS Viewer tool can calculate the overall Half-Flux-Radius (HFR) of stars in an image by summing each star's own HFR and then taking the average. Some users are interested to know the HFR of a single star, in addition to Full-Width-Half-Modulation (FWHM) and star profile (pixel distance from center vs. intensity). A tool-tip like popup when clicking on individual stars in the FITS image would be ideal as it would give users a quick access to some important information regarding a particular star.

Start by looking at how stars are detected and how HFR is calculated in FITSData class. Then calculate FWHM and construct a simple stellar profile diagram if the user clicks on a particular star.

Auto-suggest well-placed objects for observation / imaging

Aim: To auto-suggest objects that are well-placed in the night sky to users

Step 1: Move the wishlist feature into a database and support multiple wishlists, and rename it to something else. Ship pre-loaded wish-lists along with KStars, of varying levels of difficulty / experience / instrument requirements.

Step 2: Create a backend that will efficiently determine which objects are well-placed (lower than some threshold airmass set by the user) from one or more wishlists.

Step 3: Create a UI that will present one well-placed object to the user. The user may skip objects / cycle through suggestions. Skipped objects should not be displayed for a long time.

For more details, contact Akarsh Simha

Debug the Sky Calendar

The Sky Calendar tool lives in the Tools menu of KStars. The tool now has the labels that it needed badly. However, some lines still don't get labelled because the code isn't robust. The tool also fails at high latitudes. It would be helpful if the Sky Calendar was made complete and bug-free.

Fix refraction bugs

Because the refraction correction and its inverse are not perfect inverses, there are a whole bunch of problems when refraction corrections are turned on. It would greatly help KStars if this was fixed.

Fix all those translation bugs

Now, this is a big task.

SkyObject classes (see skyobject.h under kstars/skyobjects) should have some standard way of storing names. Currently, some SkyObjects store untranslated names and some store translated names, leading to a big mess. SkyObject should probably store untranslated name strings internally, and return untranslated names upon calling name(). The objectNames() hashes should ideally have untranslated names as well.

So how do we find by translated name? The best way, probably is to have a "reverse translation hash". Since very few objects have translated names, it might be easy to maintain a global hash of translated names vs. untranslated names in some convenient place (probably as a static member of SkyComposite) and do searches for translated names through this.

Implementing this will fix a whole lot of translation-related bugs that are on our bugzilla, and make life for people who use localized versions easier.

Fix JupiterMoons

This was originally a GSoC idea, but I thought it was a bit too "small" for a whole summer. The idea is to implement a class that handles moons of planets in the solar system in KStars. Calculations for Jupiter Moons are incorrect which forced us to disable the tool until it is fixed. Identify what is wrong the algorithm and fix it.

Currently, we have the JupiterMoons classes. What should be done now, is to pack the machinery that goes into this class into a generic class (probably called 'SolarSystemMoons'), various instances of which, could represent the moons of Jupiter, Saturn, Mars...

All our class would need to do, to assume the form of say, JupiterMoons, would be to read off data corresponding to JupiterMoons from some file, say "solarsystemmoons.dat"!

Generalize the Jupiter's Moons Tool

See Tools -> Jupiter's Moons. What if I could do this in general with SolarSystemMoons? [See earlier task for details]

Add Bortle Simulation

Light pollution unfortunately affects most astronomers around the world, amateurs and professionals alike. Introduce a way to simulate the effect of the light pollution using the Bortle scale by limiting the brightness and number of stars and other objects drawn in the screen.

Update KStars Documentation

KStars documentation could always need some help to improve it. Here is what you can do: + Make new screenshots if the old ones are out of date. + Annotate the screenshot to help users easily find what each control means. + Add new sections for any missing tools or feature that is yet undocumented. + Revise and expand existing documentation. Check spelling & grammar issues. + Update the keyboard shortcuts commands.

KStars Startup Tutorial

Introduce a tutorial mode for new users upon startup. The tutorial should utilize no more than 4-5 screen to explains the basic feature of KStars like searching, panning, zooming, time and simulation settings, downloading data..etc.

It should enable new users to utilize KStars a lot faster than blind exploration of the application. It is similar to the kind of tutorials used for mobile apps.

Ideas are welcome!

If you are a user of KStars and have some cool, simple ideas that would make your experience with KStars better, you are welcome to add them to the list above, or discuss them on the kstars-devel mailing list (or post them as wishlists / bug reports on the bugzilla).