headers
Akarsh Simha | 1 Nov 23:44
Picon
Gravatar

Re: Tycho-2 Star catalog lacking Stars?

> > Thanks for this valuable information. It is very much possible that
> > there are bugs in both the conversion process and in the drawing code.
> 
> I think it's the drawing code. I now found the stars. They are invisible, but 
> I can attach a label to them and see their details.

Thanks a billion. This helped me greatly while fixing the bug.

> > It would help if you could tell us which version of KStars you are
> > using as I fixed some of these bugs some day in the field. Many such
> > elusive bugs go unnoticed, and I must thank you for excavating these.
> 
> I'm using KStars 1.5.3 from KDE 4.3.2. Is there any way to build just a new 
> kstars from svn (ideally using the libs I have installed from rpm) without 
> building a complete new KDE?

Try using the packages from 4.3.2 and building KStars from trunk. I
don't think there's a "standard" shortcut to do that, but you should
be able to do this with some dirty hacks, since KStars isn't radically
affected by changes in kdelibs etc.

However, the recommended way of doing things is to build the whole of
KDE from scratch, so that it's easy to catch and resolve "upstream"
bugs in kdelibs etc.

> > It would also help if you could send us a screenshot of the
> > superimposed photograph indicating the missing stars.
> 
> I have attached the photograph with the missing stars marked (the marked group 
> in the center is M29). There might be more missing stars, but I think I found
(Continue reading)

Permalink | Reply | 3 comments |
headers
Akarsh Simha | 1 Nov 23:59
Picon
Gravatar

branches/KDE/4.3/kdeedu/kstars/kstars/skyobjects

SVN commit 1043604 by asimha:

Backporting fix for missing stars (r1043599) to 4.3 branch

Original commit log:
--------------------
Ensure that stars with unspecified spectral types / partially
specified spectral types are drawn as well. For the time being, all
stars with undefined spectral classes are drawn with the colors
corresponding to spectral class 'A'.

This fixes the bug that Lukas Middendorf brought up on the mailing
list, regarding stars in M 29.

Many thanks to Lukas, who not only pointed out this hard-to-catch bug,
but also gave me enough information to swat it dead real easy!

CCMAIL: kstars-devel <at> kde.org

 M  +8 -1      starobject.cpp  
 M  +4 -0      starobject.h  

--- branches/KDE/4.3/kdeedu/kstars/kstars/skyobjects/starobject.cpp #1043603:1043604
@@ -576,6 +576,13 @@
     }
 }

+bool StarObject::isSpecType( char c ) {
+    if( c == 'W' || c == 'O' || c == 'B' || c == 'A' || c == 'F' || c == 'G' || c == 'K' || c == 'M' || c == 'R' || c == 'N' || c == 'S' )
+        return true;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akarsh Simha | 2 Nov 02:43
Picon
Gravatar

KDE/kdeedu/kstars/kstars

SVN commit 1043623 by asimha:

Show name labels for deep-sky objects. 

I've tried to implement all the ideas that were posted as comments in
the wishlist report. Thanks for the report, and the ideas.

It looks like the slider for controlling density of DSO labels isn't
working. Other TODOs are - the colors for the labels are not editable
at the moment, if I amn't wrong. I'm keeping them for the next weekend.

CCMAIL: kstars-devel <at> kde.org
FEATURE: 207798

 M  +1 -0      colorscheme.cpp  
 M  +25 -0     kstars.kcfg  
 M  +5 -0      options/opscatalog.cpp  
 M  +169 -4    options/opscatalog.ui  
 M  +50 -0     skycomponents/deepskycomponent.cpp  
 M  +25 -0     skycomponents/deepskycomponent.h  
 M  +1 -0      skycomponents/skymapcomposite.cpp  
 M  +18 -0     skyobjects/deepskyobject.cpp  
 M  +2 -0      skyobjects/deepskyobject.h  

--- trunk/KDE/kdeedu/kstars/kstars/colorscheme.cpp #1043622:1043623
@@ -46,6 +46,7 @@
     appendItem("HSTColor",
                i18nc("Object with extra attached URLs", "Object w/ Links"), "#930000");
     appendItem("SNameColor",       i18n("Star Name"),              "#577d7d");
+    appendItem("DSNameColor",      i18n("Deep Sky Object Name"),   "#75759c");
(Continue reading)

Permalink | Reply | 6 comments |
headers
Khudyakov Alexey | 2 Nov 16:18
Picon
Gravatar

Re: Tycho-2 Star catalog lacking Stars?

В сообщении от 02 ноября 2009 01:44:36 Akarsh Simha написал:
> > I'm using KStars 1.5.3 from KDE 4.3.2. Is there any way to build just anew 
> > kstars from svn (ideally using the libs I have installed from rpm) without 
> > building a complete new KDE?
>
> Try using the packages from 4.3.2 and building KStars from trunk. I
> don't think there's a "standard" shortcut to do that, but you should
> be able to do this with some dirty hacks, since KStars isn't radically
> affected by changes in kdelibs etc.
> 
Just try to build kdeedu againist latest kdelibs in you distro. I don't 
think there would be a problem. I don't rebuild kdelibs in month.

This way you need to build only libkdeedu & kstars.
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 2 comments |
headers
Khudyakov Alexey | 2 Nov 16:14
Picon
Gravatar

Stars drawing (speed and color)

Hello

After recent fix in star drawing code I looked into it. I think usage of 
QString as keys for cache isn't the best thing to do. I've tried to experiment 
with other indexing schemes. So far I got ~10% speedup for map update with 
maximum star density. Sadly code become harder to read. 

Another problem I spotted is function StarObject::updateColors. It appears
only in commented code in the StarComponent which is marked "REMOVE" [1]
Moreover it doesn't know anything about color modes. 

So question is whether it a historical remnant which should be removed?

[1] skycomponents/starcomponent.cpp:301
--
  Khudyakov Alexey
Permalink | Reply | 4 comments |
headers
Médéric Boquien | 2 Nov 17:21
Picon
Favicon
Gravatar

Re: Tycho-2 Star catalog lacking Stars?

On Monday 02 November 2009 10:18:03 Khudyakov Alexey wrote:
> В сообщении от 02 ноября 2009 01:44:36 Akarsh Simha написал:
> > > I'm using KStars 1.5.3 from KDE 4.3.2. Is there any way to build just
> > > anew kstars from svn (ideally using the libs I have installed from rpm)
> > > without building a complete new KDE?
> >
> > Try using the packages from 4.3.2 and building KStars from trunk. I
> > don't think there's a "standard" shortcut to do that, but you should
> > be able to do this with some dirty hacks, since KStars isn't radically
> > affected by changes in kdelibs etc.
>
> Just try to build kdeedu againist latest kdelibs in you distro. I don't
> think there would be a problem. I don't rebuild kdelibs in month.

Beware, trunk now requires Qt 4.6, i would not be surprised if kdeedu already 
requires it too.

Regards,

Médéric

_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 1 comment |
headers
Khudyakov Alexey | 2 Nov 16:43
Picon
Gravatar

Re: Tycho-2 Star catalog lacking Stars?

В сообщении от Понедельник 02 ноября 2009 19:21:57 вы написали:
> On Monday 02 November 2009 10:18:03 Khudyakov Alexey wrote:
> > В сообщении от 02 ноября 2009 01:44:36 Akarsh Simha написал:
> > > > I'm using KStars 1.5.3 from KDE 4.3.2. Is there any way to build just
> > > > anew kstars from svn (ideally using the libs I have installed from
> > > > rpm) without building a complete new KDE?
> > >
> > > Try using the packages from 4.3.2 and building KStars from trunk. I
> > > don't think there's a "standard" shortcut to do that, but you should
> > > be able to do this with some dirty hacks, since KStars isn't radically
> > > affected by changes in kdelibs etc.
> >
> > Just try to build kdeedu againist latest kdelibs in you distro. I don't
> > think there would be a problem. I don't rebuild kdelibs in month.
> 
> Beware, trunk now requires Qt 4.6, i would not be surprised if kdeedu
>  already requires it too.
> 
Thank you for warning. libkdeedu builds fine againist old kdelibs though. 
I suppose I have to refrain from updating kdelibs until Qt4.6 arrives in the
Debian.
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 0 comments |
headers
Khudyakov Alexey | 2 Nov 18:39
Picon
Gravatar

Re: Stars drawing (speed and color)

> Follow-up on this subject
> 
Another problematic place is StarObject::initImages. It uses pixmaps of size 
15*SkyMap::Instance()->scale(). Then algorithm which actaully create pixmaps 
assume that they are 15x15 pixels. Which behaviour is correct?

And last one is
> double StarObject::pmMagnitude()
> {
>    return sqrt( pmRA() * pmRA() + pmDec() * pmDec() );
> }
If this functionfion calculate absolute value of proper motion it should use 
following formula:

sqrt( v_{RA}^2 * cos(dec)^2 + v_dec^2 )
Permalink | Reply | 1 comment |
headers
Akarsh Simha | 2 Nov 20:03
Picon
Gravatar

Re: Stars drawing (speed and color)

> After recent fix in star drawing code I looked into it. I think usage of 
> QString as keys for cache isn't the best thing to do. I've tried to experiment 
> with other indexing schemes. So far I got ~10% speedup for map update with 
> maximum star density. Sadly code become harder to read. 

Wow! That's awesome. I think it is okay to sacrifice code readability
for the speed increase, considering that it's annoyingly slow right
now. I think it should be okay to commit it, as long as you have some
comments explaining what's going on and what the indexing scheme is.

> Another problem I spotted is function StarObject::updateColors. It appears
> only in commented code in the StarComponent which is marked "REMOVE" [1]
> Moreover it doesn't know anything about color modes. 

> So question is whether it a historical remnant which should be removed?

I've noticed that too. I think it's okay to remove it, although I
really don't know. In any case, we can always revert the change if
required.

Regards
Akarsh
Permalink | Reply | 1 comment |
headers
Akarsh Simha | 2 Nov 20:07
Picon
Gravatar

Re: Stars drawing (speed and color)

On Mon, Nov 02, 2009 at 08:39:13PM +0300, Alexey Khudyakov wrote:
> > Follow-up on this subject
> > 
> Another problematic place is StarObject::initImages. It uses pixmaps of size 
> 15*SkyMap::Instance()->scale(). Then algorithm which actaully create pixmaps 
> assume that they are 15x15 pixels. Which behaviour is correct?

I think they can be 15x15, since the star size is recomputed using the
zoom factor anyway. If that's the screen scale, it still shouldn't
matter. What we must preserve is the relative sizes of stars. I think
it's okay to use 15x15, unless it looks awful on some very big
displays. Which one will be faster?

> And last one is
> > double StarObject::pmMagnitude()
> > {
> >    return sqrt( pmRA() * pmRA() + pmDec() * pmDec() );
> > }
> If this functionfion calculate absolute value of proper motion it should use 
> following formula:
> 
> sqrt( v_{RA}^2 * cos(dec)^2 + v_dec^2 )

Hmm... you seem to be right, and that also means that I'll need to
regenerate USNO NOMAD! I'll work on this next weekend, hopefully. But
feel free to experiment around.

Regards
Akarsh
(Continue reading)

Permalink | Reply | 0 comments |

Gmane